ADU update group no longer seeing new updates. We cannot deploy urgent updates to our IOT devices in the field.

Thank you for all the valuable inputs.

We looked at them all, and thoroughly checked permissions etc.

Of our multiple IoT devices, only 18 were showing up in the different update groups (a mere fraction of the total devices provisioned), but none in the diesel, thus it would not see the update to deploy it.

When deploying in the other groups where only a few devices were listed, we however noticed that all the missing devices were actually updating, but no stats appearing for them.
This got me thinking, so I compared AGRI devices Digital Twins, that were showing up, and those that were not.

The model id differed, then it dawned on me that we updated our Digital twin for our devices in 2024-07.
At the same time we posted this question: https://learn.microsoft.com/en-us/answers/questions/4379076/our-azure-iot-update-appears-to-be-malfunctioning

I then dug deeper into the model id issue, and then decided to change it to:

"modelId": "dtmi:azure:iot:deviceUpdateContractModel;2",

and not our custom model id for our custom digital twin.

We physically flashed a diesel-rev2 device with a new firmware that used the contract Id for the model id too, and that device appeared, and we could upload a new update "That included the 'correct' model Id", and then we could deploy; and now we have all our diesel-rev2 devices showing up.

We are currently working on a sensible update for our AGRI devices, and then all those that have not shown up since 2024-07, will now also show up in their relevant ADU groups.

At last the issue is solved, although it doesn't entirely make sense.

Also note that we are using the azure-iot-middleware-freertos library in ESP-IDF for enabling IOT with Azure.
The unfortunate part is that this Microsoft git repositories core code, has not been updated since around May of 2022.
Hopefully Microsoft will bring its digital twin support up to date with the latest available contract models soon.

Again, thx for all inputs from the community.

Hello  Adrian Wreyford,

Thank you for the detailed question.

In addition to Oetze van den Broek ‘s suggestion, please check if the following ones are helpful.

1. Please first confirm that the update has been successfully imported and is visible under the updates section of the device Update instance. The update must be fully published and marked as available before it can be associated with any device group. If the update is not visible here, it will not be linked to any group during deployment.
2. Next, please verify that the device is correctly assigned to the intended device group using the ADUGroup tag. The tag value is case‑sensitive, must exactly match the group name, and can only contain a single value per device. The tag must be applied to the correct twin (device or module, depending on how the Device Update agent is provisioned).
3.  If the group was manually deleted and then recreated using the same tag value, device Update may not automatically re‑evaluate the group’s update eligibility. In this case, force a reprocessing of the device by temporarily changing the ADUGroup tag to a different value, saving the change, and then changing it back to the intended group name. This action triggers Device update to reassess the device and correctly link available updates to the group.
4. After the tag is reprocessed, create a new deployment for the device group. Deployments are always tied to the current state of a group, and previously deleted groups do not retain any internal update associations. Ensure the update’s compatibility properties (manufacturer, model, and version) match the device reporting properties so the update is considered applicable.

Please refer the following for more detailed information

Deploy an update by using Azure Device Update for IoT Hub | Microsoft Learn

Azure Device Update for IoT Hub device groups | Microsoft Learn

Please let me know if you have any questions.

Thank you!

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Maybe you are having permission problems?

In IoT Hub, The Azure Device Update service must have IoT Hub Contributor permissisions (that is what we setup)

Based on the described behavior, the issue is with the Device Update group/tag linkage and how Device Update discovers updates for that group. Use the following checks and recovery steps:

1. Verify the device group is correctly formed from the tag
   Device Update creates user-defined groups from the ADUGroup tag in the device or module twin:

      "tags": {
        "ADUGroup": "DieselADU-REV2-ESP32S3-F16-R8"
      }
   

   Confirm on the device/module twin that:
   • The ADUGroup tag exists and exactly matches the group name (no extra spaces, different casing, or typos).
   • Only one ADUGroup tag value is present per device (a device can only be in one Device Update group at a time).
2. Confirm IoT Hub message routes for Device Update are correct
   If the tag or twin changes are not flowing correctly to Device Update, the group/update association can break.
   • Ensure message routes in the IoT Hub are configured as required for Device Update resources.
   • If routes were misconfigured, fix them and then reapply the tag (for example, temporarily change ADUGroup to a different value, then change it back) so Device Update reprocesses the device.
   This aligns with the documented guidance when tags/groups do not behave as expected:
   • Misconfigured routes can prevent tags from appearing or updating correctly when creating or using groups.
   • After fixing routes, tags must be reapplied so Device Update can see them again.
3. Ensure the device is actually connected to Device Update
   A device must be connected to Device Update for the group and updates to work correctly:
   • In the IoT hub → Updates → Groups and Deployments, verify that the device appears under the expected group or under Ungrouped devices.
   • If the device was tagged before it was connected to Device Update, temporarily change the tag to a different value and then back to DieselADU-REV2-ESP32S3-F16-R8 after confirming the device appears in Device Update.
4. Check that the imported update content matches the device class
   Device Update only offers updates to groups whose device class (manufacturer/model and compatibility) matches the update’s import manifest. If the group exists but shows “no updates linked” when deploying:
   • Verify that the device’s manufacturer and model reported via the ADU Core Interface match the values in the update’s import manifest.
   • If these properties changed (for example, firmware or agent changes), Device Update can treat the device as incompatible and not show the update for that group.
   • If needed, adjust the device properties using the Device Update configuration file so they match the imported update content.
   When a device is incompatible with an update, Device Update can show the group but not allow deployment of that content to that group.
5. Use the CLI to validate group and update availability
   To confirm what Device Update sees for this group:
   • List device groups:

          az iot du device group list \
              --account <Device Update account name> \
              --instance <Device Update instance name>
     

   • Show the group and its best available update:

          az iot du device group show \
              --account <Device Update account name> \
              --instance <Device Update instance name> \
              --group-id DieselADU-REV2-ESP32S3-F16-R8
     

   Confirm that:
   • The group exists and lists the expected devices.
   • A “best available update” is shown for that group. If none is shown, Device Update considers there to be no compatible update for that group.
6. Check compliance and invalid groups in the portal
   In IoT hub → Updates → Groups and Deployments:
   • Confirm the group DieselADU-REV2-ESP32S3-F16-R8 appears under Group name with devices in it.
   • Look for any corresponding invalid group for this device class. Devices that do not meet the device class requirements of a group appear in an invalid group, which indicates a mismatch between the device class and the update content.
7. If a deployment was created but devices are not progressing
   • Ensure the deployment start date is not set in the future; by default, new deployments start the next day unless changed.
   • If a deployment is stuck or failed, use Retry failed devices on the group’s Current deployment tab, or use az iot du device deployment retry with the correct --class-id.

If, after verifying the tag, message routes, device connection to Device Update, and device class/import manifest alignment, the group still shows “no updates linked” despite a compatible update being imported, this indicates a backend service issue. In that case, open an Azure support ticket with the Device Update and IoT Hub resource details so the service team can inspect the specific group and deployment state.

References:

• Azure Device Update for IoT Hub device groups
• Device Update for IoT Hub Troubleshooting Guide
• Tutorial: Azure Device Update for IoT Hub using a Raspberry Pi image
• Deploy an update by using Azure Device Update for IoT Hub
• Manage device groups for Azure Device Update for IoT Hub
• Tutorial: Azure Device Update for IoT Hub using the Ubuntu 22.04 package agent
• Device Update for IoT Hub diagnostics overview