A camera watches your plants on a schedule. Each photo goes to an AI trained only on cannabis, and Home Assistant turns the answer into sensors you can automate against. Something looks off, your phone buzzes with the diagnosis and the photo. Everything's fine, it stays quiet.

Setup runs about 20 minutes. The cost is a camera you probably already own plus PlantLab's free tier – three diagnoses a day, no card. No soldering, no standalone Python scripts. A Home Assistant integration and some YAML.

Your eyes are good. They're also asleep at 6 AM, and they've never once compared today's leaf color against yesterday's with any real consistency. A camera bolted to a tent pole doesn't get distracted and has never talked itself into “it's probably fine” at 11 PM. That's the whole pitch.

If you run Node-RED instead of native HA automations, there's a companion walkthrough for that. This one stays inside Home Assistant.

Prerequisites

• Home Assistant running – any install method
• A camera HA can snapshot: IP cam, Frigate, ESP32-CAM, Wyze with RTSP, Reolink, Tapo, anything with a camera. entity
• A PlantLab account – free at plantlab.ai; grab your API key from the dashboard
• HACS – optional, but it makes the install one click
• Basic YAML comfort. If you've edited configuration.yaml, you're set.

Camera positioning: shoot the canopy from above or a slight angle. Overhead gives the best coverage. Avoid shooting through blurple LEDs – the model needs real leaf color, not everything tinted purple. If your lights are blurple, run the check during a lights-off window or use the camera's white LED.

Step 1: Install the PlantLab Integration

Via HACS (recommended)

1. Open HACS in the sidebar
2. Search PlantLab in Integrations
3. Click Download
4. Restart Home Assistant

Manual install

# SSH into your HA machine
cd /config/custom_components/
git clone https://github.com/plantlab-ai/home-assistant-plantlab.git plantlab_temp
mv plantlab_temp/custom_components/plantlab .
rm -rf plantlab_temp

Restart HA after copying.

Configure

1. Settings > Devices & Services
2. + Add Integration
3. Search PlantLab
4. Paste your API key
5. Done – you get a PlantLab device with a set of sensors.

No YAML for the integration itself. The config flow handles it.

Step 2: Meet Your New Sensors

After setup you get these entities automatically:

One thing worth flagging up front: the condition and pest sensors report the display name – Nitrogen Deficiency, not nitrogen_deficiency. That matters when you trigger automations on their state. The raw snake_case class_id lives in the sensor's attributes and in the service response, which is what you'll actually key automations off of below.

Everything reads “Unknown” until the first diagnosis runs. After a check:

Step 3: The Daily Health Check

Runs once a day, grabs a photo, sends it to PlantLab, and pings you only if there's a problem. Quiet when fine, loud when not.

automation:
  - alias: "Plant Health Check - Morning"
    trigger:
      - platform: time
        at: "08:00:00"
    action:
      # Capture a snapshot
      - action: camera.snapshot
        target:
          entity_id: camera.grow_tent    # your camera entity
        data:
          filename: /config/www/plant_check.jpg

      # Give the file a moment to write
      - delay:
          seconds: 3

      # Run the diagnosis
      - action: plantlab.diagnose
        data:
          image_path: /config/www/plant_check.jpg
        response_variable: result

      # Alert only if the first plant comes back unhealthy
      - if: >
          {{ result.results | count > 0
             and result.results[0].is_healthy == false }}
        then:
          - action: notify.mobile_app_your_phone
            data:
              title: "Plant Issue Detected"
              message: >
                {{ result.results[0].conditions[0].display_name }}
                detected ({{ (result.results[0].conditions[0].confidence * 100) | round }}% confidence).
                Growth stage: {{ result.results[0].growth_stage }}.
              data:
                image: /local/plant_check.jpg

One structural thing to know: PlantLab returns one result per detected plant under results. result.results[0] is the first plant, which is why the health check, the condition, and the confidence all read off results[0] and not the top level. More on multi-plant in a moment.

Why morning? You catch overnight problems before the lights-on period drives symptoms further, and the first hour of the light cycle gives a neutral photo without heat-droop.

Skip the file – snapshot from the camera directly

Don't want files on disk? Point the service at the camera entity:

      - action: plantlab.diagnose
        data:
          entity_id: camera.grow_tent
        response_variable: result

Simpler, but you lose the photo to attach to the notification. Your call.

Step 4: Add It to Your Dashboard

A basic card for last-check results:

type: vertical-stack
cards:
  - type: picture-entity
    entity: camera.grow_tent
    name: Grow Tent
    show_state: false

  - type: entities
    title: Plant Health
    entities:
      - entity: sensor.plantlab_health
        name: Status
      - entity: sensor.plantlab_conditions
        name: Condition
      - entity: sensor.plantlab_pests
        name: Pests
      - entity: sensor.plantlab_growth_stage
        name: Growth Stage
      - entity: sensor.plantlab_reliability_score
        name: Reliability
      - entity: binary_sensor.plantlab_problem
        name: Problem?

Nothing fancy, but it's one screen. Make it prettier if you like – I'm an engineer, not a designer.

Step 5: The Fun Part

Gate on confidence and reliability

Every diagnosis carries a per-condition confidence and a plant-level reliability_score – a 0-1 trust signal for the whole call. You don't want a push for every marginal detection. Extend the if from Step 3:

      - if: >
          {{ result.results | count > 0
             and result.results[0].is_healthy == false
             and result.results[0].conditions[0].confidence > 0.75
             and result.results[0].reliability_score > 0.7 }}
        then:
          - action: notify.mobile_app_your_phone
            data:
              title: "Confirmed Issue"
              message: >
                {{ result.results[0].conditions[0].display_name }}
                at {{ (result.results[0].conditions[0].confidence * 100) | round }}% confidence.

Auto-respond to a specific condition

With smart plugs, dosing pumps, or controllable fans you can close the loop. Read the class_id straight off the response – it's the stable snake_case identifier, unlike the display-name sensor state:

      # inside the same daily-check automation, after the diagnose call
      - if: >
          {{ result.results | count > 0
             and result.results[0].conditions[0].class_id == 'calcium_deficiency'
             and result.results[0].conditions[0].confidence > 0.8 }}
        then:
          # Dose cal-mag for 5 seconds
          - action: switch.turn_on
            target:
              entity_id: switch.calmag_pump
          - delay:
              seconds: 5
          - action: switch.turn_off
            target:
              entity_id: switch.calmag_pump

          # Always notify when auto-dosing
          - action: notify.mobile_app_your_phone
            data:
              title: "Auto-Dosed Cal-Mag"
              message: >
                Calcium deficiency at
                {{ (result.results[0].conditions[0].confidence * 100) | round }}%.
                Dosed 5 seconds of cal-mag. Check your plant.

Fair warning: always notify when auto-dosing, and set a real confidence floor. Let the system correctly ID a condition manually a few times before you trust it to dose. A pump firing on a false positive is not a fun morning.

Handle more than one plant

If your camera sees the whole tent, results has an entry per plant and sensor.plantlab_plant_count tells you how many. Loop instead of assuming results[0]:

      - repeat:
          for_each: "{{ result.results }}"
          sequence:
            - if: "{{ repeat.item.is_healthy == false }}"
              then:
                - action: notify.mobile_app_your_phone
                  data:
                    title: "Plant Issue Detected"
                    message: >
                      {{ repeat.item.conditions[0].display_name }}
                      ({{ (repeat.item.conditions[0].confidence * 100) | round }}%).

The per-plant sensors always track the first plant, so the loop is how you cover a multi-plant frame. If you'd rather diagnose each plant cleanly, give each its own camera and its own automation.

Ramp up monitoring when something's wrong

automation:
  - alias: "Increase Checks When Unhealthy"
    trigger:
      - platform: state
        entity_id: binary_sensor.plantlab_problem
        to: "on"
    action:
      - action: automation.turn_on
        target:
          entity_id: automation.plant_health_check_afternoon

Create a second check (afternoon, maybe a different angle) that's normally disabled and only wakes up when a problem is flagged. More eyes when it matters, silence otherwise.

Troubleshooting

What the API Actually Returns

Here's the full response – everything inside result in your automations. Note the top-level is_cannabis (image-wide) versus the per-plant fields nested in results:

schema_version: "3.0.0"
success: true
is_cannabis: true
cannabis_confidence: 0.97
results:
  - bbox: { x0: 0, y0: 0, x1: 1, y1: 1, normalized: true }
    is_healthy: false
    health_confidence: 0.87
    growth_stage: vegetative
    growth_stage_confidence: 0.89
    conditions:
      - class_id: nitrogen_deficiency
        display_name: Nitrogen Deficiency
        confidence: 0.85
    pests:
      - class_id: spider_mites
        display_name: Spider Mites
        confidence: 0.72
    reliability_score: 0.82
    mulders_hypotheses:
      - excess: potassium_excess
        explains:
          - nitrogen_deficiency
        evidence: 0.85
        evidence_count: 1

reliability_score is a 0-1 trust signal for that plant's diagnosis – higher means PlantLab is more confident the call is right. Route on it for automations that should only fire on high-trust results.

