1

I have an Azure IoT solution that uses the Remote Monitoring Accelerator. Both the server (remote monitoring web) and client (device) are changing the device twin properties. Sometimes those properties get into the "syncing" state and don't seem to get out of it.

So what are the rules for who has the authority to change device twin properties and when?

I use the IoTHubDeviceClient_LL_SendReportedState() function to change properties from the device side, btw.

Jon Th
  • 347
  • 2
  • 13
  • The server-side should (and in fact can) only update the Desired properties. The client always only the Reported properties. – silent Jul 31 '19 at 10:57
  • That doesn't solve my problem, sorry. Yes, if the server initiates a property change, it will update a desired property and then the client will send back IoTHubDeviceClient_LL_SendReportedState() with that change stating - yes, I did that change. And if the CLIENT initiates a property change, it will call the same function - IoTHubDeviceClient_LL_SendReportedState() with a totally new value for the property. The problem is that that works sometimes and sometimes not - the property ends up in a "synching" state. – Jon Th Jul 31 '19 at 11:03

1 Answers1

1

The Azure IoT Device Twin represents a lightweight generic data (state) model for disconnectable distributed ends such as a device-facing end and service-facing end. The Device Twin has a support for creating a "shadow copy" between those ends in the transitions manner. Basically, each end has ownership for writing (or updating) its property, which the other end is notified for this changes.

enter image description here

Based on this notifications, versioning and device twin metadata, the state can be transited from one end to other one in the reliable manner. Note, that the lightweight state machine must be implemented at the each end such as a device and backend triggered by the notification changes.

The above picture is from document Device twins, where is described this model in the detail.

Update:

The following screen snippet is an example of the sequence diagram for transition states between the Device and Back-end using a Device Twin properties:

enter image description here

In the above example, this distributed state machine handles a transmission state from inprocess, ack, done, null between the Device and Back-end. Similar can be created the transitions for instance: inprocess, nack, null, between the Back-end and Device, for disconnected device, etc.

This example used an additional property such as a status to indicate that the property Config is in the transition state, but can be added more, for instance, original value, version, etc. which they help to recover state, etc.

Roman Kiss
  • 7,925
  • 1
  • 8
  • 21
  • I understand but how do I get a property out of the "syncing" state? That CAN happen, but not always, when the client sets a reported property that's not the same as the desired property from the server - but it's because in that case the client wants to report a property change (due to someone walking into the room and changing something on the device). – Jon Th Jul 31 '19 at 12:15
  • I'm only calling the IoTHubDeviceClient_LL_SendReportedState() function from the device client. Perhaps that isn't enough and that's why my properties sometimes end up in a "synced" state?? – Jon Th Aug 01 '19 at 10:17
  • ...if not, which functions do I have to call and/or which callbacks do I have to register? I just want to be able to let the device be able to originate property changes as well as the back-end. – Jon Th Aug 01 '19 at 10:22
  • **On the device side**, you should also set the callback for handling a notification changes at the desired state (back-end), such as the function IoTHubDeviceClient_LL_SetDeviceTwinCallback. **On the back-end side**, you should setup a message routing in the Azure IoT Hub for *Data source = TwinChangeEvents* to push a notification message to the custom endpoint for handling a transition state on the desired properties based on the reported changes. – Roman Kiss Aug 01 '19 at 11:43
  • Thank you. I'm already calling IoTHubDeviceClient_LL_SetDeviceTwinCallback(). I'll looking into this message routing. I haven't really done that. I assume that this could get me pointed in the right direction? : https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-messages-d2c – Jon Th Aug 01 '19 at 15:24