ESP32 Firmware OTA Update Manager

Once an IoT deployment grows past a handful of devices, "plug in a USB cable and reflash" stops working. Real fleets update firmware over the air — but doing it safely is genuinely hard: a bad image can brick every device at once, an interrupted download can corrupt flash, and there is no technician on site to recover. ESP-IDF provides the building blocks (A/B OTA partitions, bootloader rollback, signature verification), yet students rarely see them orchestrated into a managed process. FirmwareFlow is that orchestration layer as a teaching and demonstration system. A device registry tracks firmware version, active partition (ota_0/ota_1), last check-in and update state per device. Releases live in a signed registry with pinned SHA-256 hashes. Rollouts proceed in canary phases with failure-rate gates, and if a device fails to boot the new image, the bootloader falls back to the previous partition automatically — the exact recovery behaviour production systems rely on. The dashboard makes every step visible: who is updating, who failed, who rolled back, and why a phase gate blocked.

1. Firmware is built and signed with the release key; its SHA-256 hash is pinned in the registry alongside the changelog.
2. The operator creates a campaign targeting a firmware version and the first canary phase (10% of the fleet) begins.
3. Devices download the image in chunks over HTTP/MQTT; each device verifies the SHA-256 hash before marking the image valid.
4. The device writes the image to the inactive OTA partition (ota_0 or ota_1) and reboots; the app must confirm itself after boot.
5. If confirmation never arrives, the bootloader boots the previous partition instead — an automatic rollback, logged on the dashboard.
6. Phase gates check the failure rate and soak time; only clean phases advance, and the operator can halt or roll back the fleet at any point.
7. Interrupted downloads resume from the last chunk, so flaky links waste minimal airtime.

Tech stack:

• ESP-IDF OTA API (A/B partitions ota_0 · ota_1)
• HTML/CSS/JavaScript fleet dashboard
• HTTP chunked firmware delivery
• SHA-256 image verification
• ECDSA release signing (workflow)
• MQTT device status channel (design)

• [Fleet dashboard] Per-device table with firmware version, active OTA partition, last check-in, status (up-to-date / updating / failed / offline) and live progress bars.
• [Signed firmware registry] Releases with version, size, SHA-256 hash, changelog and signature state; release-candidate vs stable promotion workflow.
• [Staged rollouts] Canary phases (10% → 50% → 100%) with automatic failure-rate gates — a phase with ≥ 5% failures blocks advancement until resolved.
• [Automatic rollback] Failed boot verification reverts the device to its previous partition, matching ESP-IDF bootloader behaviour; the event log records it.
• [Halt and fleet rollback] Operator controls to stop a campaign mid-flight or roll the whole fleet back to the previous stable release.
• [Event log] Timestamped record of campaign creation, phase transitions, hash verifications, stalls, rollbacks and offline exclusions.
• [OTA resume] Interrupted downloads restart from the last received chunk instead of from zero, demonstrated in the device firmware.
• [Release pipeline guide] Documented six-step flow: build → sign → stage → rollout → verify → rollback.

• FirmwareFlow web app (fleet dashboard, registry, rollout console)
• ESP32 demo firmware with OTA update support and chunk-resume
• Device registry schema and seed data
• Release pipeline documentation (build → sign → stage → rollout → verify → rollback)
• Project report PDF (background, ESP-IDF OTA internals, rollout strategy, failure handling)
• PPT presentation for final review
• Viva Q&A preparation document (OTA partitions, rollback, signing, staged rollouts)