1

I have a relatively complex IoT device, for which I intend to use IoT hub as gateway, consider the following prerequisites:

  • IoT Device is connected to IoT Hub
  • IoT Device can receive configuration changes through the Desired twin properties from IoT hub
  • IoT Device can receive configuration changes from an on-premise tool, which connects to it through a BLE 4.0 interface
  • IoT device should report back configuration changes to IoT hub with the reported twin properties

Reported properties

The purpose of using the reported properties to report back configuration changes is to be able to acknowledge changes made to the device from the backend. In this regard, one could imagine that there is a web application, through which, users can configure the device in various ways (Through the desired twin) - In order to be able to validate that a change has taken place, I would need the reported twin, i.e. in order to tell the user that the "changes were successful".

Additionally, I would need the reported properties to recognize if an "on-premise" configuration change has taken place, through the BLE 4.0 interface.

The problem

Consider the following:

  1. A user has made a critical change in the configuration through the on-premise BLE 4.0 interface
  2. The reported device twin properties changes in IoT hub
  3. Desired twin does not reflect this change, as the change didn't occur from the backend
  4. Device somehow goes offline or looses the configuration
  5. Device gets online again and gets the entire Desired twin properties
  6. The configuration from the Desired twin properties does not reflect the latest critical changes, which were made through the on-premise tool.

My preliminary considerations

As you can see, there is a clear problem, based on the fact that the desired twin does not reflect the latest configuration on the device, given that a configuration change was made through the BLE 4.0 interface - It is "out of sync".

This is sub-optimal, as the desired twin properties (in my view) should always represent the contemporary configuration on the device - in order to avoid the scenario depicted above (one of many). The following leads me to think that I need to:

  • Keep the reported - and desired twin properties in sync

However, the most natural way for me to do this, would be to listen (IoT Eventhub endpoint) on the reported twin properties through a serverless function (Serverless function will be a part of this setup regardless) and make it alter the desired twin if it isn't in "sync" with the reported twin.

This does however also present a problem, as it would cause IoT hub to think, that the change made to the desired twin is a new change, which it will then push to the device. (Waste of data and processing power)

Therefore, my question can be boiled down to the following:

  • Can I keep the desired twin in sync with the reported twin properties (in a pretty way), provided that a change has been made "on-premise" - And not through the backend desired twin properties
Jeppe Christensen
  • 1,680
  • 2
  • 21
  • 50
  • have a look at my answer in the https://stackoverflow.com/questions/57288383/azure-iot-what-if-both-server-and-client-are-changing-device-twin-properties about the device twins in the distributed transmission state. – Roman Kiss Apr 08 '21 at 09:46
  • Thanks for your answer @RomanKiss - However, i'm not sure it solves the problem. Because when a change is made to the reported twin on-premise, the reported twin is transferred to the desired twin by the backend - which means that the desired twin will be sent to the device again (redundant) - thus a waste of data. – Jeppe Christensen Apr 08 '21 at 10:07
  • Are you using a simulated device on-premise in your solution? Basically, access to the device facing endpoint of the IoT Hub is for a real device. Note, that the reported properties can be updated only via this device facing endpoint. On the other side, such as a service facing endpoint, the desired properties can be updated and/or the reported properties can be obtained by multiple clients. The device twin represents a *shadow copy* between those ends in the transition states, in other word, each inquire for changing their state should be persisted in the device twin. – Roman Kiss Apr 08 '21 at 12:54
  • @RomanKiss no, it's a mobile application that can connect to the device over BLE4.0. So this means that the backend can change the desired twin, which takes effect on the device. Afterwards the device reports back the reported twin. Given that we only were able to change the configuration on the device through the backend, the desired and reported part of the twin would always be equal, when the device has received the desired twin and reported back - Which is great, because that means we can acknowledge to the user, when a desired twin is in effect by comparing it to the reported. – Jeppe Christensen Apr 08 '21 at 16:17
  • @RomanKiss in this case however, we have another endpoint that can alter the configuration directly on the device (the mobil application). When the mobile application makes a change, the reported twin is suddenly different to the desired twin. The following presents a couple of issues: If the device disconnects and lose the configuration, it would reboot and ask for the desired twin configuration - The desired twin does however not reflect the changes made from the mobile application. Additionally, this will give us a hard time validating if back-end changes on the desired twin is in effect. – Jeppe Christensen Apr 08 '21 at 16:24
  • Thanks for details. Couple questions. Can be your mobile app connected to the IoT Hub via https for updating a desired property? Does the device must work without the IoT Hub and operated by mobile app? – Roman Kiss Apr 08 '21 at 17:22
  • It's not a possibility to interface the mobile app with IoT hub. Imagine that these devices can be on unreliable connections - i.e. it should be possible to service the device from a mobile application if e.g. the device can't be reached from IoT hub. It should be able to function without IoT hub yes - where in such case, it for example would be operated through the mobile application. – Jeppe Christensen Apr 08 '21 at 17:39
  • OK, in this case, when the config device twin can not transmit all round trips states between the ends, the device needs to store a current config device twin and when the device is connected to the IoT Hub, the transmission state on the device twin will be finalized. – Roman Kiss Apr 08 '21 at 18:29
  • I'm afraid that you actually lost me here, can you perhaps elaborate? :-) – Jeppe Christensen Apr 08 '21 at 18:34
  • I understood your case. In my first comment is the link, where is described a sequence diagram of the transmission states between the ends, when the user (mobile app) is acting (in this example, abc=123). As you can see, there are multiple round trips for each change at the transmission state until both ends are finalized to the same device twin state represented by reported and desired properties. When the device is disconnected from the IoT Hub, the device is configured by mobile app (e.g. *abc=123*) and then during the re-connecting process will continue a device twin state synchronizing. – Roman Kiss Apr 09 '21 at 06:31
  • In addition, have a look at also this thread https://stackoverflow.com/questions/63812247/azure-iot-device-needs-to-get-desired-properties-from-while-it-was-offline?noredirect=1&lq=1 – Roman Kiss Apr 09 '21 at 10:39

0 Answers0