Implementing over the air updates
Over the air updates is a special kind of action. Read the sections on Creating a new Firmware Version and Triggering OTA update to learn how to upload a firmware file and push it to the device from the cloud. The payload for the OTA action update_firmware is as below:
Notice that payload is json inside a string. Payload json has the following fields of interest:
- content-length: The size of the firmware file
- url: The url from which the firmware file needs to be downloaded
- version The version of the file being downloaded
- Ignore the checksum and status fields. These fields are not implemented on cloud.bytebeam.io and are used by some of our enterprise clients
The client needs to download the file at the url extracted from the payload above using https. Mutual TLS is implemented here as well i.e both the server and the client authenticate each other. The same certificates downloaded in the Connect to Bytebeam cloud section and used for settting up the MQTT connection need to be used here as well.
We could not find a good GUI tool that supports custom certificates to show how to download the above files. However the curl command line tool is available for different platforms and can be used for this purpose. Once curl has been installed you can run the below command to download the firmware file:
In the above command replace ./ca_certificate.pem, ./device_certificate.pem, ./device_private_key.pem and ./file.bin with the full paths of these files on your system.
You can implement OTAs in your client as follows
- When an action with name update_firmware is received handle it as an OTA action:
- Parse the payload as json
- Extract the url field
- Download the firmware using the certificates and private key from the json file downloaded earlier. Optionally send the download progress back to the cloud.
- Implement the actual update. Send progress back during the update and at the end.
It is useful to either have a factory version of the firmware or to store one previous version of the firmware to rollback in case the step 4 fails. In this case it is usefult to send the status as "Failed" and set the errors field to ["Rolled back to version xyz"] to the cloud.
