Closed rwsanders closed 7 months ago
Hi @rwsanders thank you for bringing this to our attention. In ADU GA version, we have updated the interfaceId to contractModelId, please refer to Device properties. And both interfaceId and contractModelId are supported for ADU service, you just need to make sure that the sample uses the corresponding mode id with header file. For examples, our sample uses thermostat-4.json for contractModelId, and uses thermostat-3.json for interfaceId.
contractModelId as 'dtmi:azure:iot:deviceUpdateContractModel;2'
interfaceId as 'dtmi:azure:iot:deviceUpdateContractModel;1'
Thanks for the quick reply, @bo-ms. So, is it right to say that interfaceId is being deprecated and replaced with contractModelId? You say that both are supported for ADU, but are you accounting for the aforementioned validation? It seems like the absence of interfaceId after an update to contractModelId blocks the update process. Is this your observation as well, or are you saying that if I use the correct corresponding model id on my device that this validation won't block the update?
I was able to test this today. I can confirm that changing the device PNP_MODEL_ID to dtmi:azure:iot:deviceUpdateContractModel;2
with the latest version of NetXDuo passed the validation and allowed the update to proceed.
Thank you for your help on this!
Closing
According to https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-agent-check?tabs=portal#validation-checks-supported-by-agent-check
interfaceId is a required as part of the validation check for device eligibility to receive an update.
"If a device fails any of these criteria, it may not show up properly in Device Update"
interfaceId was replaced with contractModelId in https://github.com/azure-rtos/netxduo/blob/master/addons/azure_iot/nx_azure_iot_adu_agent.h
This causes devices to show validation errors
This bug is observed by updating to the latest NetXDuo in master and attempted to push an Azure device update.
It is expected that the system would add the "deviceUpdate" data to the "desired" section of the device twin, along with the update manifest. However it seems this validation step blocks this.