What should an ESP32 sensor do when Wi-Fi drops?

Wi-Fi loss, an internet outage and an unavailable application are different failures. A device can remain connected to a router while its readings never reach the database. Power loss is another case: software cannot keep measuring without an adequate power source.

Write an operating requirement before choosing storage. For example: keep sampling during a four-hour network interruption, retain the agreed readings and show that remote monitoring is unavailable. This is a hypothetical acceptance target, not a specification or performance claim for a Carras product.

At one reading every 30 seconds, four hours produce 480 records per sensor. If an illustrative measurement payload occupies 96 bytes, the payload alone needs 46,080 bytes. Add identifiers, integrity checks, storage overhead and a tested margin; actual capacity depends on the format and hardware.

Choose what happens when the queue fills: discard the oldest readings, stop retaining new ones or keep a defined summary. Record any loss explicitly. Also distinguish temporary RAM buffering from data that must survive a restart. A network queue is not proof of power-loss protection.

Espressif describes NVS as flash storage for key-value data, best suited to small values. Do not choose it automatically for an extensive measurement log. Evaluate storage layout, write frequency, capacity and recovery, and test interrupted writes on the selected hardware.

Each record should identify the device, measurement sequence, value, units and the time information available when it was taken. Store arrival time separately. Data uploaded after reconnection belongs in the historical record; it should not replace a newer current reading.

Define how identifiers remain unique across reboots. If the clock is not synchronized, preserve sequence and elapsed-time information and mark the timestamp uncertainty. Inventing an exact time makes later investigation harder. Decide when a queued record becomes too old to be useful.

Espressif documents connection events and application-controlled reconnection. Use a bounded retry policy with delays, and distinguish an intentional disconnect from a fault. Restoring Wi-Fi alone does not demonstrate that the application has accepted a reading.

ESP-MQTT retransmits unacknowledged QoS 1 and 2 messages; QoS 0 does not provide delivery acknowledgements. Its outbox has expiry settings. Define the acknowledgement that permits deleting a local record. Receiving a broker acknowledgement does not prove that a downstream database or notification completed.

Use a stable event identifier so a replay does not create duplicate rows or repeated notifications. After reconnecting, send the backlog at a controlled rate while preserving current monitoring. Test failure after receipt but before acknowledgement: it exposes duplicate-handling weaknesses.

The dashboard should distinguish current, stale and unavailable information. Agree how old a reading can become before its status changes. Show the last measurement time and last successful contact rather than leaving an old normal value looking current.

MQTT Last Will can signal an unexpected client disconnect, but it does not establish measurement freshness. Use a server-side timeout as part of the design. An alert delivered over the failed connection cannot be assumed to reach anyone; assign a working notification route and a responsible recipient.

Run an agreed test sequence and compare the device log, stored records and notifications. A useful checklist covers both recovery and the evidence left when recovery is incomplete.

• Remove Wi-Fi while leaving the sensor powered.
• Keep Wi-Fi available but interrupt internet or application access.
• Fill the queue and check the chosen loss policy.
• Restart during pending storage and transmission.
• Replay a record and confirm it causes no duplicate action.
• Recover with an uncertain clock and review timestamps.
• Confirm stale-data and recovery notifications reach their recipient.

Document sampling interval, tolerated outage, retention, expected loss, notification route and recovery criteria. Carras Technologies can assess firmware, local storage and dashboard behavior together within a scoped sensor project. Include these requirements when requesting an assessment, so the proposal covers disconnected operation as well as normal readings.