Should the `thing-example.js` thing be setting the "reported" state instead of "desired"?

I’m still wrapping my head around the intended use of reported vs desired, but based on my current understanding the desired state is basically “Thing, I would like you to change your state to this new state” - i.e. in the example of a remote IoT lightbulb and a phone app, the phone app would set the desired state of the thing to tell the light that it should go to that state.

The reported state is what the light would return back with, to let AWS IoT know that it was it’s state. This could be done as a confirmation that the state had been moved to match the desired state, or it could be used to indicate that some external force caused the thing to go to that state (maybe somebody hit a remote control that changed the light to a new state).

Again, I could be totally off on my understanding and would greatly appreciate being corrected if so!, but if not, then the example thing-example.js seems to be a bit confusing because the thing part of the example sets the desired state. Again I’m probably thinking about htis all wrong, but it just seems to me like the “thing” should be setting the reported value?

[liuszeng]

Hi @develpr ,

Thank you very much for your interest in AWS IoT.

Thanks to @groteworld 's explanation. You can actually think about the following model:

1. You have a device with a light and a physical light controller on it.
2. You have a application that you would like to use to control that device light.
3. Both the device and your application runs AWS IoT Device SDKs, communicating with each other using MQTT.
4. The device light always updates the reported state, indicating this is exactly what happens on the device.
5. The application always updates the desired state, indicating that is exactly what you want the device to be.
6. The device light also listens to the delta messages, which are triggered whenever there is a difference between the desired and the reported state, that is to say, the device status is different from what you want it to be and needs to be changed.
7. The device light reacts to an incoming delta message by switching its status to the desired state you just requested through your application.

Basically, your device and you application are connected to each other through AWS IoT Device Shadow and its delta mechanism. You can control your device from your application by simply updating your shadow state.

For more details, you can take a look at the following documentations: http://docs.aws.amazon.com/iot/latest/developerguide/thing-shadow-mqtt.html#update-delta-pub-sub-topic http://docs.aws.amazon.com/iot/latest/developerguide/thing-shadow-data-flow.html

You can also take a look at a more use case related sample provided along with the Node.js SDK: https://github.com/aws/aws-iot-device-sdk-js/tree/master/examples/temperature-control

Thanks, Liusu

[groteworld]

I think you are just missing a small part of a thing shadow’s document which is the delta. If the reported doesn’t match the desired a delta is create that states the desired. A thing can then handle changing to that missing desired state.

Example:

{
  "desired": {
    "light": "green"
  },
  "reported": {
    "light": "blue"
  }
  "delta": {
    "light": "green"
  }
}

Here the shadow is stating there is a desired change, delta, and it will remain there until the reported state returns the same as the desired.

In the case of the example thing-example.js it is setting desired because it handles its “light” changing through the delta. since the reported (null) will never be desired (random RGB), the delta is always being updated and it’s event can be listened for.

I hope this helps!!