Data Model

Tzone RS485 climate probe mounted in the south zone, one of six sensors feeding the data pipeline

The data pipeline: ESP32 sensors publish state changes over aioesphomeapi (encrypted, port 6053). The ingestor maps 286 ESPHome object IDs across climate, equipment, state, setpoint, diagnostics, and daily accumulator surfaces, plus 135 cfg_* readback aliases for firmware confirmation. Seventeen periodic tasks enrich and check the data: water-flow sync, materialized-view refresh, Shelly energy, Tempest weather, Home Assistant sensors, alert monitoring, setpoint dispatch and confirmation, forecast sync/actions/deviation checks, daily summaries, grow-light rollups, planner heartbeat, midnight watch, and public inference-infra samples. Everything runs locally on a single VM.

TimescaleDB (PostgreSQL 16 + hypertables) stores every measurement, event, plan, and observation.

Catalog counts below were checked against the live production database on 2026-05-23.

Public Sample Dataset

For public readers who want to inspect the receipts without database access:

30-day hourly performance CSVUpdated daily

Hour-by-hour greenhouse climate averages and equipment runtime minutes. The generated page links to the current dated archive and keeps prior versions in the same folder.

7-day climate sample CSV187,178 bytes; generated 2026-05-23 16:30 MDT

5-minute indoor climate, outdoor weather, hydro, soil, water, and solar fields. SHA-256: 055ae3a41847edccec82c5fc1d9dc00ac5153f2b9eaa7163c390a126aa5d9faf.

30-day plan outcome sample CSV277,122 bytes; generated 2026-05-23 16:30 MDT

Plan scorecards, stress hours, resource cost, hypotheses, expected outcomes, and actual outcomes. SHA-256: 5be16adfb5cb089ca882669219f2ba82892db9fee7a1c70339d3ae0b861d8711.

Dataset notes467 bytes

Timestamp, timezone, and scrub boundary for the export.

The export omits local IPs, device IDs, trigger UUIDs, alert channels, hostnames, and raw sensor entity names.

Core Tables

TableTypeRowsWrite Pattern
climateHypertable273K+~60s batch (ESP32 sensors + outdoor merge)
equipment_stateHypertable118K+Event-driven (relay and switch changes)
energyHypertable526K+Every 5 min (Shelly EM50)
setpoint_changesHypertable86K+Event-driven (ESP32 reports + plan pushes)
setpoint_planHypertable46K+Planner waypoints and tunable updates
weather_forecastHypertable311K+Hourly (Open-Meteo, 16-day, 28 columns)
daily_summaryRegular288Nightly and live summary rows
diagnosticsHypertable146K+~60s (ESP32 health)

Setpoint & Tunable Delivery

The AI planning agent writes future intent to setpoint_plan, not directly to relays. The active value for each parameter resolves through v_active_plan; the ingestor dispatcher pushes changed values to ESPHome and the ESP32’s reported values land in setpoint_changes. Firmware cfg_* readbacks land in setpoint_snapshot, which is the ground-truth table for whether bounded tunables actually reached the controller.

ObjectRole
setpoint_planAI-authored waypoints: timestamp, parameter, value, plan id, source, and reason.
v_active_planLatest active plan value per parameter after supersession.
setpoint_changesEvent log of pushed and ESP32-reported setpoint values; drives fn_setpoint_at().
setpoint_snapshotESP32 configured-value readbacks from cfg_* sensors.
plan_delivery_logTrigger id, planner instance, delivery status, and resulting plan id for MCP audit.
/setpointsLegacy key=value compatibility endpoint that combines active plan values, crop-band functions, lighting policy, activity windows, and direct-wet defaults for diagnostics/recovery tooling. Current firmware uses ESPHome push/readback instead of HTTP polling.

See AI Tunables Traceability for the bounded tunable taxonomy and relay impact.

Crop & Operations Tables

TablePurposeStatus
cropsActive plantings with position, zone, stage8 records
crop_eventsStage changes, transplants, harvests14 logged events
observationsPest scouting, visual notes, camera assessments797 observations
treatmentsSpray/biological applications with PHI/REIEmpty
harvestsYield recordsEmpty
plan_journalPer-plan hypothesis, outcome, score196 entries
planner_lessonsValidated patterns from planning cycles111 lessons

Key Views (113 total)

ViewPurpose
v_greenhouse_nowSingle-row snapshot: all zones, hydro, costs, health
v_equipment_nowCurrent state of 39 equipment-state rows
v_cost_todayReal-time electric + gas + water cost
v_active_planResolves plan supersession (latest waypoint per parameter)
v_band_trace_recentCrop band, firmware-enforced band, cfg readback band, and compliance flags
v_stress_hours_todayHours above/below target bands per day
v_disease_riskBotrytis + condensation risk from RH/temp/VPD
v_mister_effectivenessVPD drop per pulse by zone, with outdoor context
v_forecast_vs_actualHourly forecast accountability (bias detection)
v_indoor_outdoor_correlationThermal gain coefficient
v_state_durationsTime-in-state per day
v_estimated_plant_dliCorrected DLI estimate (sensor × correction factor)

Key Functions

FunctionReturns
fn_equipment_health()0–100 composite health score
fn_stress_summary(date)Human-readable stress text
fn_system_health()4-component health: sensors, alerts, equipment, controller
fn_house_vpd_control_band()Whole-house VPD band derived from crop and zone policy
fn_band_timeline()Actual-to-forecast dashboard compliance band plus traceable firmware-derived trigger/padding thresholds
fn_band_setpoint_provenance()Four-edge source trace: crop target, dispatcher value, firmware push, cfg readback, and latest planner context
fn_band_trace()Canonical sample-level crop/firmware/readback band trace
fn_compliance_pct()% time within firmware-enforced target bands
fn_forecast_dli()Predicted natural DLI from forecast radiation
fn_forecast_correction()Rolling 7-day bias per forecast parameter

The data-model page owns table, view, and function names. Live health and planner outcome panels stay on Operations and the Scorecard so this reference page stays a schema map rather than a second dashboard.

Compression & Retention

TableCompressionRetention
climate7 days365 days
energy7 days365 days
diagnostics7 days180 days
esp32_logs30 days

Where to Go Next

  • Planning Loop — how the AI planner reads this data and writes setpoints
  • Operations — live health checks and data freshness monitoring
  • Lessons Learned — what the data has taught us about greenhouse control