Operations
This is the live-status hub for Verdify. If you want to know what the greenhouse is doing right now, whether the controller is behaving, whether the plan is being enforced, and whether anything needs intervention, start here. This page is the operational bridge between:
- the physical greenhouse
- the AI planning layer
- the deterministic controller
- the evidence trail in telemetry, plans, and alerts
The exact planner-writable setpoints that bridge the AI layer and controller are listed in AI-Writable Tunables.
Use this for the continuously refreshed command-center view. The static snapshot below is the crawler-friendly public proof layer.
Most runtime, cycle, water, and equipment-now panels on this page come from this dashboard.
Plan, alert, firmware-health, and dispatch proof panels remain here.
This page answers:
- Is the system healthy right now?
- What equipment is running right now?
- How many hours and cycles are the relays accumulating?
- Which devices are carrying the heat, cooling, humidity, lighting, and water load?
- Do we need to intervene?
System health
Top-line indicators: health score, active alerts, controller uptime, connectivity, memory, and today’s cost.
Static public API snapshot: 2026-05-09 13:19 MDT. Source: evidence snapshot JSON, home metrics API, and data health API. These values are public receipts for crawlers and locked-down browsers; use the live Operations dashboard above for continuously refreshed state.
Data-health status
Latest climate age
Open critical/high alerts
Active controller mode
Last plan age
Cost today
Relay state is a point-in-time snapshot of physical outputs only; Grafana below shows the full transition history.
Written 2026-05-09 05:54 MDT; age 59m at snapshot time. The ESP32 continues enforcing bounded setpoints while the plan awaits scorecard validation.
Launch-visible panic condition is clear at snapshot time; firmware reset and component-health panels below remain the live diagnostic path.
Water accounting status is ok; unattributed water remains an instrumentation limitation.
Equipment now
Operations starts with the physical outputs: heaters, fans, vent, fogger, misters, grow lights, and irrigation. This is the fastest way to answer what the controller is currently doing.
What to inspect: which devices are on, when they last changed, and whether the active set matches the expected controller mode.
Runtime and cycles
Runtime hours show sustained load. Cycle counts show relay chatter, control instability, or a device being asked to do many short corrections. These panels are better operational proof than climate summary cards because they show the mechanical burden.
What to inspect: heater runtime, fan/vent runtime, fog/mister runtime, grow-light runtime, and whether cycle counts look proportional to actual weather pressure.
Thirty-day equipment load
The daily runtime mix shows how the greenhouse work shifts across weather regimes: heat during cold nights, fans and vent during solar load, fog/misters during dry VPD pressure, and grow lights when supplemental DLI matters.
What to inspect: which device family dominates the last 30 days and whether the cost-bearing devices line up with the climate story.
Water and misting
Humidity control is an equipment problem as much as a climate problem. The controller has to decide which mist zone to use, whether fog is warranted, and whether water accounting still matches the observed totalizer.
What to inspect: mister zone runtime, water-flow transitions, and whether totalizer movement matches expected misting or irrigation.
Controller state
This is where Verdify stops being a dashboard story and becomes a control-system story. The controller table shows state-machine values, transition context, and whether the live firmware state matches the expected equipment behavior.
What to inspect: controller state, mode reason, active mist zone, lead fan, overrides, and recent transitions.
Active plan
The greenhouse is not just reacting. It is following an explicit plan. The plan record belongs in the generated archive, where the plan id, cycle, rationale, tunables, and later outcome are readable as one document.
Use this for the active plan id, cycle text, tactical changes, and eventual outcome notes.
Use this to understand which planned parameters can affect the ESP32 state machine.
Alerts and diagnostics
When something goes wrong, this is where you verify whether the issue is climate, hardware, controller state, or telemetry.
What to inspect: recent reset reasons, open alert context, and component-level health.
How this fits the site
This page is the canonical operational entry point. If you want:
- broader cost and executive framing, go to Resource Use
- temperature, VPD, safe bands, and zone climate behavior, go to Climate Control
- historical plan decisions, go to Daily Plans
- lessons extracted from incidents and experiments, go to Lessons Learned
Operational target: high system health, fast alert response, safe controller behavior, and a greenhouse that follows the plan closely enough for the lessons to mean something. Open full dashboard ↗