Textile monitoring (weaving)ESP32 PLCWiFiResilience / OTA
WiFi reconnection that never stops the machine monitor
Non-blocking WiFi reconnection is the difference between a monitoring node that rides out network trouble and one that freezes with it. Factory WiFi drops constantly — saturated access points, interference from variable-frequency drives, maintenance windows. This example for the ESP32 PLC retries the connection at most once every 10 seconds without ever stalling the loop, a pattern hardened in a real textile machine monitoring deployment across two production plants.
Check every loop, retry every 10 seconds
checkWiFiConnection() runs on every single loop iteration but costs essentially nothing while connected — one status read and an immediate return. When the link is down, it calls WiFi.begin() asynchronously at most once per 10-second window and never sits waiting for the result to come back. There is no while-not-connected loop anywhere in the firmware, because that classic blocking pattern is exactly what turns a WiFi outage into a full firmware outage.
The real work never stops
While the radio hunts for the access point, the production pulse counter keeps running on its hardware interrupt and every record keeps landing in the daily file on the SD card, exactly as if nothing were wrong. Connectivity is treated as an optimisation, not a dependency — when the network finally returns, MQTT publishing resumes on its own and the buffered files fill in the gap. The machine data ends up with no holes at all.
Drop counters as a health metric
A global connection flag tells the rest of the firmware whether publishing is worth attempting right now, and a counter increments on every connected-to-down transition. Exposed through the embedded status page or the periodic MQTT snapshot, that drop count turns out to be gold for diagnosing plant networks. When one PLC out of the fleet reports forty drops a day and its neighbours report two, you are looking at a weak or saturated access point, not a firmware problem.
A snippet from the implementation
Straight from the example as deployed on the ESP32 PLC — copy it freely:
void setup() {
Serial.begin(115200);
// Plant work: production counter via interrupt
pinMode(I0_0, INPUT);
attachInterrupt(I0_0, [] { pulses++; }, FALLING);
// First connection attempt, also without blocking startup
WiFi.mode(WIFI_STA);
WiFi.begin(WIFI_SSID, WIFI_PASS);
lastConnectionAttempt = millis();
}
The full example is a complete program — wiring header, setup and main loop — ready to adapt to your application.
Frequently asked questions
Why not just call WiFi.begin() on every loop iteration?
Hammering the WiFi stack with connection attempts starves it and can keep it permanently associating. The 10-second rate limit gives each attempt time to complete while keeping recovery fast.
Does this work with MQTT reconnection too?
Yes, the same pattern applies one level up — attempt the MQTT connect only when WiFi is up and the client is disconnected, also rate-limited, and re-subscribe to command topics after every successful reconnect.
How do I avoid losing data while offline?
Write every message to the SD card before attempting to publish. With daily JSON files on the card, an outage of hours or days costs nothing; the data is uploaded or replayed when the link returns.