mulders_hypotheses is the nutrient antagonism read. Here it's flagging that the nitrogen-deficiency symptoms might trace back to a potassium excess locking out nitrogen uptake, rather than an actual shortage – so piling on more nitrogen could make it worse. That's the kind of thing that saves a week of chasing the wrong fix.

Each plant in a multi-plant frame gets its own entry with its own bbox (normalized [0,1] canopy box), so you always know which plant a diagnosis belongs to.

FAQ

How many checks per day on the free tier?

Three. One morning, one evening, one spare for when you're feeling paranoid – enough for a home grow. Pro is 500/month if you need more.

Can I use any camera?

If HA can snapshot from it, PlantLab can diagnose from it. Tested with Frigate, Wyze RTSP, ESP32-CAM, Reolink, and Tapo. Phone photos work too – drop the image in /config/www/ and point the service at the path.

Does this work for tomatoes?

No. PlantLab will look at your tomato and politely tell you it's not cannabis.

It says healthy but I can see a problem. Now what?

Trust your eyes. The AI catches things you haven't noticed yet – it's not there to override what you already see. Early symptoms, odd lighting, and blurry photos all cut accuracy. Cannabis detection and the overall health check are the most reliable parts; specific condition labels, especially lookalike nutrient deficiencies, are harder and keep improving with each retrain.

Can I run this offline?

Not yet – cloud only. On-premise is on the roadmap for air-gapped facilities.

PlantLab diagnoses 31 cannabis conditions – nutrient deficiencies, pests, diseases, and environmental stress – from a single photo. The Home Assistant integration is open source at github.com/plantlab-ai/home-assistant-plantlab. Try it free at plantlab.ai.

PlantLab can now analyze more than one plant in a single uploaded photo. Instead of forcing the whole image into one diagnosis, the API slices separable plants into their own canopy boxes, runs the diagnosis cascade per plant, and returns a results[] array with one entry per plant.

This is a breaking API change. The response schema is now 3.0.0. Fields like is_healthy, growth_stage, conditions, pests, and reliability_score moved out of the top level and into results[]. Image-level fields such as is_cannabis and cannabis_confidence stay top-level.

If your code already treats a diagnosis as “the answer for this plant,” the migration is simple: iterate results[]. Single-plant photos still return exactly one result.

Why this had to change

Most plant diagnosis tools assume one photo equals one plant.

That is convenient for an API contract. It is not how people take grow-room photos.

Growers send canopy shots. They send side-by-side plants from the same tray. They send one wide image because it is faster than taking six separate photos. Sometimes one plant is healthy and the plant beside it is showing early deficiency. Sometimes the left side of a tent is getting different airflow or light intensity than the right side.

The old PlantLab response could only represent one diagnosis. If the image contained three plants, the model still had to answer as if it were looking at one object. That creates two bad outcomes.

First, the answer can become a blend. A healthy plant and a deficient plant in the same frame can collapse into a single diagnosis that is not quite true for either plant.

Second, the UI has no place to show location. Even when the model found the right problem, it could not say “this plant, in this part of the image.” For automation and history, that is a real limitation. A diagnosis without a region is hard to compare over time.

The fix was not another confidence field. It was a different shape of response.

What changes for growers

When the photo contains one plant, the experience should feel the same. PlantLab returns one diagnosis, with a full-image bounding box:

"results": [
  {
    "bbox": { "x0": 0, "y0": 0, "x1": 1, "y1": 1, "normalized": true },
    "is_healthy": false,
    "growth_stage": "flowering",
    "conditions": [
      { "class_id": "magnesium_deficiency", "confidence": 0.85 }
    ],
    "reliability_score": 0.87
  }
]

When the photo contains multiple separable plants, PlantLab returns multiple entries. Each entry has its own normalized bounding box and its own diagnosis fields:

{
  "schema_version": "3.0.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "results": [
    {
      "bbox": { "x0": 0.06, "y0": 0.12, "x1": 0.45, "y1": 0.92, "normalized": true },
      "is_healthy": true,
      "health_confidence": 0.91,
      "growth_stage": "vegetative"
    },
    {
      "bbox": { "x0": 0.52, "y0": 0.10, "x1": 0.93, "y1": 0.95, "normalized": true },
      "is_healthy": false,
      "health_confidence": 0.88,
      "growth_stage": "vegetative",
      "conditions": [
        { "class_id": "nitrogen_deficiency", "confidence": 0.80 }
      ],
      "reliability_score": 0.83
    }
  ]
}

The boxes are normalized x0, y0, x1, y1 coordinates in the original image. They are designed for overlays, history views, and automation clients that need to keep a result tied to the plant it came from.

The original uploaded image stays the canonical image. PlantLab does not store a separate cropped image for each plant as the primary record. The boxes are metadata attached to the original frame.

Why the response is an array, not plant_1, plant_2, plant_3

Arrays are boring. That is why they are the right answer.

A grow tent can have one plant today and four plants next week. A user can upload a single close-up, then a wide tray shot, then a photo where the plants overlap too much to split safely. The API should not need new field names for each case.

With results[], the contract is stable:

• len(results) == 1: use it like the old response.
• len(results) > 1: show a plant selector or iterate through every result.
• Each result carries its own bbox.

This also makes the API easier for automation systems. If you are feeding PlantLab into Home Assistant, Node-RED, a dashboard, or a cultivation controller, each plant result is a normal object. You can pick the first plant for backward-compatible behavior, show a plant count, or build a UI that lets the user choose which plant they care about.

The PlantLab Home Assistant integration has already been updated for this shape. Version 0.7.0 reads schema 3.0.0, keeps the existing sensors pointed at the primary plant (results[0]), and adds sensor.plantlab_plant_count so automations can tell when the last frame held more than one plant.

What changed for API consumers

Before schema 3.0.0, diagnosis fields were top-level:

{
  "schema_version": "2.1.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "is_healthy": false,
  "growth_stage": "flowering",
  "conditions": [
    { "class_id": "magnesium_deficiency", "confidence": 0.85 }
  ],
  "reliability_score": 0.91
}

In schema 3.0.0, those diagnosis fields live inside results[]:

{
  "schema_version": "3.0.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "results": [
    {
      "bbox": { "x0": 0, "y0": 0, "x1": 1, "y1": 1, "normalized": true },
      "is_healthy": false,
      "growth_stage": "flowering",
      "conditions": [
        { "class_id": "magnesium_deficiency", "confidence": 0.85 }
      ],
      "reliability_score": 0.91
    }
  ]
}

Migration pattern:

const primaryPlant = response.results?.[0]

if (primaryPlant?.is_healthy === false) {
  for (const condition of primaryPlant.conditions ?? []) {
    console.log(condition.class_id, condition.confidence)
  }
}

If your integration displays only one diagnosis, start with results[0]. That gives you a safe primary-plant path while you add richer multi-plant UI later.

If your integration can display multiple plants, iterate the array and draw each bbox over the original image.

If you use the official Home Assistant integration, update to v0.7.0. It is rollout-friendly: the updated integration understands the new results[] response, but it also falls back to the old flat fields when talking to a pre-3.0.0 API. That means you can update Home Assistant before the API flips without breaking existing sensors. Older integration versions should be upgraded before you depend on schema 3.0.0.

Why I made it breaking

I considered keeping the old top-level fields for one release and adding results[] beside them. That sounds friendlier until the two disagree.

Imagine an image with two plants:

• Plant A is healthy.
• Plant B has a deficiency.

What should the old top-level is_healthy say? If it says false, the healthy plant is wrong. If it says true, the deficient plant is wrong. If it tries to summarize the whole image, it stops being the same field that integrators already rely on.

Keeping both contracts would make the API easier to call and harder to trust. I would rather force one clear migration than leave stale fields around for months.

So the schema version bumped to 3.0.0. Consumers must read results[].

What PlantLab does when the image is messy

Multi-plant analysis is only useful when the plants can be separated cleanly enough to diagnose.

Dense canopy shots are hard. Touching plants, heavy overlap, blur, and poor lighting can make a crop ambiguous. Splitting too aggressively is worse than under-splitting, because an over-split can create contradictory diagnoses from pieces of the same plant.

PlantLab uses a conservative policy:

• If the image looks like one plant, return one result.
• If the plants are separable, return one result per plant.
• If the scene is too dense or ambiguous, prefer one safer result over several questionable crops.
• Cap the number of plant crops so latency stays bounded.

That last part matters. A multi-plant image now runs a lightweight slicing step, then the diagnosis cascade per plant. We also removed a wasted whole-image cascade for multi-plant paths, so a three-plant image runs the plant diagnosis work three times, not four.

The point is not to pretend every canopy photo is solvable. The point is to make the output honest about the structure of the image.

What this unlocks

For growers, this makes wide shots more useful. You can upload a photo of a tray and see which plant the diagnosis belongs to.

For paid history, bounding boxes make comparison over time more meaningful. A diagnosis can be stored with the region it came from instead of being attached only to the original image.

For automation, the response is finally shaped like the thing it describes. A controller can loop over plants, display per-plant state, or decide to alert only when any plant crosses a threshold.

