ProcirelESP32 WiFi That Never Dies: Reconnection Strategies
Demo-grade code connects once in setup() and works until the first router reboot. Production devices must detect drops, back off politely and recover automatically, for months. The difference is about twenty lines of pattern.
> At a glance: 7 minute guide · part 3 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.
## Detect and report state
Here is the working theory in one pass. WiFi. status() tells you the truth: WL_CONNECTED, WL_IDLE_STATUS, WL_DISCONNECTED. Log transitions with millis() timestamps intermittent issues become readable history instead of vibes. An LED or MQTT LWT topic reports health without SSH.
| F | a | i | l | u | r | e | | | | |
| — | — | — | — | — | — | — | — | — | — | — |
| S | y | m | p | t | o | m | | | | |
| F | i | x | | p | a | t | t | e | r | n |
| Router reboot | WL_DISCONNECTED loop | Timed retry with backoff | | | | | | | | |
| Dead spot | Weak RSSI, drops | RSSI logging + antenna/site change | | | | | | | | |
| Sleep wake | No auto re-associate | Explicit reconnect after wake | | | | | | | | |
| Radio stall | status stuck | WiFi.disconnect + restart radio | | | | | | | | |
| Credential change | Auth fail | Fallback config portal | | | | | | | | |
## Reconnect with backoff
Attempt reconnection every few seconds, then stretch the interval (5 s → 15 s → 60 s) so a dead network is not hammered. Reset the backoff on success. WiFi. reconnect() is gentler than begin() from scratch and preserves credentials flow.
## Survive the edge cases
After deep sleep, re-associate explicitly before using sockets. On brownout recovery, validate that the radio actually re-initialised. And design the application layer to queue data during outages reconnection is useless if sensor history is lost while offline.
## How to apply this in your build
Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Track status changes with timestamps in a ring buffer
2. Retry on a backoff schedule, resetting after success
3. Reconnect explicitly after every deep-sleep wake
4. Queue telemetry while offline and flush on reconnect
### Worked example
A garage sensor dropped for hours because reconnect hammered every 200 ms and the router throttled it. Backoff to 60 s reconnected in one cycle after the router rebooted and stopped the lockout entirely. Run the numbers yourself with the Battery Life Calculator and the result should agree to within rounding.
> Practical note from the bench. Every Procirel IoT sketch ships with the same skeleton: status ring-buffer, backoff reconnect, offline queue. Copy it between projects verbatim.
## Pitfalls that cost real hardware
– Calling begin() in a tight loop credential re-read hammers flash
– Blocking loop() while disconnected, freezing local logic
– Ignoring WiFi events (SYSTEM_EVENT_STA_DISCONNECTED) that make state machines clean
## Key takeaways
– Detect and report state the foundation of this guide; revisit it if any measurement here surprises you.
– Reconnect with backoff the foundation of this guide; revisit it if any measurement here surprises you.
– Survive the edge cases the foundation of this guide; revisit it if any measurement here surprises you.
## Who this guide is for
Beginners get a single focused topic instead of a whole textbook chapter. It works as an early stop in the complete IoT and ESP32 guide path. Intermediate readers use it as a reference the table, the worked example and the mistake list answer the questions that come up mid-build. If you teach, the structure (theory, application, example, failure modes) maps cleanly onto a lab session.
## What you need before starting
Nothing exotic: the parts or tools named in the guide, a multimeter. The Battery Life Calculator open in a tab. Track status changes with timestamps in a ring buffer before you begin the guide assumes it and keep the quick-reference table above within sight while you work through the steps.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Detect and report state |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Pitfalls that cost real hardware |
## How this fits the complete IoT and ESP32 guide track
This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [MQTT protocol basics](/tutorial/mqtt-protocol-explained) and [Home Assistant MQTT integration](/tutorial/home-assistant-mqtt-integration). For the arithmetic, open the [Battery Life Calculator](/tools/battery-life).
## Frequently asked questions
How do I know reconnection works before deployment?
Pull the router power mid-run: the log should show drop, backoff attempts, and recovery repeat ten times.
What is MQTT LWT?
Last Will and Testament the broker publishes an “offline” message when the device drops, giving observers instant status.
Is there a calculator for this?
Yes the [Battery Life Calculator](/tools/battery-life) tool runs the formulas from this guide instantly, client-side, with no signup.
## Related guides and tools
– The complete iot, sensors & esp32 guide: [IoT, Sensors & ESP32 complete guide](/tutorial/iot-esp32-complete-guide)
– Read next: [lorawan for beginners: long-range iot without wifi](/tutorial/lorawan-tutorial-beginners)
– Also in this track: [antenna basics for iot: wavelength, gain and matching](/tutorial/antenna-basics-tutorial)
– Continue with: [biomedical sensors: how wearables measure the body](/tutorial/biomedical-sensor-guide)
– Calculate as you go: [battery life estimator](/tools/battery-life) · [LM317 regulator designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
– From here, the natural continuation is the next guide in the track index. It assumes exactly the vocabulary this page built and adds the next layer of practice.
## Verification routine
The fastest way to internalise this topic is to change one variable deliberately and predict the result before measuring. Wrong predictions are the curriculum, they show exactly which mental model needs revisiting, and the bench grades honestly.
Component substitution is a legitimate experiment as long as it is deliberate. Swap one part, predict the effect, measure, and record. That single habit converts a parts bin into a teaching lab and makes every future guide in this track faster to absorb.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## Notes from the bench
Location, then device, then measurement. Document the tree before flashing the first device.
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.