OTA follow-up: align with ESP-IDF best practices (rollback + evaluate pull OTA) #61
Description
Summary
Current web OTA is functionally working and already uses a safe dual-slot layout (otadata + ota_0 + ota_1), but it does not yet fully match the OTA recommendations from Espressif.
What we already have
- Safe app OTA partition layout
- OTA writes to the inactive app slot
- Slot size checks and oversized image rejection
- Improved web OTA state handling, timeout policy, and concurrent upload rejection
What is still missing
- App rollback on first boot validation
- Fast self-test after first boot of a new OTA image
- Optional anti-rollback / secure_version checks
- If we ever move to internet OTA: HTTPS OTA with server verification and optional image signature verification
- Evaluation of device-pull OTA (
esp_https_ota) with resume support for poor/unreliable networks
Why this matters
- Espressif recommends rollback with first-boot validation so a bad OTA image can automatically fall back to the previous working firmware.
- The current browser-upload OTA path is still dependent on the client/browser/network upload path.
- A future device-pull OTA flow may be more reliable on problematic networks, especially with OTA resumption support.
References
- ESP-IDF OTA guide:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/ota.html - ESP HTTPS OTA guide:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32c6/api-reference/system/esp_https_ota.html
Proposed follow-up
- Add rollback support (
CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE) and first-boot self-test flow. - Confirm new firmware with
esp_ota_mark_app_valid_cancel_rollback()after successful diagnostics. - On failure, roll back with
esp_ota_mark_app_invalid_rollback_and_reboot(). - Separately evaluate a future pull OTA path using
esp_https_ota. - If pull OTA is adopted, consider HTTPS certificate validation, optional signature verification, and OTA resumption.
Not urgent. This is a follow-up improvement task for later.