For training, this closes a long-standing mismatch. A whole-frame label is often too crude for a multi-plant image. Per-plant boxes let the system learn from the plant region without pretending the entire image has one uniform condition.

This is the main reason I was willing to break the schema. The old response was simpler, but it encoded the wrong assumption.

Migration checklist

If you maintain a PlantLab client, check these paths:

• Replace reads of top-level is_healthy, health_confidence, growth_stage, conditions, pests, mulders_hypotheses, reasoning fields, and reliability_score with reads from results[].
• Keep reading top-level is_cannabis and cannabis_confidence.
• Treat results[0] as the primary plant if you need backward-compatible behavior.
• Use len(results) as the plant count.
• Draw result.bbox over the original uploaded image if your UI supports overlays.
• Treat {x0:0, y0:0, x1:1, y1:1} as the whole-image fallback box.
• If you use Home Assistant, update plantlab-ai/home-assistant-plantlab to v0.7.0. Existing diagnosis sensors continue to show the primary plant, and the new sensor.plantlab_plant_count exposes len(results).

The full OpenAPI schema is available in the PlantLab docs at plantlab.ai/docs.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, structured JSON responses, and API docs built for automation clients.

FAQ

Does every upload now return multiple plants?

No. Single-plant images return one result. Ambiguous dense canopy images may also return one result if splitting would be unsafe.

Did the old fields disappear?

Yes. Per-plant diagnosis fields moved into results[] in schema 3.0.0. Top-level is_cannabis and cannabis_confidence remain image-level fields.

How do I get the plant count?

Use response.results.length.

Are the bounding boxes pixel coordinates?

No. They are normalized coordinates from 0 to 1, relative to the original image. Multiply by image width and height when drawing overlays.

What should older clients do?

Read results[0] first. That restores the old “one diagnosis” behavior while keeping your code compatible with multi-plant uploads.

Is the Home Assistant integration ready?

Yes. The official Home Assistant integration is updated in v0.7.0. It reads schema 3.0.0, surfaces the primary plant through the existing sensors, adds sensor.plantlab_plant_count, and still tolerates pre-3.0.0 flat API responses during rollout.

The Short Version

AI plant health diagnosis is having a moment – grow cameras with “AI” on the box, phone apps that name a deficiency from one photo, controllers that promise to read your plants for you. Most of them report a confidence number they haven't earned, because the hard part of AI plant diagnosis isn't producing an answer. It's knowing when the answer is wrong, and proving the accuracy you claim on photos the model has never seen. June at PlantLab was a research-and-hardening month spent almost entirely on that second problem: catching my own model being wrong before a grower could. This is what that looks like from the inside, with the numbers.

Most of the month, I tried to prove myself wrong

There's a failure pattern in applied machine learning that's easy to fall into and embarrassing to admit: you measure your model against data it has secretly already seen, get a great number, and ship a worse product than your benchmark says you have. The honest version of this work is mostly the unglamorous job of making sure that can't happen – and then re-checking, because it usually has happened somewhere you didn't look.

So June was light on shipped features and heavy on measurement. Three of the month's most useful outcomes were negative – things I built, validated, and then deliberately threw away because the evidence said they didn't help. That's not wasted time. A NO-GO you can trust is worth more than a feature you can't.

The accuracy number that was lying to me

The biggest single finding of the month: my internal accuracy was inflated by roughly 14 percentage points, and the cause was data leakage.

Here's what that means in plain terms. To know how good a diagnosis model is, you test it on photos it didn't learn from. If even a slice of your test photos overlap with your training photos, the model isn't being asked to diagnose – it's being asked to remember, and it scores far higher than it will in the real world. When I audited my evaluation set carefully, about 85% of one classifier stage's test images turned out to share lineage with its training data. The accuracy that overlap was buying us was about 14 points of pure illusion.

The fix was tedious and worth every hour. I rebuilt a clean evaluation set – over 20,000 plant images, locked and checksum-pinned so it can't drift – with the training lineage of every image traced and excluded. Then I made “score only against the locked, leakage-free set” a mandatory gate that every model has to pass before it can deploy. No new version ships on a number I can't defend.

On that honest, leakage-free set, overall diagnostic accuracy sits at 94.6%, up from 93.5% at the start of the month. That second number matters more than the first: it's measured on data the model has never touched, and it went up during a month where I was actively trying to deflate my own claims. Two of the pipeline's stages remain the weak links and are the explicit target of the next training round – I publish the strong numbers below and keep the weak ones honest rather than hiding them.

For context, the two stages I'm confident citing, measured the same leakage-aware way:

Three things I built, validated, and killed

A diagnosis pipeline gets safer when it knows when to stop and ask for help. So I tried to add three “brakes” – rules that would catch a likely-wrong answer and downgrade it to “not sure” instead of stating it confidently. Building them was the easy part. Testing whether they actually helped is where most of the value was.

• The reliability brake shipped. It watches a separate trustworthiness signal and, on the photos where the detailed classifier is most likely to be wrong, hands back a hedge instead of a false certainty. It catches roughly half of the cases that would otherwise have produced a confident wrong answer with no warning. This one earned its place.
• Two other brakes did not. A “health gate” and a second-stage abstention rule both looked promising on paper. Both got built, both got tested against the locked set, and both came back NO-GO: the classifiers they were meant to second-guess are confident enough that a threshold catches almost nothing real while occasionally suppressing correct answers. I removed them.

There was also a retraction. Earlier in the quarter I'd said nutrient problems were my single biggest error source, and that a “nutrient brake” had validated as a win. Re-measuring with the nutrient specialist properly loaded into the test harness overturned both claims. The earlier result had been reading the wrong confidence signal – a bug in the test setup, not a real weakness in the model. Once it was fixed, accuracy went up, nutrient-specific errors dropped by about 55%, and my biggest remaining weak spot turned out to be somewhere else entirely. Walking back a number you've already said out loud isn't comfortable. But a diagnosis company that won't retract its own bad measurement has no business asking growers to trust its good ones.

Why one photo often isn't enough

A lot of plant problems look alike. That's not a model limitation – it's a property of the plant. Different root causes converge on the same visible leaf symptom, which means a single RGB photo sometimes physically does not contain enough information to separate them.

The clearest example is watering. Both overwatering and underwatering can produce yellowing that looks exactly like nitrogen deficiency. Overwatering starves the roots of oxygen, which impairs their ability to take up nutrients; underwatering cuts off the soil-water flow that carries nitrate to the roots in the first place. In both cases the leaf says “nitrogen,” while the real fix is the watering can. The same trap shows up across the deficiency map:

An honest plant diagnosis tool has to respect this. It's why PlantLab returns a separate reliability signal for exactly the ambiguous cases, and why I tell integrators to gate automation on that signal rather than on raw confidence (I wrote that up in detail in Confidence Is Not Reliability).

It's also why I started a new line of work in June on counting and separating plants. I kept seeing photos with more than one plant in frame, and a diagnosis model handed two plants at once can't give either a clean answer. The first version of that work counts the right number of plants about 70% of the time and lands within one almost 90% of the time, fast enough to run on a CPU – early, but it's the prerequisite for diagnosing the messy real-world shots people actually take, not just the tidy single-plant ones.

The unglamorous half: infrastructure and security

Two larger efforts wrapped up in June that don't change a single diagnosis but matter for anyone trusting the service.

I finished moving PlantLab entirely onto European infrastructure and tore down the last of the old US cloud. A plant photo is sensitive – it reveals that someone grows, and at scale, how much – so the data path now runs through providers I chose for sovereignty rather than convenience: compute in Germany, CDN in Slovenia, database and email in France. The full reasoning is in Why PlantLab Runs in Europe. I also built and tested a one-command disaster-recovery rebuild against a live clone, so a lost server is a known, rehearsed recovery rather than a panic.

On security, the runtime container moved to a distroless image, dropping its count of known high-and-critical vulnerabilities from ten to zero, alongside a broader hardening pass – secret rotation, host firewalling, supply-chain scanning, and request-path fixes. None of it is visible in a diagnosis response, which is rather the point.

What I saw at Mary Jane Berlin

I spent the first weekend of June at Mary Jane Berlin, mostly talking with grow-hardware vendors. The headline impression: the industry has decided AI is the next feature, and the race is on. Multiple vendors had AI grow cameras on display, several of them announced that week. The appetite is real and growing.

What's missing is the rigor. Across the floor, the AI accuracy figures were vendor-stated and unaudited, the disclosure of how any of it actually works was thin, and the recurring complaint I hear from growers who've tried the general-purpose-AI route is the same one every time: it answers with total confidence, it's frequently wrong, and it gives you nothing to tell the difference. There is clear demand for “AI something” in cultivation. There is very little supply of AI that's specifically built for the plant, honest about what it can't see, and willing to publish a number it didn't cherry-pick.

That gap is the entire reason PlantLab exists, and Berlin made it concrete. Interest in a rigorous, cannabis-specific diagnosis service was easy to find. Several people I spoke with signed up to try it on the spot.

Where this leaves PlantLab

