Managing OTA Updates for Multiple IoT Hardware Variations

Every IoT fleet needs Over-the-Air (OTA) firmware update support and Golioth offers that by default for projects. When all your devices are exactly the same, it’s not too tricky to manage the rollout. But life is messy, and chances are you’ll eventually have different types of hardware in the field, if you don’t already. Golioth organizes fleets into Cohorts when rolling out firmware updates. Combine that with a package name for each hardware variation and you’ll have solved the challenge of getting the right firmware to the right device.

A Real-World Example

Chris Gammell has designed a great line of custom boards for Golioth to use when standing up an IoT fleet. We call these boards the Aludel, and have both the Elixir and Mini models. With the Aludel Elixir model there are two variants that have different hardware and slightly different chips.

The challenge comes when you learn that all of these device types are running the same Nordic nRF9160 cellular modem as the main processor. So it is entirely possible to send the wrong firmware to one of these boards. It will flash, and will probably run, however the expected pin assignments are going to be different from one device type to the next. None of the peripheral devices are going to work!

To solve this, give each different hardware variant its own unique package name.

Firmware: Assigning Package Names

This will work with all of the platforms supported by the Golioth Firmware SDK. Set the Kconfig symbol below to your chosen package name.

This should be done for each unique hardware and firmware combination. If you’re using Zephyr, add the variants to a boards/board_name.conf file:

CONFIG_GOLIOTH_FW_UPDATE_PACKAGE_NAME="aludel-elixir"

This hard codes the package name into this particular firmware. That means that the device will only look for this package name when receiving an OTA manifest from the cloud. If you happen to deploy the wrong package to a Cohort, the firmware update subsystem on your devices will ignore it!

Cloud: Creating, Uploading, and Deploying Packages

Regular readers of the blog may remember that I posted about multi-image OTA back in April. In that post, I detailed how to deploy multiple images to a single Cohort. Of course that still applies here, but instead of using main as your firmware update package name, use the unique name you built into your firmware.

In the Golioth web console, navigate to your project and create one package for each of the unique package names you have used in your firmware build. Above you can see I have created two: aludel-elixir and aludel-mini.

Now that my packages have been created, I can click on the package name and use the New Version button to upload a version. Input the version number, choose the binary to upload, and hit the Upload New Version button.

Finally, navigate to the Cohorts entry on the left sidebar, choose your desired Cohort, and click on the Deploy button. You’ll be greeted with the dialog shown above. Choose your desired packages and versions; you will be limited to the packages that have already been uploaded to the Golioth platform.

Click Next to review your changes, and if everything looks okay click Start Deployment to roll these out to the fleet. More precisely, roll it out to this Cohort of your fleet!

As with all features on the Golioth cloud, this is available via the Golioth REST API. Pair up cohorts, package names, and CI/CD pipelines and you really start to line up a bulletproof system to ensure the right firmware goes to the right place.

Organize Your IoT Before It’s Too Late!

Planning for OTA begins long before your devices are in the field. If you wait, the problem can quickly scale to an unmanageable mess. Golioth delivers a powerful OTA experience that is simple to use thanks to Packages, Cohorts, and Deployments.

Golioth is free for individuals so give this approach to OTA organization a try today! We’d love to hear how it goes so let us know on the Golioth forum.