Mender OTA on the ESP32, Part 1

The “DNA” of Mender has two core ingredients: first, care about connected device security and second, care for the users responsible for device management. Security and people go in tandem: The right people should have the ability and knowledge to provide secure devices. The accessibility of the Mender API documentation and the open source-based device client enables this.

One of the most prominent platforms for creating connected devices is the ESP32 series by Espressif. This platform comes with excellent software support, offers WiFi connectivity, and, last but not least, a very competitive price for both the module and development kits. This combination made it the solution of choice for many hobbyists and makers, many professionals and device manufacturers.

Now, with all those devices already around, how to update them securely and robustly? One of our community members, Joël Guittet, development engineer for MCUs at Witekio, wondered about the same challenge and started designing a solution that is both proven and offers the most significant degree of flexibility.

Joël’s wishlist

Here is his wishlist:

• Being able to self-host everything for development purposes under a liberal license
• Having a hosted and managed alternative to migrate upon completion of development for long-term operation
• Having a fully documented requirements for the client device to connect and update

Looking for a solution to tick all the boxes, he found Mender.

So he started looking into the pieces he would need to implement to put a Mender-compatible client onto his ESP32 development board. And he got in touch with us! We talked about how artifacts are constructed and transferred and what we could improve to help him.

Precise packaging inside the artifact

Throughout Joël’s work on the integration, one of the fascinating topics was how the update payload was packaged so precisely inside a Mender artifact. The key is, again, openness. Instead of inventing something on our own, the artifact format is a carefully constructed tar file. It can be read right from the beginning, even as a stream, and from there, "jump" to the relevant sections without downloading the whole artifact in advance. Thus, the artifact format is particularly suited for using resource-constrained devices like the ESP32. Additionally, compression of the payload is both optional and configurable. If your update is relatively tiny anyways - just as it is for the ESP32, where we are talking about a couple of 100KByte - you can cut down the implementation complexity even further. Choosing not to compress the artifact payload means your client can use a library to unpack it. It can just take the stream as it is and write directly to the designated storage area, in OTA terms, the "inactive partition." The usual reboot-commit/rollback cycle executes upon completion of the writing.

Joël put all these things into place, and when we saw the first preliminary demo, we were impressed!

Fast-forward then a couple of weeks up to the current day. "Why should I be interested in what he did?" you might ask. The answer is: "You can just go ahead and use it!". Heading over to his example repository on GitHub, you can dive right in and connect your 10$ ESP32-S2-DevKit-M to the Hosted Mender (sign up for a trial here ). Unique gimmick: you don't have to keep it to yourself. Being MIT-licensed, you can even put it into your product. Just remember the kudos note!

We are pretty thrilled about the possibilities this will bring to lower-end devices. Do you also have a use case that might sound crazy? Tell us over at the Mender Hub.

When you finish playing with the example, check back here for the upcoming post on the technical details of the ESP32 integration. We will not only take a look at the code and its design but also at real hardware.

So this is Mender: empowering people to create secure devices.