잘못된 업데이트 되돌리기

Even careful OTA pushes sometimes ship broken code. A solid plan needs a way to roll back to firmware that actually worked.

If new firmware can't connect to WiFi, you lose OTA itself. Without a safety net the device becomes a useless brick.

The ESP32 keeps the old app in one slot while flashing the new one into another. The previous build is still intact if needed.

A fresh update boots in a pending state. Your code must prove it works and then confirm the image so it becomes permanent.

Before confirming, run a quick health check: did WiFi connect, did key sensors respond? Only then mark the build valid.

If a pending build crashes or reboots before confirming, the bootloader quietly returns to the last good firmware on its own.

You can also force a return to the previous image in code with esp_ota_mark_app_invalid_rollback_and_reboot() when a check fails.

A watchdog timer resets a frozen board. Paired with rollback, a hung update reboots straight back into working code.

Stamp each build with a version number you can print over Serial, so you instantly know which image is actually running.

Never push to your whole fleet at once. Update a single canary device, watch it, then roll out widely. 🐤

Worst case, a USB cable still reflashes any board. Design so a bad OTA is an inconvenience, never a permanent loss.

Consider what happens if new firmware crashes before it confirms itself.

Keep two partitions, self-test then confirm each build, lean on auto rollback and a watchdog, and always leave a USB recovery path. 🛡️