A month of trying to prove myself wrong left the product in a better place than a month of shipping features would have. I caught a 14-point measurement illusion, killed two things that didn't work, retracted a claim that didn't hold, and came out the other side with accuracy that's higher and honest – 99.96% on whether a photo is even cannabis, 98.4% on healthy-versus-problem, 94.6% end-to-end, all measured on photos the model has never seen, all at 18 milliseconds.

That's the bar I think AI plant health diagnosis should clear before it asks a grower to act on it. Most of the tools shipping right now don't, and they don't tell you that. I'd rather show my work.

PlantLab is free to try at plantlab.ai – three diagnoses a day, results in milliseconds, every diagnosis returns a reliability score so you know when to trust it. API documentation is at plantlab.ai/docs. If you build grow hardware or a cultivation app and want diagnosis that's actually accountable, the API is built to drop into your stack.

FAQ

How accurate is AI plant health diagnosis, really?

It depends entirely on how the accuracy was measured. A number measured on photos the model also trained on is meaningless – it tests memory, not diagnosis. PlantLab's accuracy is measured on a locked, checksum-pinned test set with all training-related images excluded: 99.96% on whether a photo is cannabis, 98.4% on healthy-versus-problem, and 94.6% end-to-end. Most consumer “AI camera” accuracy figures are vendor-stated and not independently audited.

Can AI diagnose a plant problem from a single photo?

Often, but not always. Different root causes can produce identical-looking leaf symptoms – overwatering, underwatering, and true nitrogen deficiency can all yellow the lower leaves the same way. A responsible tool returns a reliability signal that drops on exactly these ambiguous cases, rather than reporting the same confidence on a clear photo and a hopeless one.

Why do AI grow cameras and plant apps get diagnoses wrong?

The common pattern is wrapping a general-purpose vision model and printing its confidence as if it were an accuracy guarantee. A general model handed a plant photo will produce a confident-looking answer whether or not it has any basis for the call. Tools built specifically for the plant, and calibrated against real outcomes, can instead tell you when they're unsure.

What's the difference between confidence and reliability in a diagnosis?

Confidence is how strongly the model picked an answer. Reliability is whether you should act on that answer, on this specific image. They agree on easy photos and diverge on hard ones – which is the whole reason to track reliability separately for any automation. Full explanation here.

Does overwatering cause nitrogen deficiency?

It can produce nitrogen-deficiency-like symptoms. Overwatering deprives roots of oxygen and impairs nutrient uptake, so the plant shows lower-leaf yellowing even when nitrogen is available. Underwatering can cause the same look by cutting off the water flow that delivers nitrate to the roots. In both cases the cause is the watering, not the nutrient – which is why a leaf photo alone can mislead.

Related reading: – Confidence Is Not Reliability: Trust Signals for Automated Plant Diagnosis – Why PlantLab Runs in Europe – How PlantLab's AI Diagnoses Cannabis Plant Problems in 18 Milliseconds

The Short Version

Most plant diagnosis tools show you a confidence number. Confidence tells you how strongly the model picked an answer – not whether you should act on it. Those are different questions, and on a hard photo they get different answers: a model can be very confident and flat wrong. If you're feeding a diagnosis into an automation – a Home Assistant flow, a grow-room controller, a dashboard alert – the signal you actually want is reliability: how trustworthy is this answer, on this specific image? PlantLab returns both. Here's how to use each, and why automation should gate on reliability, not confidence.

The failure mode nobody warns you about

Here's the trap. You wire a plant diagnosis API into an automation. When the model says “magnesium deficiency” with 0.9 confidence, you trigger an action – a notification, a nutrient-dosing routine, a log entry. It works in testing. The clear photos you tested with all return high confidence and correct answers.

Then a real photo arrives: backlit, half in shadow, two plants in frame, taken at midnight because something looked off. The model returns “magnesium deficiency” at 0.9 confidence again. Except this time it's wrong, because that confidence number was never a promise about correctness. It was a statement about how strongly the model leaned toward one class. On an ambiguous image, the model can lean hard in the wrong direction and report a high number while doing it.

A confidence score that's only trustworthy on easy photos isn't a trust signal. It's a confidence display. And the cases where you most need to know whether to trust an answer are exactly the cases where raw confidence is least informative.

This isn't hypothetical. A wave of consumer photo-diagnosis apps has shipped in the last year, and most of them do the same thing: wrap a general-purpose vision model and print a “confidence” percentage next to the answer. The problem is that a general-purpose model handed a plant photo will produce a confident-looking number whether or not it has any real basis for the call – the percentage reflects how hard the model leaned, not how often it's right when it leans that hard. A confidence figure with nothing calibrating it against actual outcomes is decoration. It looks like a trust signal and behaves like one right up until the photo gets hard, which is the moment you needed it most.

Three different questions

The fix is to stop treating “confidence” as one signal and recognize that an automated diagnosis is really answering three separate questions.

Per-class confidence is the model's strength of preference for a specific condition. It's useful when you want to know what the model saw and how it ranked the possibilities. It is not a verdict on whether the overall answer is safe to act on.

Reliability is a single number from 0 to 1 that estimates how trustworthy the entire diagnosis is on this particular image. It's the signal that stays informative on the hard cases – the ambiguous, badly-lit, multi-plant photos where you most need to know whether to trust the result. Higher is better. Low means “something about this image makes the answer shaky, double-check before acting.”

The policy threshold is yours. The API gives you a number; your system decides what to do at each level. That decision is a product choice, not a model output, and it's where the actual safety lives.

Wiring automation to the right signal

The practical rule for any automation: branch on reliability, then use per-class confidence for the details.

A reasonable starting policy, which you should tune to your own tolerance for false actions:

• High reliability (say, above 0.7): safe to act automatically. Update the dashboard, log the plant state, trigger the routine. This is the band where automating saves you work without costing you trust.
• Middle reliability (roughly 0.3 to 0.7): don't act blind. This is the band to ask for a second photo, queue the case for a human glance, or surface a “check this one” flag instead of firing an action.
• Low reliability (below 0.3): do not automate. Show the result as informational at most. Acting on a low-reliability diagnosis is how an automation does the wrong thing confidently.

The reason this ordering matters: per-class confidence will happily hand you a high number in all three bands. Reliability is what separates them. If you gate automation on confidence alone, you'll take action on the 2 AM backlit photo. If you gate on reliability, that photo lands in the “ask for another shot” band where it belongs.

For an integrator, this also means you don't have to build your own uncertainty handling from scratch. The hard part – estimating whether an answer holds up on a given image – is in the response. Your job is to pick the cutoffs that match what your automation does when it's wrong.

Why PlantLab returns a single reliability number

PlantLab used to return rule-based trust fields derived from the model's confidences. Those were removed in favor of a single learned reliability signal, and the API schema was bumped to make the change loud rather than silent. The full migration writeup is linked below.

The short version of why: a trust signal assembled from a handful of rules works on easy cases and falls apart on hard ones, which is the opposite of what you want. A trust signal is only earning its keep on the ambiguous cases – the ones where the answer genuinely might be wrong. So PlantLab consolidated to one number, on one contract: a 0-to-1 reliability score, present whenever the API returns a condition diagnosis, designed to stay honest on the cases that matter.

One implementation note worth knowing: reliability is omitted when there's no condition diagnosis to score – for a non-cannabis photo, or a healthy plant. Treat a missing score as “no score available,” not as a low score. Your automation logic should handle absence explicitly rather than defaulting it to zero.

The product principle underneath

A diagnosis API that always answers, always confidently, is easy to build and dangerous to automate against. The harder thing – and the one I think actually matters – is an API that knows when to slow you down, that can say, in effect, “I have an answer, but this image is the kind where I'm often wrong, so don't wire a pump to this one.”

That's what the confidence-versus-reliability distinction is really about. Confidence is the model talking about itself. Reliability is the system telling you whether to listen. For anything beyond a human reading a single result on a screen – and especially for automation that acts without a person in the loop – reliability is the number to build on.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. Every diagnosis returns a reliability score; the full API documentation lives at plantlab.ai/docs.

FAQ

What's the difference between confidence and reliability?

Per-class confidence is how strongly the model picked a specific condition. Reliability is how trustworthy the whole diagnosis is on this particular image. A model can be highly confident in a wrong answer on an ambiguous photo – which is exactly why you want a separate reliability signal for automation decisions.

Which signal should I use to trigger an automation?

Reliability. Gate the automation on the reliability score (act high, verify middle, don't automate low), then use per-class confidence for the details of what to display or log. Gating on confidence alone will take action on hard photos where confidence is high but the answer isn't trustworthy.

What thresholds should I use?

A reasonable starting point is above 0.7 for automatic action, 0.3 to 0.7 for “ask for another photo or a human check,” and below 0.3 for “don't automate.” These are starting values – tune them to how costly a wrong action is in your setup.

What if the reliability score is missing?

It's omitted when there's no condition diagnosis to score – a non-cannabis photo or a healthy plant. Treat absence as “no score available,” not as a low score, and handle it explicitly in your code.

Does a high confidence number mean the diagnosis is correct?

No. Confidence reflects how strongly the model leaned toward an answer, not whether the answer is right. On clear photos the two usually agree; on ambiguous ones they can diverge, which is the whole reason reliability exists as a separate signal.

Related reading: – How PlantLab Knows When It Might Be Wrong: The reliability_score Field – The schema change and one-line migration – How PlantLab's AI Diagnoses 31 Cannabis Plant Problems in 18 Milliseconds – The pipeline behind the API – Build an Autonomous Plant Health Monitor with AI + Home Assistant – Where reliability thresholds earn their keep

Building on American cloud is the easy choice, which is exactly why almost everyone makes it. One account at Amazon, Google, or Microsoft and you get the whole stack in one place: compute, database, storage, DNS, email, all of it wired together, billed on one invoice, documented to death. It is a genuinely excellent product. It is also where PlantLab started.

It doesn't run there anymore. The diagnosis API, the database that holds your history, and the services around them now run on European infrastructure, and the live path a request travels – upload, inference, response, storage – never leaves the EU. That was not the easy choice. I want to explain why I think the easy choice and the right one were two different things here.

The all-in-one pitch is real, and it's the trap

The reason a hyperscaler is so easy to build on is that it has already solved the hard part for you: integration. You don't think about how your database talks to your storage, or whether your email provider and your DNS provider have ever heard of each other. One vendor owns all of it, so it all just fits. For a solo founder with limited hours, that convenience is worth a lot.

The catch is what you hand over in exchange. Your data, and the rules that govern it, now live inside one American company's estate, under one country's legal reach, no matter which “region” you tick in the console. An EU region of a US cloud is still a US cloud. The convenience and the loss of sovereignty are the same decision – you can't take one without the other.

For a lot of software that trade is fine. For a tool that gets handed photos from real, often licensed, grow rooms, I didn't think it was.

Europe is fractured, and that's the whole point

Here is the honest part nobody puts in the brochure: there is no European hyperscaler. There is no single EU console where you tick a box and get a sovereign, all-in-one stack. So you build it the hard way – you assemble it.

You host compute with one provider in one country. You find a separate DNS and content-delivery company in another. You put your database and transactional email with providers in a third. And before you trust any of them you do the unglamorous research: is this company actually European-owned and European-hosted, or is it a US firm with an EU postcode? Where does the data physically sit? Who can be compelled to hand it over, and under whose law? More vendors, more contracts, more reading, more things that can break.

That fragmentation is real, and it is the cost of sovereignty. The single invoice is convenient precisely because one entity controls everything. The moment you insist that no single entity should, you inherit the work of stitching independent pieces together yourself. I think that work is the point, not a bug to be engineered away.

What the assembling actually produced

Here is where things stand now. Three countries, several independent European providers, deliberately not one console:

The cutover was the careful kind. I ran the new European stack alongside the old one, sent real traffic through it, and verified end to end that a diagnosis written on the new infrastructure could be read back correctly, including the parts that are encrypted at rest. Only then did production point at it. The old environment is still sitting there, frozen, as a rollback target for a while longer, because turning the lights off the same day you cut over is how you turn a migration into an incident.

In an earlier post on data privacy I said this move was in progress and was careful not to overclaim it – the core diagnosis API still ran on a US cloud at the time. That caveat is gone now. The whole live path is European.

Why the hard road

I didn't do this for a marketing line, and I'm wary of anyone who treats “EU-hosted” as a badge. I did it because of what a plant photo actually is.

A photo of a flowering plant gives things away – that you grow, the kind of setup you run, and across enough images, the scale of it. For a licensed European operation that is commercially sensitive information sitting inside a regulatory frame. The question that operator asks before sending anything real is simple: where does my data live, and whose rules govern it? “On servers in Germany, under EU law, with no single foreign company holding the whole stack” is a different answer than “somewhere in a US cloud's European region.”

There is a regulatory tailwind too. Europe's high-risk AI obligations come into force in August 2026, and the broader direction on privacy keeps moving toward stronger consent and more transparency, not less. Building here now, while PlantLab is small and the change is cheap, beats retrofitting it under a deadline later. But the regulation is the tailwind, not the reason. None of this makes PlantLab a compliance product, and you should distrust any small tool that claims a certificate.

The reason is plainer than that. Data sovereignty, privacy, and digital rights belong to the person whose data it is – not to whichever cloud happens to be cheapest to build on. Most companies build on US infrastructure because it's easy and it works, and I understand why. I took the harder, more fragmented road because, for a tool handling this kind of data, the user is the one who matters most. The convenience was mine to give up. The data was never mine to be casual with.

What this changes for you

For most people using the API, the answer is: nothing you have to do, which is the point. The endpoints are the same, your API key is the same, the response format is the same. Inference still runs in milliseconds – the model didn't change, only the building it runs in. A migration you have to think about is a migration done badly.

What it changes is what's true underneath:

• Your diagnosis data is processed and stored in the EU. The live request path stays inside European infrastructure from upload to response, across providers that no single foreign entity controls.
• Sovereignty is distributed on purpose. No one company holds your data, your DNS, and your delivery layer at once. That's harder to run and harder to compromise wholesale.
• The privacy controls travel with it. Bounded, opt-in retention and encryption of the sensitive diagnosis fields ride on top of the move. Where your data lives and how it's held now point the same way.

If you opt in to contributing diagnoses on the free tier, those images are kept in EU storage as well. The default is still minimization: opt-in, bounded, then deleted.

Stated accurately, not stretched

“EU-based” is a phrase that gets stretched until it means a billing address. I'd rather it mean something concrete. Here it does: the request that carries your plant photo is served from Germany, your history is stored in the EU, traffic is measured by cookieless EU analytics, and uptime is watched by EU monitoring – each from an independent European provider. The live path your data travels, in real time, is European end to end. That's the claim, and it's a specific one.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. The full API documentation, including data handling details, lives at plantlab.ai/docs.

FAQ

Where does PlantLab run now?

The diagnosis API is served from Germany, the database and transactional email are in France, and DNS and content delivery run from Slovenia. Analytics are cookieless and EU-hosted, and uptime monitoring runs from France – each from an independent European provider rather than a single all-in-one cloud. A diagnosis request stays inside the EU from upload to response.

Why not just use a US cloud's European region?

Because an EU region of a US company is still governed by that company and, ultimately, by US legal reach over it. Using independent European providers keeps the data physically in the EU and out of any single foreign entity's control. It's more work to run, which is the trade I chose to make.

Did the API change? Do I need to update anything?

No. The endpoints, your API key, and the response format are unchanged. Inference still runs in milliseconds. The move was designed to be invisible to integrators – nothing in your code needs to change.

Why does this matter for cannabis growers specifically?

A plant photo can reveal that you grow, the kind of operation you run, and at scale, how large it is. For a licensed European operation that's commercially sensitive and sits inside a regulatory frame. Data stored in the EU under EU law, across providers no single foreign company controls, is a stronger answer to “where does my grow data live” than data in a US cloud.

Does this make PlantLab GDPR or EU AI Act compliant?

EU-based infrastructure supports those goals but isn't a certificate, and no honest small tool should claim one. PlantLab pairs EU hosting with bounded opt-in retention, encryption of sensitive fields at rest, and cookieless analytics – controls that move in the same direction the regulation does.

Related reading: – A Plant Photo Says More Than You Think: Privacy by Design at PlantLab – What we keep, for how long, and why – How PlantLab Knows When It Might Be Wrong: The reliability_score Field – The trust signal on every diagnosis – What's Wrong With My Cannabis Plant? A Visual Diagnosis Guide – The grower-facing diagnostic hub

The Short Version

I spent two days in May chairing and speaking at World Class Cannabis Business Europe (WCCBE) in Frankfurt, on the subject of visual AI for cannabis cultivation. The biggest takeaway wasn't about the technology. It was about the gap between what the AI industry likes to talk about – autonomy, end-to-end automation, “AI runs the grow” – and what growers in the room actually asked for, which was something much more grounded. They want a tool that helps them decide, not one that decides for them. They want it to be specifically good at plants, not generically good at everything. Here's what I heard, and what it means for where PlantLab goes next.

The setting, and an honest mismatch

WCCBE Frankfurt, May 19-20, 2026. I chaired a day and gave a talk on visual AI for cannabis – the kind of plant-by-plant diagnosis problem PlantLab works on.

The first honest thing to say is that a deep cultivation-diagnosis talk is not the same animal as a policy, regulation, and investment talk, and a conference that spans all of those is going to have rooms with very different centers of gravity. The business and policy sessions are genuinely useful for credibility and for understanding where the industry is heading. But the product conversation – the one where someone tells you what they'd actually use on a Tuesday in their grow room – happens with operators, not in the M&A track. That's not a criticism of the event. It's a note to myself about which rooms the product story belongs in.

With that said, the technical lessons that came out of the operator conversations were sharp enough to be worth writing down.

Lesson 1: Growers want a co-pilot before they want an autopilot

The pitch the AI industry loves is autonomy: the system watches, decides, and acts, and the human steps back. Almost nobody I talked to wanted that as the first step.

What they wanted was a tool that makes their own judgment faster and more confident. Flag the plant that looks off. Tell me what you think it is and how sure you are. Then let me decide. The grower stays in the loop because the grower is accountable for the crop, and because they have context the camera doesn't – what they fed it last week, what the room did overnight, what this strain always does at this stage.

This maps cleanly onto a design choice: the most valuable output isn't a decision, it's a well-calibrated suggestion plus an honest signal of how much to trust it. Autonomy can come later, on the narrow slices where the tool has earned it. Human-in-the-loop is not a stepping stone to be skipped. For most growers it's the actual product.

Lesson 2: Generic AI keeps disappointing growers

This came up again and again, usually as a half-frustrated aside: people have tried asking a general-purpose AI assistant what's wrong with their plant, and it gives them an answer that sounds authoritative and is often wrong, with no signal that it might be wrong.

This is the wedge, and it's a fair one to talk about publicly because it's about outcomes, not methods. A general model trained on the whole internet knows a little about cannabis among a billion other things. It will confidently call magnesium deficiency on something that's actually a pH problem, because the visual distinctions between plant health issues are subtle and the general model never had to get them right. Worse, it presents every answer with the same smooth confidence, so the grower has no way to tell the good answers from the bad ones.

A purpose-built tool earns its place precisely here: it's narrow on purpose, it's measured on how well it does the specific thing, and it can tell you when it's unsure. “Specifically good and honest about its limits” beats “generally capable and uniformly confident” for anyone making a real cultivation decision.

Lesson 3: The near-term home for visual diagnosis is controlled indoor cultivation

Visual AI diagnosis works best where the inputs are consistent: stable lighting, repeatable camera angles, a known set of plants, a controlled environment. That description is controlled indoor cultivation, and it's also where the people most willing to adopt new tooling tend to be.

Outdoor and greenhouse settings introduce variability – weather, mixed lighting, scale – that makes consistent visual diagnosis harder. None of that is unsolvable, but it's the second problem, not the first. The honest near-term answer is that indoor, controlled grows are where this technology delivers reliable value today, and that's where the product should aim first.

Lesson 4: The automation companies need plant-state signals, not another app

A recurring theme in the hardware and automation conversations: the companies building controllers, sensors, and grow-room automation don't need another consumer-facing diagnosis app. They need a plant-state signal they can pull into what they already build.

That's a different shape of product. It says the diagnosis capability should be available as something an automation system can consume – a clean signal of plant condition and how trustworthy it is – rather than only as an app a human opens. The growers running those rooms have already chosen their controllers and their dashboards. The useful move is to feed plant-state into those systems, not to ask everyone to adopt yet another screen.

Where this points PlantLab

Four lessons, one direction. Take the product to the rooms where operators are, not only the rooms where the industry talks about itself. Keep the diagnosis specifically good and honest about its uncertainty, because that's the thing generic AI can't do. Aim first at controlled indoor cultivation, where visual diagnosis is reliable today. And make plant-state available to the automation systems growers already run, instead of competing for their attention with another standalone app.

None of these are surprising in hindsight. That's usually the sign of a good conference – it doesn't hand you a new idea so much as it sharpens the ones you arrived with and tells you which were wishful thinking. The wishful one was autonomy-first. The sharpened one was that being narrowly excellent and honest about it is the whole game.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. If you build grow-room automation and want a plant-state signal to integrate, the API documentation lives at plantlab.ai/docs.

FAQ

What is WCCBE?

World Class Cannabis Business Europe (WCCBE), held in Frankfurt in May 2026, covering cultivation, policy, regulation, and business across the European cannabis sector. I chaired a day and spoke on visual AI for cannabis cultivation.

Why not just use ChatGPT to diagnose my plants?

A general-purpose AI knows a little about cannabis among everything else, and presents wrong answers with the same confidence as right ones. A purpose-built diagnosis tool is narrow on purpose, measured on how well it does the specific task, and can signal when it's unsure – which is exactly what a general model can't do.

Does PlantLab automate my grow room?

PlantLab provides the diagnosis and a trust signal; what you do with it is your call. Most growers want a tool that informs their decision rather than one that acts for them, and the API is built to support that human-in-the-loop use first. It can also feed plant-state into automation systems for the cases where automatic action makes sense.

Related reading: – What's Wrong With My Cannabis Plant? A Visual Diagnosis Guide – The grower-facing diagnostic hub – Confidence Is Not Reliability: Trust Signals for Automated Plant Diagnosis – How to know when to trust an automated answer – Build an Autonomous Plant Health Monitor with AI + Home Assistant – Feeding plant-state into automation

The Short Version

When you send a plant photo to a diagnosis API, you are not just sending a picture of a leaf. You are sending a signal about what you grow, roughly where, and sometimes at what scale. PlantLab treats that as sensitive data. Diagnosis history is kept only if you opt in, only for a bounded window, and the sensitive parts are encrypted at rest. Analytics are cookieless, the supporting infrastructure is moving toward EU providers, and your API key is shown once and never emailed back to you in full. None of this is glamorous. All of it is the difference between an API you can hand real grow-room data and one you can't.

A leaf photo is more revealing than it looks

A single diagnosis request looks harmless: an image, a response, done in milliseconds. But the picture itself gives things away. A flowering cannabis plant in frame implies cultivation. A steady stream of them implies an operation. Add metadata, timing, and volume and you can start to estimate scale. For a hobby grower that's a privacy preference. For a licensed facility it's commercially sensitive – and in much of the world, cannabis cultivation sits inside a regulatory frame where careless data handling is a liability, not just bad manners.

The honest way to think about this is to assume the data matters before anyone proves it does. The cost of treating a plant photo as sensitive is small. The cost of treating it as disposable and being wrong is not.

That assumption is the whole design principle: keep what is genuinely useful, keep it for a bounded period, and make raw database access far less useful to anyone who shouldn't have it.

What we keep, and for how long

PlantLab can show you your past diagnoses through the diagnosis history endpoint. That feature is useful – it lets you track a plant over time and gives integrators a stable record to reference. But I treat history as a choice you make, not a default I impose on you.

• Retention is opt-in. Storing your diagnosis history, and using images for model improvement, happens against a clear consent disclosure, not silently.
• Retention is bounded by tier. History is kept for a defined window – 90 days on Pro, 365 days on Business – and then cleaned up automatically on a nightly schedule. The window is a published number, not an open-ended “until we feel like deleting it.”
• Deletion is the default end state. When the window passes, the record goes. There is no quiet long tail of old data accumulating because nobody wrote the cleanup job.

The principle here is data minimization by calendar. The most private record is the one that no longer exists, and the cheapest way to guarantee that is to delete on a schedule rather than on request.

Encryption at rest, stated accurately

Sensitive diagnosis fields are encrypted at rest. If someone were to obtain a raw copy of the database, the sensitive columns would not be readable as plain text.

I want to be precise about what that claim is and isn't, because “encrypted” is a word I've watched get stretched until it means nothing. PlantLab encrypts the sensitive diagnosis fields – not a hand-wavy “the whole database is encrypted, trust us.” The design uses standard, portable PostgreSQL encryption rather than a proprietary scheme, so it can be audited, reasoned about, and moved between environments without leaning on one vendor's black box. The point is narrow and real: it raises the cost of a database compromise from “read everything” to “read very little.” One layer, described as one layer.

Your API key is yours, shown once

A practical piece of the same posture: PlantLab no longer emails raw API keys. When you create a key, you see it once in the interface, with an acknowledgement step and a rotate button. The follow-up email contains only a safe prefix so you can identify which key it refers to – never the full secret.

This matters because email is a long-lived, widely-synced, frequently-breached store. A secret that lands in an inbox lives in that inbox, on every device synced to it, in every backup of it, indefinitely. Showing a key once in the UI and never transmitting it in full keeps the most sensitive credential out of the least private channel. Sensitive account actions are also recorded in a structured way, so there is an audit trail for the things that should have one.

Cookieless analytics and a move toward EU infrastructure

Two more changes are visible if you look closely at how the site behaves.

The analytics are cookieless. I replaced Google Analytics with a privacy-native setup that sets no advertising cookie, which is why you won't see a cookie wall on the site. It counts aggregate traffic, not individual visitors followed around the web.

The infrastructure is also moving toward EU providers. Over the last few months I shifted content delivery and DNS off a US-centric stack onto an EU-based CDN, and moved transactional email to a provider in France. Analytics are EU-hosted too. This is a migration in progress, not a finished state – the core diagnosis API still runs on major cloud infrastructure today – and it would be dishonest to claim the whole stack has relocated. The honest version: I'm deliberately moving supporting services toward EU-friendly providers, and that work is still going.

That direction is not an accident of taste. Data-protection expectations are tightening, not loosening. The EU's high-risk AI obligations come into force in August 2026, and broader privacy regulation keeps moving toward stronger consent, retention discipline, and transparency about automated decisions. Building the quiet controls now – bounded retention, encryption, cookieless measurement, EU-leaning infrastructure – is cheaper than retrofitting them under a deadline. None of this makes PlantLab a compliance product, and you should be suspicious of any small tool that claims a regulatory certification. It makes PlantLab an API that is moving in the same direction the rules are.

Why bother, when nobody asks

Privacy work is invisible by design. No grower opens an app and thinks, “I appreciate that the diagnosis history is deleted on a 90-day schedule and the sensitive columns are encrypted.” The feature you notice is the diagnosis. The privacy work only becomes visible the day something goes wrong, and by then it's too late to add it.

The reason to do it anyway is that an automation API gets handed real data from real grow rooms. The more useful PlantLab becomes – feeding dashboards, triggering Home Assistant automations, logging plant state over a full grow cycle – the more that data accumulates and the more it matters how it's held. The boring controls are what make the useful version safe enough to actually use.

That's the trade. Privacy work is quiet, it doesn't demo well, and it's the part of building a plant health API that has to be right before any of the interesting parts are worth trusting.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. The full API documentation, including data handling details, lives at plantlab.ai/docs.

FAQ

Does PlantLab store my plant photos?

Storing diagnosis history and using images for model improvement is opt-in, disclosed through a consent step rather than enabled silently. If you opt in, history is kept for a bounded window per tier (90 days on Pro, 365 days on Business) and then deleted automatically. The default posture is minimization – keep what's useful, for a defined period, then remove it.

What does “encrypted at rest” actually mean here?

The sensitive diagnosis fields are stored encrypted in the database using standard, portable PostgreSQL encryption. If someone obtained a raw copy of the database, those fields would not be readable as plain text. It's a specific control on specific fields, not a blanket “the whole system is encrypted” claim.

Is my API key safe?

Your key is shown once in the interface when you create it, with a rotate option. PlantLab does not email raw keys – the email contains only a safe prefix so you can identify the key. The full secret stays out of your inbox.

Is PlantLab EU-based?

PlantLab is deliberately moving supporting services – CDN, DNS, email, analytics – toward EU providers, and analytics are cookieless and EU-hosted. This is a migration in progress; the core diagnosis API still runs on major cloud infrastructure. I'd rather describe it accurately than overclaim a finished relocation.

Why does plant diagnosis data need privacy at all?

Because a cannabis plant photo gives things away – that you're growing, the kind of setup you run, and across many photos, the scale of it. For a licensed operation that's commercially sensitive and often regulated. Treating it as sensitive by default costs little; treating it as disposable and being wrong costs a lot.

Related reading: – How PlantLab Knows When It Might Be Wrong: The reliability_score Field – The trust signal on every diagnosis – How PlantLab's AI Diagnoses 31 Cannabis Plant Problems in 18 Milliseconds – The pipeline behind the API – What's Wrong With My Cannabis Plant? A Visual Diagnosis Guide – The grower-facing diagnostic hub

A single diagnosis tells you what's wrong now. A history of them tells you whether you're getting better.

That's the gap PlantLab's new /history endpoint closes.

When you call /diagnose with a photo, you get back a single answer about a single plant at a single moment. Useful, and also limited. You can't tell whether the answer you got today is consistent with the answer you got last week. You can't tell whether the intervention you ran four days ago made things better or worse. You can't see a pattern across photos because the API forgets each call the moment it returns.

That's the gap /history closes.

What changed

Pro and Business accounts now have an opt-in setting that, when turned on, retains diagnosis history. The photo, the answer, the timestamp, the engine version, all queryable through a new /history endpoint. Pro keeps the last 90 days. Business keeps the last 365. Off means nothing is stored. The default is off.

There's also a Home Assistant sensor exposed for the count if you want it on a dashboard. The endpoint supports cursor-based pagination, which matters more than it sounds once you've been growing for a few months and your history grows past a screen.

What you can do with it today

Three things, on day one.

You can see trajectory. Whether a plant is improving or sliding. The leaf that read nitrogen-deficient last Sunday: is it still showing the same signal this Sunday, or has it moved? A single diagnosis can't tell you.

You can spot patterns across plants. If three different plants in the same tent keep coming back as overwatering, the watering schedule is the variable, not the plants. The room is the constant.

You can audit the API itself. Whether the model is consistent shot-to-shot on the same plant under the same conditions. Two photos two minutes apart, same lighting, same angle, should produce broadly the same answer. /history makes that an inspectable claim instead of a vibe.

What I want to build on top of it

The endpoint is the substrate, not the analysis. The reason it has the shape it does, opt-in, retention-bounded, paginated, machine-readable, is that I want certain things to be possible later. None of them exist today. I'm being deliberate about not promising them on a date.

A simple “this plant has been declining for X days” flag, computed from the history rather than the latest photo alone.

Intervention tagging. Mark a diagnosis with “I tried foliar Cal-Mag” and see whether the next photo improves. That requires a feedback loop the current API doesn't have. /history is one half of it.

Anomaly detection that respects time. A plant that's been healthy for six weeks suddenly returning a confident pest signal is a different event from a plant that's been borderline for six weeks. Without history the API has no way to tell those two apart.

All of those features need the data to exist in queryable form before they can be built. That's what /history is for.

The privacy posture

A stateless diagnosis API is genuinely stateless. You send a photo, you get an answer, the photo is gone. That posture is impossible the moment you start retaining anything, so the bar moves: if you're going to store, you store as little as possible, you make it opt-in, you delete on a known schedule, and you never share with a second party.

That's what /history does. Off by default. The toggle is in your dashboard and on the API. Tier-bounded retention. Rolling deletion.

It also slots into a wider set of changes this month that all point in the same direction. Analytics moved to Umami, EU-hosted, cookieless, no consent banner. The CDN moved to Bunny.net in Slovenia. The signup CAPTCHA moved to self-hosted Altcha. Each one of those moves cuts a third party out of the data path between you and PlantLab. Together they shrink the surface area of who sees what.

The point of all of that is straightforward. Your grow data is yours. The job of an API like this isn't to accumulate it, it's to give you an answer and stay out of the way.

How to use it

If you're on Pro or Business, the toggle is in your dashboard under Account settings. The API exposes the same setting. Once it's on, /history returns your diagnoses in reverse chronological order, paginated, with the same field shape as /diagnose plus a timestamp and the engine version.

Full docs at plantlab.ai/docs.

If you build automations and you've been waiting for a way to compare today's reading against last week's, this is the piece that was missing.

PlantLab's API now returns a reliability_score field on every diagnosis. A number from 0 to 1 telling you how likely the answer is to be correct on this specific image. It replaces the old diagnostic_confidence and safety_classification fields, which were rule-based guesses that I never trusted. The new score is much better at flagging the diagnoses that turn out to be wrong – especially on the hard cases, which is where you actually need it. Schema bumped from 1.x to 2.0.0. If you're integrating with PlantLab today, the migration is a one-line change.

The problem with “confidence” fields

Most diagnosis APIs return a confidence number along with each answer. PlantLab did too. For every condition the model spotted, the response included a confidence value between 0 and 1. On top of that, the response also carried two derived fields. diagnostic_confidence, a single overall trust number, and safety_classification, a three-way bucket of high, moderate, low.

Those derived fields were a heuristic. A small handful of rules that mostly looked at the top condition's confidence and rolled it up into a number. Heuristics work fine when the problem is simple. They fall apart when the failure modes are subtle.

In real traffic, the cases that matter are the ambiguous ones – photos where the answer isn't obvious from the image alone, and a single rule isn't enough to capture how confident the diagnosis really is. That's the slice where a trust signal earns its keep, and the slice where a rule-based composite tends to break.

A trust signal that works on the easy cases and stops working on the harder ones isn't really a trust signal. It's a confidence display.

What reliability_score does differently

reliability_score is a single number from 0 to 1 that estimates how likely the top diagnosis is to be correct on this specific image. Higher is better. Below 0.3 is a clear “double-check this one.” Above 0.7 is “the system is confident and the confidence holds up.”

It doesn't replace per-class confidence. Those still tell you how strongly the model picked each individual condition. What reliability_score adds is a separate answer to a different question – “is the entire diagnosis trustworthy on this particular image, or is something off?”

The analogy I keep coming back to: a junior diagnostician who always gives an answer, and a supervisor who looks over their shoulder. The supervisor doesn't redo the diagnosis. They judge whether each one looks trustworthy. The old diagnostic_confidence was a checklist the junior filled in themselves. reliability_score is the supervisor.

I held the new score to a higher bar than the old composite. On the ambiguous cases, it does a much better job of flagging the answers you should double-check before acting on them. On the easy cases, both fields agree – which is the only place they were ever going to agree, and not where the score earns its keep.

What changes in the response

If you're integrating with PlantLab today, here's what your code currently sees:

{
  "request_id": "550e8400-e29b-41d4-a716-446655440000",
  "schema_version": "1.2.0",
  "success": true,
  "is_cannabis": true,
  "is_healthy": false,
  "growth_stage": "flowering",
  "conditions": [
    { "class_id": "magnesium_deficiency", "confidence": 0.85 }
  ],
  "diagnostic_confidence": 0.85,
  "safety_classification": "high_confidence"
}

After the upgrade, that same image returns:

{
  "request_id": "550e8400-e29b-41d4-a716-446655440000",
  "schema_version": "2.0.0",
  "success": true,
  "is_cannabis": true,
  "is_healthy": false,
  "growth_stage": "flowering",
  "conditions": [
    { "class_id": "magnesium_deficiency", "confidence": 0.85 }
  ],
  "reliability_score": 0.91
}

Two fields removed. One field added. The rest of the response is identical.

reliability_score is omitted when the API doesn't return a condition diagnosis – for example, when the photo isn't of cannabis, or when the plant is healthy. In those cases, there's no diagnosis to score for reliability, so the field doesn't appear. Treat its absence as “no score available” rather than “low score.”

Migration

The change you make depends on what you were doing with the old fields.

If you were displaying diagnostic_confidence to a user, swap to reliability_score. The semantics are the same direction (higher is better, both 0-1), and the new value is more accurate.

If you were branching on safety_classification strings, pick thresholds on reliability_score instead. A reasonable starting point: above 0.7 is “Confident,” 0.3 to 0.7 is “Uncertain,” below 0.3 is “Low confidence.” Your application can use whatever cutpoints make sense – the score is a number, not a string, so you have full flexibility.

If you were ignoring the old fields entirely, the upgrade is automatic. Remove your code that references diagnostic_confidence or safety_classification (it'll get null going forward) and you're done.

The Home Assistant integration shipped a new release the same day as the API change, so existing HA users get the new sensor automatically. If you're using a custom integration, update it before the next API deploy if you can – sensors that read the removed fields will return null until the integration is updated.

Why a breaking schema, not deprecation

I considered keeping diagnostic_confidence and safety_classification as deprecated fields, returning the old values alongside the new score for a release or two. It would have spared everyone a migration step.

But it forces consumers to choose between two trust signals that can disagree. The old composite says “low confidence” on a photo where the new score says 0.95 – which do you trust? Worse, deprecated fields stick around for months, and integrators keep reading them instead of migrating. That's basically the entire failure mode of deprecation.

Cleaner break, single migration, no ambiguity. Schema bumped to 2.0.0 to make it loud. If your integration was on schema 1.x, you'll start getting 2.0.0 responses the next time you call the API. Field changes are documented above.

What's next

reliability_score ships as v1. The field semantics stay stable: a 0 to 1 trust score, present on diagnoses that returned a condition prediction. Future improvements land behind that contract. Same field, more accurate values, no code changes on your end.

If you migrate now, you're done with the migration.

PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. The full API documentation, including the OpenAPI spec, lives at plantlab.ai/docs.

FAQ

Do I have to migrate immediately?

You'll start receiving schema 2.0.0 responses the next time you call the API. If your code reads diagnostic_confidence or safety_classification, those reads will return null. If your code branches on those fields, your branches will fall through to whatever default path you wrote. So the migration urgency depends on what your code does with null values – some integrations will degrade gracefully, others will break.

Is reliability_score the same as confidence?

No. confidence (still present in conditions[] and pests[]) is the model's per-class probability for one specific class – “how confident am I that this leaf shows magnesium deficiency?” reliability_score is a separate signal that estimates how likely the entire diagnosis is to be correct on this image. The two answer different questions, and you can use both.

What does it mean when reliability_score is missing?

The score is only computed when the API returns a condition diagnosis – that is, when the photo is cannabis and the plant is unhealthy. For non-cannabis photos or healthy plants, there's no condition prediction to score, so the field is omitted. Treat absence as “no score available,” not as a low score.

How is this different from just thresholding on confidence?

Per-class confidence values are the model's individual outputs. They tell you which classes were predicted strongly. They don't tell you whether the diagnosis as a whole holds up on a given image. reliability_score answers that broader question, which is usually the one you actually have.

Can I see PlantLab's diagnosis history for my key?

GET /usage returns daily and monthly counts. For per-request lookup, store request_id from each diagnose response – it's stable, returned in both the JSON body and the X-Request-ID header. Use it for support tickets and feedback submission.

Related reading: – The Work Nobody Sees: How I Ran 47 Experiments to Make PlantLab's AI Better – What goes into making the model more accurate, cycle by cycle – Yellow Leaves, Seven Suspects: How PlantLab Got Specific About Nutrient Deficiencies – The nutrient subclassifier that ships alongside this trust signal – How PlantLab's AI Diagnoses 31 Cannabis Plant Problems in 18 Milliseconds – The full pipeline

Most plant diagnosis tools give you a paragraph to read. PlantLab gives your automation system something to act on.

The model covers 31 cannabis conditions and pests at 99.1% balanced accuracy. Balanced means every class counts equally – a system that nails common deficiencies but misses rare pests does not score well. The output is structured JSON that Home Assistant, Node-RED, or a custom controller can read and act on without a person in the loop.

Why generic AI fails

The first time I tried AI for plant diagnosis, I uploaded a photo to ChatGPT. It told me I had a calcium deficiency. It was light burn. The two look nothing alike if you know what you are looking at, but ChatGPT was never trained specifically on plant images. It is a convincing generalist, and when it does not know, it guesses.

That is what most “AI plant diagnosis” apps actually do. Wrap a general-purpose language model, send your photo with a prompt, return whatever comes back. The output is confident, plausible, and sometimes wrong, and a new grower has no easy way to tell which time is which. It is also something you can do yourself for free, which makes paying for the service hard to justify.

The deeper problem is that even when these tools are right, they hand you prose. Useful for a person reading a screen. Useless for an automation system that needs to decide whether to adjust pH, run a fan, or send you an alert.

What PlantLab detects

The model covers 31 cannabis conditions and pests across four families.

Nutrient issues: nitrogen, phosphorus, potassium, calcium, magnesium, iron, boron, manganese, and zinc deficiencies, plus nitrogen toxicity.

Diseases: powdery mildew, bud rot, root rot, pythium, rust fungi, septoria, and mosaic virus.

Pests: spider mites, thrips, aphids, whiteflies, fungus gnats, caterpillars, leafhoppers, leaf miners, and mealybugs.

Environmental: light burn, light deficiency, heat stress, overwatering, and underwatering.

Every class scores above 95% detection accuracy, including the rarer ones.

What you get back

{
  "request_id": "550e8400-e29b-41d4-a716-446655440000",
  "schema_version": "2.0.0",
  "success": true,
  "is_cannabis": true,
  "is_healthy": false,
  "growth_stage": "flowering",
  "conditions": [
    { "class_id": "bud_rot", "confidence": 0.92 }
  ],
  "pests": [],
  "reliability_score": 0.88
}

Not a paragraph for a person to read and interpret. A machine-readable signal. Your controller sees 92% confidence on bud rot in a flowering plant and can ramp airflow, send an alert, or log the event – keeping you informed without forcing you to step in every time.

reliability_score is a separate trust signal on top of per-class confidence. It estimates whether the entire diagnosis holds up on this specific image, which is most useful on the hard cases – mixed symptoms, lookalike conditions, edge-case growth stages. There is more on it in How PlantLab Knows When It Might Be Wrong.

What's new in this release

The previous version of the model covered 24 conditions. This release brings it to 31. The additions came from what growers actually run into and ask about.

Bud rot is one of the worst things that can happen during flowering. Dense colas plus humid air invite Botrytis, and by the time you can see it with the naked eye, it has often already spread.

Heat stress causes leaf curling, foxtailing, and bleaching that new growers often confuse with nutrient issues. Splitting it into its own class prevents the misdiagnosis.

Fungus gnats are usually the first pest a new indoor grower meets. Caterpillars, leafhoppers, and leaf miners are common outdoor threats. Mealybugs are less common but brutal once they take hold. All five now have dedicated detection.

Boron, manganese, and zinc deficiencies fill out the micronutrient coverage. Less common than the macros, but harder to spot by eye because their symptoms overlap with other conditions.

A diagnosis that surprised me

I sent a sample of recent images through the live service to spot-check it against my own intuition.

One result stood out. The photo was a plant that looked underwatered – drooping, leaves curling, the classic signs. The model called it overwatered. I was ready to write that off as wrong, then I went back through earlier photos. The plant had been chronically overwatered for weeks. That ongoing stress had caused nutrient lockout, which then progressed into something that looked like underwatering. The model caught the underlying cause. Without that, I would have treated the symptom and made the problem worse.

What's next

A few things in the queue.

Multiple concurrent conditions in one image. Plants can have spider mites and a calcium deficiency at the same time. Today the API returns the primary diagnosis. Multi-label output is on the way.

Step-by-step automation guides. Home Assistant, Node-RED, and others – walkthroughs for wiring PlantLab into the stack you already run.

More real-world data. Photos from real tents, at real angles, in real lighting, sharpen the model on the conditions it actually sees – not just the clean reference shots.

PlantLab is free to try at plantlab.ai. The API returns structured JSON for every diagnosis – plug it into your automation stack and let your grow room see for itself.

Related reading: – Why I Built PlantLab – The origin story – How PlantLab Knows When It Might Be Wrong – The reliability_score field and schema 2.0 – Nitrogen Deficiency in Cannabis: A Visual Guide – Detailed guide for the most common deficiency – Yellow Leaves, Seven Suspects – Specific nutrient identification – API Documentation