Validated feature matrix | Crop Steering docs

This table separates what is implemented in the source, what the automated checks prove, and what has been verified on a live installation. Each release's audit, attached to its GitHub release as release-audit-v<version>.md, records what was run for that release and what was not.

Physical water delivery, a completely blank HA installation and a complete live grow-plan boundary handoff remain uncommissioned. Use the user guide for daily workflows and installation guide for prerequisites.

The rows follow the order of the project story: what it watches, how it decides, how it stays safe, what it does, how you see it, how you change it, the AI layer, how you know it is working, and how to start. The website tells the same story with pictures: cropsteering.growlabs.nz/features.

Feature	Result	Evidence and limits
Sensor mapping	Implemented; locally tested	Search existing HA entities by name/ID and inspect readings/units; multi-probe VWC/EC selection. Backend validates domains, units and conflicting valve roles. Device pairing/firmware provisioning is external.
Sensor fusion	Implemented; median with dropout carry-over; unit + real-HA tested	A zone's probes are combined by median (the mean for two), so one wild probe among three or more is outvoted. Readings outside the controller's range are dropped, and a probe silent for 20 minutes is set aside while another still reports. When a probe drops out, the others are shifted by how they last read against it, so the zone reading does not step. Two probes that disagree cannot outvote each other: the zone sensor's `spread` attribute shows it. Room-wide averages remain arithmetic means.
Sensor diagnostics and equipment map	Implemented; browser tested	Measured values, freshness/coverage and configured devices; no unsupported yield/potency score.
Graphical tank and pump overview	Unit/browser tests and live panel verification	Explicit per-room mappings were saved and adopted, and the live panel showed the tank level, EC, pH, temperature and the recorded fill time. Unknown stays distinct from off or empty; a displayed percentage or fill record does not prove physical filling.
Tank level and watering history	Unit and compiled browser tests pass on demo history; not yet seen in a live panel	The mapped level over 12 hours, 24 hours, 3 days or 7 days from Home Assistant's recorder, with each zone's shots on it (valve open times, named by the controller's decision, litres at the configured flow; grouped by the hour across 7 days), the pump's runs, the tank filling, each newer last-fill time, and the tank minimum and refill reminder levels. A passing value recorded while Home Assistant restarts is left out. The dashboard cannot tell a measured level from an estimated one, and the chart says so.
Irrigation: current targets and daily graph	Unit/browser checks and live 2.16.1 navigation pass	When no schedule owns the room, numeric edits and draggable targets share one local draft with the saved reference visible. Active schedules show their effective targets and read-only graph, hiding fallback manual inputs. Missing/stale required snapshots remain unavailable. Existing bounds, mode mapping, room/zone scope and draft/readback protections remain.
Reactive combined planning curve	221 frontend tests and 56 browser workflow groups pass	Current day and Calendar connect VWC/EC references through lights-off and overnight to the next lights-on. Dashed EC interpolates configured phase anchors; it is not a predicted physical EC or salt trajectory. VWC dryback and the separate P3 emergency floor remain explicit. Missing values stay gaps.
Continuous vegetative/generative steering	Implemented; both legacy modes tested	Explicit endpoint profiles interpolate and quantize against HA parameter bounds/steps; canonical scheduled dryback/EC overrides work regardless of the old mode select. Endpoints need grower review.
Different setpoints per zone	Live preservation verified	An in-place upgrade kept every captured numeric setting and control after the engine state was restored. Room and zone sizing and mappings are preserved.
Whole-grow day/week schedule	Implemented; browser and unit tested	Days1-366, independent zone start dates, inclusive range splitting, weekly overview, daily exceptions, import/export and explicit plan-zone synchronization after setup changes.
P1 runs its full ramp	Engine and controller tests pass; not yet observed through a live lights-on	P1 no longer ends on a clock. It ends when the target is recovered after at least `p1_minimum_shots`, or at `p1_maximum_shots`. Deployed live after that day's ramp had passed, so the first live ramp under this rule is still to be observed.
Source-water/interlock/volume/duration gates	Implemented; controller regressions	Includes request-latency duration accounting, blind-path caps, shared-hardware fault latch and recovery. Physical valve/pump behavior remains unverified.
Patient switch read-back	Regression tests; four consecutive live shots closed without a false hold	After a shot the controller reads pump, mainline and valve at 1 s, then every 0.5 s up to 6 s. A Zigbee plug that reported off after 1.6 s had latched false hardware holds on the fixed 1 s read. A pump that never reports off still latches, within a bounded time (tested, not provoked live).
Restart-safe setup	10 regression tests; verified live on 0.14.0	The accepted setup revision is saved with a fingerprint. Live on 20 September the controller was restarted with the engine flag left on and logged "setup revision 4 resumed after restart", then fired its next shot. A newer revision, a changed hardware map under the same number, or a missing or malformed record still needs the engine switched off to accept it, and now says so with a notification. The first start after updating from 0.13.x needs that off-and-on once.
Missing or invalid EC	Implemented; controller/core regressions	Unscaled base VWC watering, suspended EC learning/offset application and degraded status. Salt protection is unverified until EC returns. Configured feed-water gates still apply.
Room on / off	Unit and controller tests pass; verified live on 2.17.1 / 0.14.0	`switch.crop_steering_<prefix>room_active` off stops all irrigation for that room, including emergency shots and the no-probe fallback, raises no alerts and clears its repair issues. Live on 20 September an empty room was switched off: the controller reported `room_off`, every zone read "Room off", and its heartbeat carried `room_active: false`. Switching back on starts a clean cycle in order and keeps water history (tested; not yet exercised live).
Timed manual override	Implemented; lifecycle/service tests	Per-room/zone deadline expires and survives graceful restart/reload. Retrigger/direct switch changes cancel obsolete callbacks. Noncanonical entity IDs are rejected because the controller consumes canonical IDs. Abrupt power-loss persistence follows HA RestoreEntity checkpoints.
Water per zone, plant and proposed runtime	Implemented; unit/browser/controller tested	Total zone litres, average mL per plant and substrate capacity are distinct. Runtime and phase estimates include engine bounds, duration caps, minimum time and truncation; P1 budgets remain conditional. New counters freeze configured flow per shot and use elapsed runtime, including partial aborts. Old totals are preserved. Missing producer data remains unknown.
Catch-test calculator	Implemented; unit/browser tested	Catch-test output is a local proposal; no automatic calibration write or proof of flow.
Batch-tank dosing; climate actuation	Dosing implemented in the integration and controller; controller regressions and real-HA tests. Climate actuation not implemented	Single doses and whole batches for dosing pumps whose own firmware times each dose (Batch-tank dosing): the integration stores each room's dosing setup and its one request, and the controller app does every action, reads back every switch it turns on or off, holds the watering a batch could disturb and any room whose dosing hardware does not read off, switches everything off after a restart (CS-801 to CS-807), and draws what each dose delivered from the stock tank linked to its pump. Tested against a scripted pump, not on real plumbing. The Equipment › Dosing page is its own layer. EC values stay root-zone references; environment controls remain external HA workflows.
All advanced pages in one workspace	Implemented; live 2.16.1 navigation verified	One Irrigation workspace opens Current day and Calendar with shared room/zone context, one planning canvas and draft protection. Current day edits targets when no schedule owns the room; an active schedule shows effective read-only targets. Old #/strategy and #/grow-plan bookmarks remain valid. Earlier native-panel navigation was verified on 2.16.1; the consolidated navigation is checked in the compiled demo.
Zone current state and last irrigation	Unit/browser tests and live 2.16.0 verification	Controller status, exact mapped valve state, scheduling phase and timezone-aware last-irrigation events were displayed. Missing/invalid events remain Not reported; sensor update times are not substituted. Switch reports do not prove physical flow.
Current day: recorded zone and projected day	Unit and compiled browser tests pass; seen in the live panel on 2.17.1	The draggable Current day planning graph draws the zone's recorded VWC (this grow-day and the previous one) and pore EC under the targets, with now, peak and trough, on an axis scaled to the readings. P0 dry-on, one P1 riser per shot, the P2 sawtooth and the P3 overnight dry-down are projected from the zone's measured dry-down rate, or a stated nominal rate until it has history. When few or no P2 shots project, the graph says why and names the threshold that gives them. It is a projection, not a schedule or a forecast of plant response. The installed file was verified byte-identical to the release; rendering in the live panel was seen by the operator, not by an automated check.
Combined recorded VWC + EC history	Implemented; browser tested	Independent axes/units, zone selection, HA Recorder data and honest missing-history states. Sensor history requires Recorder retention.
Run comparison with daily target overlays	Implemented; browser, unit and metadata-service tested	Day/week/month/run-to-date/custom Recorder ranges; previous run aligned to grow age; repeated full-day target references clipped at now. Stored references are timestamped, not a historical setpoint audit. Retention gaps, stale carry-in, daylight saving, request cancellation and room scope are covered.
Activity view and CSV export	Implemented with evidence limits	Exports available controller/state information. This is not a complete immutable history of all physical irrigation events.
Weekly water usage	Implemented; migration/rollover tests	Seven grow-day controller delivery estimates, including partial aborts; old/missing history is marked incomplete. External irrigation and measured flow are not included.
Native Home Assistant appearance	Implemented; locally tested	Same-origin iframe inherits theme variables and reacts to host theme changes. Roboto and its license are bundled. Explicit light/dark overrides and standalone fallback are supported. Cross-origin inheritance is unavailable by browser design.
Reviewed manual setpoint writes	Implemented; mocked-HA browser tested	Selected-room bounds, steps and readback remain enforced; partial failures retain drafts. The Current day view hides fallback manual inputs while a schedule owns the room and shows effective read-only targets. Dated changes belong in Calendar.
Persistent plans and safe activation	Implemented; fake-HA tests and independent review	Draft storage, revision conflicts, preview, explicit arming, next lights-on activation/disarm, coherent expiring snapshots and durable required-plan holds. Live draft reads and controller capability are verified. Recipe activation and a full lights-on handoff remain uncommissioned.
User-authored recipe library	Unit and compiled browser tests pass	Production libraries start empty; named plan copies remain separate by room and demo/live mode. Loading is a local draft operation with zone/date protection and existing validation/review. Import bounds, storage corruption and HTTP LAN UUIDs are covered. No source-guide numerical presets are included. See library and references.
Auto Setpoints	Unit, runtime, engine-twin and real-HA tests pass; learning runs live	Off by default. The learner (ceiling, gain, dry-down) always runs and is published per zone. With the room's switch on it rewrites only that zone's own target numbers in bounded steps, never while a dated plan owns the room, and a learned P1 target rises at most 2 points a grow-day, only after that day's ramp reached it: on 22-26 Sep 2026, before that limit, it took Room A zone 3's P1 target from 40.9 to 74.5. Under Jev's Setpoints judge it writes only the P1 target and field capacity; the learner never moves the rescue floor; the judge owns the P2 shot size and re-water threshold. Without the judge, the optional Cloudflare `typesafe/jev` check is consulted on a plateau and once an hour in P2 (bounded nudges to P2 shot size and the working peak); irrigation never waits on it. The 2-point limit and this split are tested, not yet run live.
Optional scoped MCP server	18 protocol tests; live reads and reviewed setup saves verified on a two-room installation	Local stdio tools are documented in Configure Crop Steering through MCP. Tank-mapping proposals completed preview, apply and read-back on a live installation, and its controllers acknowledged the new setup revision. Other writes are limited to reviewed setup or draft-plan saves. No generic actuation, engine enabling or plan activation.
Who gets which alerts on which phone	Implemented in the integration and controller; unit, controller and real-HA tests. Not yet seen on a real phone or a live install	Each phone's row ticks the kinds of alert it gets (emergencies, hardware lockouts, sensors and drift, watering stopped, phase changes, stock tanks, dosing, Jev, setup and settings), for every room or some (Notifications: who gets which alerts). The integration keeps one setup for the site and sends each push to the phones that ask for it, tagged so a repeat replaces the last one, and a critical code as a high-priority push; its own Repairs cards go out the same way. The controller hands each alert's push to it, and pushes to its own notify_service option only while no phone is set up or when that call fails, so an install that never sets a phone up behaves as before. Phase changes and Jev's setting changes go to the phones that ask for them, and CS-209 says when a room with its lights on has watered nothing for a set number of hours. Tested against mobile_app-like notify services in a real Home Assistant. The Settings › Notifications page is its own layer.
Complete usage documentation	Source workflow audit	User guide covers mapping, overview/tank/zone status, local edits, HA drafts, recipes, runs, water estimates and failure states. Documentation is not physical commissioning.
Live deployment	Each release is installed and verified on a live two-room installation after promotion	The installed integration files are checked byte-identical to the release tag and the running controller's code against the tag; heartbeats and settings are compared before and after; the dashboard the installation serves is compared with the public demo.
Installation shortcuts and sidebar	Live in-place upgrade verified	HACS download, Supervisor app update, HA restart, both room entries loading and the automatic native sidebar passed. First installation on a blank HA instance remains untested.
HA sidebar integration	Five host-fixture checks and live 2.16.0 panel check pass	The actual native HA panel hid the HA sidebar and the Home Assistant button revealed it. Fixture checks cover desktop/mobile recovery, restoring the prior temporary state and preexisting kiosk state. Saved sidebar preferences are unchanged; unsupported embeddings retain normal navigation. See Inside Home Assistant.
Room and zone creation/removal	Implemented; flow/API/browser tested	Removal archives stable IDs; restoration preserves identifiers. No automatic renumbering or reuse. Engines and implicated equipment must be readable OFF for mapping mutations.
Interactive demo	Unit and compiled browser tests pass	Synthetic rooms/readings, two sample recipes for untouched demo libraries, and current/previous/archived run examples. Reset restores in-memory examples while retaining browser recipes/live connection data. Production libraries remain unseeded. The compiled browser checks verify initial current/prior curves across day/week/month/run ranges, reset confirmation, and recipe/live-storage preservation.
Yield/potency prediction or autonomous crop optimisation	Not implemented	Removed misleading claims from the active UI. Neither setpoints nor a schematic establish expected yield.

Some facts to know

The answers of the AI assistant are judgements, not guarantees. The log records each answer with its confidence and the action of the code.
The controller calculates the water totals from the settings and the valve time. They are not a measurement.
The dashed lines of the rest of the day are projections. The controller always waters by the probe.
The controller waters by VWC and EC. It does not control the climate.
An update keeps your rooms, settings, counters, plans and the history of the AI assistant.

Improvements that are now practical

Plan every zone across the grow without rewriting daily setpoints by hand.
See what a steering change means before saving, including actual hydraulic assumptions.
Use one curve for planning and a separate combined history for measured behavior.
Keep room/zone identities stable as a facility changes.
Detect unsupported/stale control snapshots and setup adoption gaps instead of displaying false success.
Check dripper output locally and review the proposed correction before changing configuration.

In progress, not in a release yet

Note from the site: this section was not updated at v3.18.1. Most of the items below are released in v3.18.1 and have their own pages under Features; the changelog is the record of what each release contains.

These are built or being built on the parity branches (feat/parity-backend, feat/parity-system) and are not in any release. They get rows above only when they ship.

Shot timeline: every shot in every room on one timeline (done, planned, failed, waiting for the pump), with sensor-driven future shots drawn as expected, not certain.
Timer programs: water mothers, clones and zones without probes on a timer, with the next 24 hours drawn before saving. Timed shots pass the same safety checks.
Pump queue: pump output and zones at once; a shot waits its turn when the pump is busy.
Feed probe calibration and dosing pump prime and calibration: step by step, applied as a corrected reading or a measured flow, and read back.
Probe offsets and curves: applied before a zone's probes are combined.
Journal, put back and undo: every change with who and why; put any earlier value back.
Presets and copy: stored on the controller, with a preview of only the values that change.
Alert rules, alerts inbox and quiet hours: rules as sentences tested against yesterday, open alerts in one place, quiet hours per phone and a multi-phone test.
System status: what is reporting, whether the controller is running, and what has gone silent.
Display units and wall dashboards: EC in mS/cm or PPM, temperature in °C or °F; a Home Assistant dashboard from ready-made cards.
MCP previews: an AI client prepares timers, alert rules, presets, copies and probe offsets as previews that a person applies.

Valuable next additions

Measured-flow reconciliation is the strongest next step: compare commanded litres with independent water-meter deltas and identify blocked/leaking lines. Next, align recorded shot events with VWC/EC history, then quantify planned versus observed dryback over repeated days beyond the available visual comparisons. Reliable measurements would support proposal-only recipe adjustments and cultivar-specific profiles. Those features require clean real observations and have not been claimed as implemented here.

Evidence

Each release's audit is attached to its GitHub release as release-audit-v<version>.md, together with the approval that let it be promoted. The review that shaped the release process is the first-run setup review.

Reproduce the checks using Testing. Machine-readable browser results and screenshots are generated in the ignored output/playwright folder.