The sample code looks for a certificate named ca_cert.pem which has to be shipped with the firmware itself. If this is done, your device should try to start the update, but fails due to an error with certificates, which we will fix in our next step. For exampleĪlso you could make this URL configurable due to device twins as well.Īfter that, we have to write a function, which concatenates the firmware upgrade URL with the name of our blob file, which we can calculate regarding our device twin property. For a hardcoded URL you could set a sdkconfig property CONFIG_EXAMPLE_FIRMWARE_UPGRADE_URL to the URL of the blob container of your storage account like we did in the configuration step. It’s also necessary to adjust the URL which is used to look for the new binary file. For example, there is a function validate_image_header which will compare the current running firmware version number with the version number of the new binary file. The OTA class should handle all checks regarding the update. The OTA now has nothing to do with azure itself so we could look for integration examples at the ESP-IDF repository. We are using the partions_two_ota.csv which is delivered out-of-the-box from ESP-IDF and tells our microcontroller where the partitions are located and which partition is used for the over-the-air firmware file. So we will name our File “v1_1_0.bin” and upload it to the created blob container with public accessibility. We recommend to use “ Semantic Versioning 2.0.0” which introduced a versioning. We should name our files with a version number for easier access by the device itself. It’s necessary to configure the container with “Blob (anonymous read access for blobs only)” as access level. Blob StorageĪfter we’ve built a new version of the binary file for the device update, we need to create a new Azure Storage Account with a simple blob container named firmware. This could be a boolean flag like updateRequired or better updateVersion as string, which indicates the update version number like “1.1.0” for a minor update. To let the device know an update is ready for it, we can simply set a desired property on the device twins, which will be synchronized with the device itself. We need to focus on the desired properties, because they can be access by the device and the IoT Hub. The structure consists of tags, desired and reported properties. The device twins are mapped in the Azure IoT Hub as JSON data structure. In the following article we will go into more detail about the update process via device twin properties. You can use direct methods to start the update process on the device. On the other hand, if you want to update individual or very different devices, keep it simple and put in as little effort as possible. These also have the advantage that the device is simply given the option of when to start the update process, but more on that later. We speak of roll-out, when we give several devices the opportunity to download and install the update at the same time. If we have a lot of identical devices that should always be kept up to date, it will be necessary to roll out the updates. Here one must differentiate between the purpose of application. OTA IoT Structure Device Twins or direct methodsĪs already mentioned, there are two ways to implement an over-the-air update from the Azure IoT Hub. As storage for our binary firmware files, which we would like to offer to our devices, we configure a simple Azure Blob Storage, which makes our binary files available to the outside world. Of course, this is not enough, the OTA update function must also be available on the device itself. Via the IoT Hub, we have the option of using device twins and direct methods. With regard to Azure, IoT devices are always connected to an IoT hub, whether via a transparent edge gateway or with a direct connection. When managing IoT devices in relation to Microsoft’s Azure IoT Hub, we are explicitly looking at the management of OTA updates in this blog post. This is where it comes to over-the-air (hereinafter referred to as OTA) updates. Unfortunately, this is not possible as it would require dismantling the entire machine. Normally, to apply this update to a microcontroller you would need to link it to an USB port on a PC. from anywhere in the world.įor example: Imagine we got a machine in a big production hall which could be updated to a new firmware. One of the biggest reasons to get devices in the cloud, in addition to process millions of sensor data in near real time, is the ability to manage the devices online, i.e. How to implement configurable over-the-air updates on ESP32 based microcontrollers using Azure IoT Device Twins
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |