Skip to main content

OTA Firmware Upgrades

Over-the-air updates let you ship firmware to devices already in the field. In ESP RainMaker Neo an update is an AWS IoT job: you upload an image, create a job that targets specific nodes or a node group, and the job tracks each device's progress to completion or failure.

What the user sees​

Nothing, ideally. Updates are initiated by you, not by the device owner — there is no "update available" prompt in the phone app. A well-behaved device updates and reboots during a quiet moment, and the owner notices only that a bug is gone.

What the operator must do​

From the Admin Dashboard, under OTA:

  1. Open Images and upload the firmware binary, filling in the metadata the form asks for — name, version, type, model and platform.
  2. Once it appears in the list, start a job from that image and choose the target: a single node, several nodes, or a node group.
  3. Watch progress under Jobs, or on a node's own OTA Jobs tab.

Get version and platform right. They are what stops an esp32c3 build reaching an esp32c6 node, and nothing downstream will catch that mistake for you.

Roll out to a canary group first

Target a small node group before the fleet. A bad image that bricks devices cannot be recalled over the air — the device has to come back for reflashing.

What the firmware must do​

Add the OTA component and enable the service. The device then subscribes for job documents, downloads over the existing MQTT connection as a file stream, verifies, writes to the inactive partition and reboots into it. Rollback on failed self-test, signature verification, and resuming an interrupted download are all supported and configured in firmware — see OTA firmware updates.

Custom file types and custom job documents exist for products that need to ship something other than an application image.

Limits and caveats​

  • The download shares the node's MQTT connection, so MQTT budgeting must be off for OTA builds or the transfer starves.
  • Partition layout must leave room for two application slots. This is a decision made at design time, not at update time.
  • A node that is offline when the job starts picks it up when it reconnects; jobs do not expire on their own.
  • Job progress is only as good as the device's reporting — a device that loses power mid-update shows as in-progress until it reconnects.