Query regarding Reported/Desired states of Device Twins@IOTHub

Arun Kumar Singh 1 Reputation point
2020-06-18T05:52:19.827+00:00

Hi,
I am trying to implement a cloud based solution for Home Automation devices and exploring various options offered by Azure IOT Hub and device twins. Its in this context I need to understand few things :-

When a device sends reported properties update to IOTHub, is it mandatory for the back end application to simultaneously update desired properties update back to device of same properties.
Do the Desired properties/Reported properties always remain to be in sync with each other - update on one(by either side) triggering update of another. so if cloud back end app updates desired properties to device, is it required for the device to update its properties and trigger back reported properties update back to IOTHub with same properties?
Can Reported and Desired properties be different at any point of time?

Going through the documentation I understand that reported/desired properties at cloud end(and device end) can be different as these server different purpose. But it would be good if I get clarification on same.

Thanks

Azure IoT Hub
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
1,189 questions

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Olivier Bloch - MSFT 101 Reputation points
    2020-06-18T17:48:47.36+00:00

    Hi, Desired and Reported properties in the Device Twins are decorrelated. There is no requirement for having identical properties in both sections of the Device Twin. And if you decide to have identical properties in both Reported and Desired properties, you need to decide what your own convention is in terms of sync.
    I think it is not efficient nor useful to have identical properties. For example, if you monitor and control the state of a thermostat, a Desired temperature and a Reported temperature wouldn't have the same meaning. You would set the Desired temperature from the Cloud and the device would report the actual measured temperature (which is different than the desired temperature). Now, if you have a way on the device for a user to set a local "desired" temperature on the device, then you will indeed want to report this value set on the device to the cloud, but it will have to be in the Reported properties section of the Twin as the Desired properties are read-only on the device side.
    Try and think about Desired vs. Reported as synonyms for Read-Only vs. Write-only from the device perspective and Write-only vs. Read-only from the Cloud perspective.

    2 people found this answer helpful.
    0 comments
  2. Olivier Bloch - MSFT 101 Reputation points
    2020-06-18T20:44:09.207+00:00

    In both cases, whether step 3 is required or not is totally on you and the scenario you want to implement. Usually the desired and reported properties are used in asynchronous scenarios where you want to know the last known state of the device or the last known desired property from the Cloud app. By default the Device Twins property update mechanism doesn't include the acknowledgment from the other party.

    It seems your scenario requires having an acknowledgment that the other side received and acted on the property update.
    Here is what I would recommend depending on whether you need a synchronous or asynchronous behavior:

    • For Asynchronous behavior, you can definitively leverage the device twin properties the way you suggest. But once again, this is gonna be based on your own convention and properties names/values
    • For Synchronous response of a device to a command from the Cloud you will prefer using the Direct Method feature. And for the other way around (Device to Cloud), you will want to use telemetry messages which allow the device side to be notified when the telemetry device was delivered.
    1 person found this answer helpful.
  3. Arun Kumar Singh 1 Reputation point
    2020-06-18T18:50:53.333+00:00

    Hi Obloch,

    Thanks for the clarification. So just to be clear on this, consider below flow scenarios:-

    Case A : Cloud back end wants to update device state via desired properties.
    1)Cloud back end app needs to update state of device via device twins. It sets same via desired properties at its end and device get these desired properties.
    2)Device acts on these desired properties and updates its state.
    3)Device then reports back its updated state(due to these desired properties).

    Is step (3) required at all? In my view and looking at your reply, it sounds redundant and not efficient.

    Case B :
    Similar could be the scenario when device has got any update(whether change of its state due to local control, telemetry etc)
    1)Device updates its reported properties
    2)Cloud back end retrieves these reported properties
    3) Cloud app then again sends these back as desired properties to device.

    Step 3 in both these cases should not be required at all?
    Further if step (3) is redundant then how will cloud in case A and device in case B know that its desired/reported property update to other end has been acted upon?

    Thanks,

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.