ESP32 OTA firmware updates over Wi-Fi have no standard rollback-on-failure mechanism in the Arduino framework, so a buggy OTA push to deployed sensors can brick devices that are physically inaccessible

ESP32's OTA (Over-The-Air) update capability is critical for deployed IoT devices — you can't physically plug a USB cable into a sensor mounted on a roof or inside a wall. The ESP-IDF framework has a dual-partition OTA scheme where new firmware is written to an inactive partition and the device boots from it only after verification. But in the Arduino framework — which is what 90%+ of hobbyist ESP32 projects use — the OTA implementation lacks a robust automatic rollback mechanism. If the new firmware boots but has a bug that crashes the Wi-Fi stack (so it can't receive another OTA update), or if the update partially transfers due to a flaky Wi-Fi connection and the MD5 check is misconfigured or skipped, the device becomes a brick that can only be recovered with a physical USB connection. For a hobbyist with 3 sensors in their house, this is annoying. For a small startup with 200 units deployed at customer sites, a single bad OTA push can generate 200 support tickets requiring physical site visits, each costing $50-$200 in labor and travel. ESPHome documented a specific bug in version 2025.12.0 where HTTP OTA updates on ESP32-C3 using the Arduino framework consistently failed at ~13% progress with MD5 mismatch errors — meaning any automated OTA push using that version bricked devices en masse until a manual fix (switching to esp-idf framework) was applied. This problem persists because the Arduino framework's OTA libraries prioritize simplicity over safety. The 'ArduinoOTA' library provides no built-in watchdog that reverts to the previous firmware if the new firmware fails to reach a 'healthy' state within N seconds. Implementing proper rollback requires understanding ESP-IDF's partition table scheme, app_rollback_enable configuration, and esp_ota_mark_app_valid_cancel_rollback() API — knowledge that lives in Espressif's C-language IDF documentation, not in Arduino-friendly tutorials. The gap between 'OTA works on my desk' and 'OTA is safe for production deployment' is undocumented in the Arduino ecosystem, and every hobbyist-turned-startup discovers it the hard way when their first batch of deployed devices stops responding after a firmware update.