1

I'm currently developing an update strategy for IoT devices running embedded Linux. With Azure Device Update for IoT Hub.
I have read a lot of MS documentation regarding this topic. But I am missing the part of how to connect all services together, so they do what I want.

What I know:

What I want:

  • Send Telemetry data for the device
  • Invoke Methods on the device
  • Deploy an Update Image to my IoT Devices from a central Point (IoT Hub).
  • Automatically start the download when a new Patch is viable.
  • Have one Client App that does all of this.

What I have:

  • The Client Side of the update is implemented with rauc. I just need a way to deliver the update file to the device.
  • I can send Telemetry, edit device Twins and invoke Methods using the iot-sdk-c.
  • I created an IotHub with Device Update and connected my devices with the Device Update Agent
  • I created an Update-Artifact and imported it, and created a new deployment for my target group.
  • I was the able to simulate a successful download with the AducIotAgent.

My Problem:

I don't know how to connect all these parts together so that, when I deploy a new artifact, all compatible devices start the download by themselves, or if I am even on the right path. My next step would be to simply invoke a method which downloads the update file and passes it to my rauc updater, but that would defeat the purpose of Device Update and Update Agent, at least with my current understanding of them. I have an additional problem with the Device Agent which I explained on github, but I don't think that this is related.

Furthermore, I read that the Device Update uses PnP interfaces and in this guide they are using iot-dps to register new devices, but before I read further into these topics I would like to know if is suited for my case.

This Question on MS.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Voxel
  • 55
  • 1
  • 8

2 Answers2

2

Thank you for your questions, please see some responses below.

  1. From your feedback it looks like you have successfully completed an OTA update to your IoT device. Congrats!
  2. We support OTA updates using installers such as: swUpdate for Image (A/B) updates and apt for Package Based updates. So you don’t need to use the RAUC updater if either of these meet your needs. If not, we are interested in hearing your use case and feedback on how we can improve the platform in the future. a. Here are the various update tutorials for reference: i. Image Update: Getting Started with Raspberry Pi 3 B+ Reference Yocto Image
    ii. Package Update: Getting Started using Ubuntu Server 18.04 x64 Package agent iii.Device Update for Azure IoT Hub tutorial for Azure-Real-Time-Operating-System
  3. We don’t yet support the ability for dynamic deployments where compatible devices just start downloading the update without someone manually starting a new deployment from the Portal (or API’s). We will consider this capability for future releases.
  4. Devices don’t need to be PnP-enabled to use Device Update for IoT Hub. However, they do need the Device Update Agent installed, which communicates with the Device Update service via IoT Hub, using PnP device twin properties to orchestrate the update.
  5. Device registration: A device can be registered with IoT Hub using DPS (in production scenarios) or manually with a connection string (for testing). Depending on your use case you can register the device using DPS with the preferred authentication (SAS, TPM, X509 certificate). Next you have to provide the Device Update agent access to your device using the IoT Identity Service or using a config file for testing. Details for how to provision Device Update agent can be found here.
Val
  • 21
  • 1
  • 1. At the moment only on my dev machine cross compiling will be done when everything works as intended. 2. swUpdate was an option but RAUC was better suited for our use case. 3. Maybe my explanation wasn´t clear enough. The manual Deployment part form an Backend App or the Hub is fine. I just don´t want to start the download process on each device manually. 4. So the device agent is a separate program that needs to run on each device in addition to my client app ? 5. Automating the whole update setup will be the next step after the initial testing is done. – Voxel Apr 14 '21 at 06:53
  • For #3: You can group devices in the IoT Hub to deploy an update to multiple devices at the same time. This will start the download process from the Device Update service to the Device Update agent on all devices in the group. See how to group devices [here](https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-groups). Also it will be helpful to review one end to end update from from [this](https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-raspberry-pi) tutorial that walks through the flow of grouping and deploying updates to devices. – Val Apr 15 '21 at 07:49
  • For #4: The Device Update agent works with the service to orchestrate management of updates from the cloud. If your client app includes the Device Update agent you dont need to have a seperate program. – Val Apr 15 '21 at 07:50
  • Thanks for clarifying. Including the Update agent into my client app is exactly what I want. A guide to how I could achieve this would be very helpful. – Voxel Apr 15 '21 at 09:25
2

At this point we do not have a general guideline on how to integrate your existing app/client/module with the update agent, which is something we're working to add very soon. For now I can refer you to some of the relevant pointer in our documentation, which will help you to get started:

Update agent PnP interface: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-plug-and-play

Update agent workflow: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/understand-device-update#device-update-agent

Workflow code reference: https://github.com/Azure/iot-hub-device-update/blob/main/src/agent/adu_core_interface/src/agent_workflow.c

Note that for installation specific implementations we have the concept of a "handler" which is maps to a specific "updateType". Here is the relevant pointer: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-agent-overview#update-handlers

An example of such handler is APT or SWUpdate, which resides here: https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers/swupdate_handler

Dharman
  • 30,962
  • 25
  • 85
  • 135
Yuval Gross
  • 21
  • 1
  • Thanks for the answer. I already looked at these files and in the meantime I think that have a basic understanding on how the Agent is working and where I can add my additional tasks he should do. I'm looking forward to see what the expected way is. Is there a rough estimate when this "very soon" will be ? – Voxel Apr 21 '21 at 12:03
  • Once I have everything up and running I will post this at my solution. But your answer ensured me, that I'm not missing something obvious. – Voxel Apr 21 '21 at 12:45