A greenhouse controller is not just a soil probe and a relay. Sensor placement, crop stage, soil mix, irrigation hardware and network outages all affect whether an alert is useful. Treat the ESP32 as a measurement and control-edge node, SQL as the operational history, and irrigation as a bounded decision that remains visible and overridable.
Calibrate soil sensors in the actual growing medium; a raw analog value is not a universal volumetric-water-content reading. Capacitive probes, installation depth, salinity, temperature and substrate composition change the relationship. Place probes where roots draw water and consider multiple depths; field guidance emphasizes root-zone placement and using soil measurements with irrigation plans, not as a one-size threshold.
Publish measurements and health signals under a device-specific identity. Include UTC sample time, server receipt time, sequence, calibration version, unit and quality flags. On the ESP32, keep sensor acquisition independent of network reconnects; queue a bounded amount of readings and mark gaps when capacity is exceeded. A disconnected node should not block a local safety limit or silently reuse an old measurement.
Keep the first version advisory: generate an alert or recommendation, then let an operator approve watering. If automating a pump or valve later, add independent maximum run time, daily volume limit, dry-run detection, leak response, manual stop and safe power-on state. A cloud rule should never be the only thing preventing continuous pumping.
A simple relational model can separate devices, locations, sensors, readings, irrigation_events and alerts. Store normalized values with units and raw values where calibration may change. Use a uniqueness key such as device, sensor and sequence to make retries idempotent. Constrain required fields and valid ranges, index the time/location lookup path, and retain event provenance so an operator can see which readings and rule version led to a recommendation.
Do not update old readings when a calibration changes; record a calibration version and apply it at ingestion or in a reproducible transformation. Preserve the raw reading and the normalized result so historical trends can be recalculated without rewriting evidence.
A single low sample should not start a watering cycle. Require persistence below a crop- and substrate-specific threshold, add hysteresis before clearing, enforce a minimum interval between cycles and confirm sensor freshness. Combine soil moisture with plant stage, expected rainfall or greenhouse conditions where those inputs are reliable. The FAO describes irrigation scheduling as a combination of soil-moisture monitoring, weather information and a decision-support process; the proper thresholds are agronomic, not universal firmware constants.
| Input/state | Rule behavior | Guardrail |
|---|---|---|
| Moisture below target | Raise a candidate irrigation event | Require repeated fresh readings |
| Sensor stale or implausible | Pause automatic recommendation | Notify operator; never assume dry soil |
| Recent irrigation | Wait for expected infiltration period | Prevent rapid repeated cycles |
| Manual override or leak | Stop or inhibit actuation | Local interlock and logged reason |
Alert on actionable conditions: a zone stayed below its target, a sensor stopped reporting, a valve ran longer than expected, or a post-irrigation reading did not respond. Include location, last value, sample age, threshold/rule version and suggested next check. Deduplicate open incidents and clear them only after a defined recovery condition. A chart should show readings, irrigation events, stale gaps and threshold bands on the same time axis.
Simulate sensor open/short, stuck values, clock drift, Wi-Fi loss, broker/database outage, full device queue, stuck relay, empty reservoir and power interruption. Verify that history distinguishes “dry,” “sensor fault” and “no recent data.” Start with a small plot and compare recommendations against a grower's observations before extending to more zones or crops.
A useful ESP32 greenhouse system combines calibrated sensing, contextual SQL history, stale-data handling, crop-aware rules and safe actuation boundaries. Make each recommendation explainable and every pump action limited, observable and overridable. The goal is not “IoT irrigation”; it is a decision workflow that respects plants, water and equipment.