Why the AI Does Not Control Relays
The AI does not flip relays. That is the central safety rule.
Iris (our OpenClaw AI agent) writes tactical intent: target bands, hysteresis, misting thresholds, fog escalation, dwell gates, water budgets, and rationale. OpenClaw routes those planning events to Gemma 4 26B A4B (MoE), served locally under the gemma4-26b alias for routine checks and to a larger cloud peer for major reviews. The dispatcher validates and pushes bounded setpoints. The ESP32 firmware decides physical state every 5 seconds and owns the relays.
The exact planner-writable parameters are listed in AI-Writable Tunables.
If the local GPU path is down, the cloud peer is down, Iris is offline, the public website breaks, or the network path to the planner fails, the greenhouse controller keeps running.
Firmware changes to that controller are intentionally harder than content or planner changes. The Firmware Change Protocol documents the replay, invariant, OTA, and rollback gates used before changing the ESP32 path.
Safety Diagram
Reasons over forecast, memory, scorecards, lessons, and known limits.
Accepts only registry-approved writes with trigger and planner-instance metadata.
Clamps, pushes, and checks cfg_* readbacks.
Runs the priority-ordered state machine every 5 seconds and owns relays.
Judges the physical result and exposes failures publicly.
That split is enforced through explicit responsibilities:
Control Responsibilities
Defines the temperature and VPD band the plants should experience through the day.
Reads state, forecast, costs, equipment health, scorecards, previous plans, site context, and lessons; writes bounded setpoints and a measurable hypothesis.
Compares planned values to live readbacks, clamps invalid values, pushes changed setpoints, and records delivery status.
Evaluates the greenhouse state every 5 seconds and controls fans, heat, fog, misters, vent, lights, and pumps.
Measures whether the plan kept temperature and VPD inside band while spending water, gas, electricity, and equipment cycles responsibly.
The Physical Loop
Iris writes a 72-hour tactical plan with waypoints, hypotheses, expected outcomes, and changed tunables.
The dispatcher and schema layer reject unknown, out-of-range, or non-planner-owned parameters.
Changed setpoints are pushed over the local ESPHome native API; the ESP32 also has an HTTP pull fallback.
Firmware runs the priority-ordered mode controller every 5 seconds.
Climate, equipment, energy, water, forecast, and plan outcomes land in TimescaleDB.
The next planning cycle reads scorecards and validated lessons before writing new tactics.
Firmware Safety Shape
The current controller is a priority-ordered firmware state machine, not an LLM loop. The defensible public safety claim is an 8-state controller: 7 non-idle safety/control states plus IDLE, evaluated every 5 seconds with separate relay outputs and hard safety rails.
Fail closed when the controller cannot trust the climate reading.
Emergency cooling shape preempts normal planning.
Emergency heating shape preempts normal planning.
Humidification posture when the greenhouse needs moisture more than ventilation.
Transient vent/fan relief so sealed misting cannot trap heat indefinitely.
Fan/vent posture when heat rejection or outdoor exchange is the right tradeoff.
Ventilation branch when VPD is below the safe band and excess humidity needs to leave.
No-action branch when readings are trusted and the greenhouse is inside the safe operating band.
Safety rails and transient relief preempt normal tuning. The planner can make the controller more or less aggressive inside allowed ranges. It cannot remove the firmware’s hard boundaries.
Those allowed ranges and defaults are documented in AI-Writable Tunables.
What Happens When Things Fail
The ESP32 keeps enforcing the most recent valid setpoints and safety rails. The public plan archive shows the gap.
Local firmware continues running. Public data freshness degrades visibly through the data-health cards.
The dispatcher and tunable registry constrain values before they reach the controller. Readbacks and clamp logs make silent failures visible.
Firmware and alerting favor safe shapes when core readings go stale or invalid.
The ESP32 continues on last confirmed values; freshness and readback checks make the gap visible before new planning claims are trusted.
Boot defaults are bounded by safety rails; dispatcher readbacks show whether the live controller has recovered the active plan.
Equipment-state telemetry, cycle counters, alerts, and operator checks expose physical systems that no longer match software intent.
If sun, outdoor humidity, vent area, or cooling capacity cannot meet the band, the scorecard records stress instead of pretending the plan worked.
Why Not Direct LLM Control?
Direct LLM relay control is the wrong abstraction for a greenhouse. Relays need deterministic timing, hysteresis, interlocks, and safety preemption. Iris is useful here because it can weigh context: forecast, crop needs, prior failures, plan memory, cost, water, equipment state, and the documented physical constraints of the room. It is not useful as a 5-second relay loop.
The pattern is edge-safe and cloud-smart:
Routine OpenClaw events can run on Gemma 4 26B A4B (MoE), served locally under the gemma4-26b alias, using greenhouse memory and retrieval context.
Major reviews can route to a larger model when the planning event deserves deeper reasoning.
The ESP32 runs the deterministic control loop and owns relay state.
Every plan is judged by measured telemetry and a public scorecard.
Future Autonomy Ladder
Verdify’s autonomy should increase only when evidence supports it.
| Level | Meaning | Verdify status |
|---|---|---|
| L1 | Monitor and explain | Done: dashboards, scorecards, alerts, lessons. |
| L2 | Recommend bounded tactics | Done: Iris writes bounded plans with hypotheses. |
| L3 | Execute bounded tactics automatically | Current: dispatcher applies validated tunables while ESP32 owns safety. |
| L4 | Optimize with counterfactual/simulator support | Future: replay recent telemetry before considering RL or simulator-trained policy. |
No roadmap item bypasses the firmware safety layer.
Next: FAQ answers the launch-thread objections directly.