Sketch polling and main loop

How the firmware timer reads DHT22 probes, serves HTTP, and updates the LCD without blocking.

The main loop balances sensor polling, LCD refresh, and HTTP service without blocking any one task for too long. DHT22 reads take hundreds of milliseconds; Ethernet handling must remain responsive enough that dashboard fetches do not time out.

Typical loop structure

  1. Check timer: If the poll interval elapsed, read each DHT22 with retries.
  2. Update LCD: Refresh lines for probe 0, probe 1, and optional average.
  3. Serve HTTP: Parse incoming client requests and return cached JSON.
  4. Watchdog / reconnect: Reset or re-init Ethernet if the link dropped.

Timing constraints

Respect the two-second minimum between DHT22 reads per sensor. Stagger probes if needed. Averaging logic is documented in dual-probe averaging. When reads fail, skip updating that key rather than publishing NaN.

Debugging on serial

Log read failures and Ethernet state during development. After deployment, rely on stale reading diagnostics on the website side. Recovery paths: firmware watchdog recovery.