The daily sequence below describes the current V3 configuration. For the earlier control designs, see the V1 tests and V2 Ethernet integration.
- ~7:40 p.m.Measure & report
The Transmitter samples both sensors and sends soil status, giving a nominal 20-minute lead before watering.
- 8:00 p.m.Decide & water
The Receiver evaluates soil status and either skips watering or starts the configured run.
- After each eventNotify
The Ethernet ESP32 queues Gmail updates for valve-on, valve-off, or skipped watering.
Times use the installation’s America/New_York local time, including daylight saving time.
Why we chose an 8:00 p.m. schedule →
Transmitter ESP32 · Low-power sensing
The battery-powered Transmitter requests time from the Ethernet ESP32 on each wake, then uses staged deep sleeps to approach the 7:40 p.m. target. It combines the two sensors’ averaged readings into one voltage. See the sampling method and placement tests →
The voltage is rounded to two decimal places before deciding and sending. Above 1.75 V means needsWater = true; at or below 1.75 V means false. Both dry and moist conditions are reported, so “no watering needed” is different from “no report received.”
How Naren’s staged wake-up algorithm addresses sleep-clock drift →
Shared sensor data and consistent decisions
The SOIL_STATUS message carries the needs-water flag and averaged voltage in a shared 24-byte structure. Both boards check the structure’s size at compile time. Normalizing once prevents a value such as 1.995 V from being treated differently when displayed as 2.00 V downstream.
See the air/water endpoint tests and threshold research →
Receiver ESP32 · Watering authority
The wall-powered Receiver stays awake and requests fresh Ethernet time every hour; it does not sleep between requests. It accepts soil reports from 6:00 p.m. until just before 8:00 p.m. At the scheduled decision, a valid moist-soil report skips watering. Otherwise, the garden configuration runs the valve for two hours, including when no report arrives. The needs-water flag controls the decision; voltage is retained for notification context.
How the original variable-duration bands became two-hour runs →
The missing-report fallback prioritizes keeping plants watered, but can water unnecessarily. It requires a valid Receiver clock. Daily state resets at midnight so a previous day’s moist reading does not silently carry over.
Ethernet ESP32 · Time and monitoring
A W5500 Ethernet module obtains a network connection through DHCP. The Ethernet ESP32 gets time through NTP and answers the other boards’ REQUEST_TIME messages with seconds since midnight. It also turns Receiver events into readable Gmail notifications with event time, soil condition, and expected timing.
Acknowledgements, retries, and event queues
A successful radio send is not the same as the receiving application accepting the data. Application acknowledgements and separate queues distinguish those steps.
- Soil report: the Transmitter makes up to three delivery attempts, waiting about five seconds for an application acknowledgement on each attempt.
- Watering events: the Receiver stores up to 16 events in a first-in, first-out queue. It retries the oldest event every five seconds until a matching
EVENT_ACK arrives. - Email delivery: the Ethernet ESP32 acknowledges an event only after accepting it into its separate 16-event queue. It suppresses duplicate events and re-acknowledges them. Failed email sends stay queued for retry at 60-second intervals when connected, and leave the queue after SMTP success.
An event acknowledgement confirms the Ethernet board accepted the event—not that an email reached someone’s inbox. These finite, in-memory queues help with temporary interruptions, but do not guarantee recovery through unlimited outages, queue overflow, or power loss.
What a notification actually means
Events are “Turned On,” “Turned Off,” or “Did Not Activate.” For example, a pre-watering reading of 2.13 V is described as moderately dry and selects a two-hour run in the deployed configuration. The early variable-duration concept would have selected 1.5 hours instead. The later valve-off email carries that same pre-watering reading; it is not a new measurement of the watered soil.
A missing reading is explicitly sent as NO_SOIL_DATA, rather than an invented voltage. Moisture labels in emails are descriptive; the needs-water flag controls watering. A “next watering” time means the next scheduled decision opportunity, not a guarantee that the valve will open.
What happens if time updates or email stop working?
- The Receiver does not know the time yet: it waits for the correct time before starting scheduled watering.
- The Receiver stops getting time updates: if its clock was already set, it can keep following the watering schedule using its own clock. That clock may become less accurate over time.
- The Transmitter cannot get the time: if it is checking when to wake next, it sleeps for an hour and tries again. If it has already reached the wake-up step for taking a soil reading, it still takes the reading and tries to send it. See how the wake-up steps work →
- Gmail cannot send an email: the system saves the notification and tries again later. Watering does not have to wait for the email to send.
