OhioIoT
Menu

OTA Updates

Push new firmware to your ESP32 devices over the air — by group, with rollback — without ever plugging in a cable.

Build a .bin, upload it to a group, and tell the group's devices to update. Each device downloads the image, flashes it, and reboots into the new firmware — or rolls back automatically if the new image won't run.

Groups

OTA is organized around groups. A group is a named bucket of firmware plus the list of devices it's for — "greenhouse-sensors," "v2-hardware," whatever maps to how your fleet actually divides. You create groups in the dashboard, assign device IDs to them, and upload firmware into them.

Each group keeps its two most recent firmware images on hand; older ones are cleaned up automatically. Two is deliberate — the current image and the one before it, which is what a rollback reaches for.

The update lifecycle

From the dashboard, a normal update goes like this:

  • Upload — push your .bin into a group. Max 4 MB, must end in .bin.
  • Notify — tell the group to update. The platform sends each assigned device an OTA message carrying a one-time download credential, spaced about ten seconds apart so a hundred devices don't hit the download endpoint in the same instant.
  • Download & flash — each device fetches the image and writes it to its spare flash partition.
  • Reboot — the device restarts into the new image.
  • Confirm — the device republishes its status; you watch its firmware version tick up on the device card.

Progress streams back to the dashboard live — per device, with a percentage and a phase (downloading, success, or failed) — so a fleet update is something you watch finish, not something you hope worked.

Abort, accept, rollback

Each device exposes three OTA controls from its card, for the moments when an update needs a human:

  • Abort — cancel a download that's in flight.
  • Accept — mark a freshly-flashed image as good. In manual-accept mode a new image is provisional until you confirm it; if you never accept, the device reverts on its next boot. This is your safety net against shipping a build that connects once and then wedges.
  • Rollback — go back to the previous image and reboot.
Manual accept is the difference between "I bricked one device" and "I bricked the fleet." Roll out to one device, confirm it's healthy and accept it, then push the rest.

Uploading from your own build pipeline

You don't have to use the dashboard to upload. The OTA service is reachable over HTTPS at ota.ohioiot.com, authenticated with an auth key, so a CI job can publish firmware the moment it builds:

# upload a new image into the "greenhouse-sensors" group
curl -H "x-auth-key: YOUR_KEY" \
     -F firmware=@build/firmware.bin \
     -F group_name=greenhouse-sensors \
     https://ota.ohioiot.com/upload

Devices fetch the latest image for their group from the download endpoint. The standard ESP32 OTA library can't set custom headers, so the download accepts the auth key as a query parameter:

https://ota.ohioiot.com/download/greenhouse-sensors?auth_key=YOUR_KEY
Only one upload per account runs at a time — a second concurrent upload is rejected. Build pipelines that push several groups should upload them in sequence, not in parallel.

Security model

OTA is the most sensitive thing you can do to a device remotely, so it's worth being explicit about what is protected, what isn't yet, and where the boundary sits.

In transit, everything is encrypted. Uploads and downloads run over TLS, and the auth key gates every request.

On the device, firmware integrity is enforced by the hardware. A corrupted or truncated image won't boot, and the device falls back to the previous image on its own — a bad download can't leave a device stuck.

On upload, you can independently verify what the platform stored is what you sent, by comparing a hash of your local .bin against the stored image. You don't have to take our word that the bytes match — you can check.

On the roadmap: cryptographic signing, so that a device will only accept firmware from an authorized key over the air. Until that ships, the auth key plus TLS are what stand between your devices and an unwanted image.

Out of scope: physical tampering. Someone holding the board with a cable can flash it however they like — securing physical custody of the hardware is part of your deployment, not something a cloud platform can do for you.

The honest one-liner: in transit it's encrypted, on the device a bad update can't run and reverts itself, and on upload you can verify by hash that what we stored matches what you sent. Signing is coming; physical security is yours.

The device side

The device-side OTA flow — receiving the update message, downloading from the group's URL, writing to the spare partition, and handling accept/rollback — is built into the Champion SDK. If you're rolling your own, the moving parts are: subscribe for the OTA message, fetch the download URL with the supplied credential, use the ESP32 HttpsOTAUpdate flow, and republish your firmware version on the next boot so the dashboard can confirm the change.