- Newest
- Most votes
- Most comments
A /delta message will be published immediately whenever there's a mismatch between values of a field that is present in both the desired and reported properties of the shadow document. If you keep your current shadow design, the way you could prevent that additional /delta message is by removing the desired property from the document when the device publishes the /update.
If an update causes the desired or reported properties to become null, it is removed from the document. The following shows how to remove the desired property by setting it to null. You might do this when a device updates its state, for example.
{
"state": {
"reported": {
"color": "red"
},
"desired": null
}
}
You can also remove individual fields rather than the whole property.
https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-data-flow.html
The device or client publishes a $aws/things/thingName/shadow/name/shadowName/update request topic with a state document that assigns null values to the properties of the shadow to delete. Only the properties to change need to be included in the document. This is an example of a document that deletes the engine property.
{
"state": {
"desired": {
"engine": null
}
}
}
More generally though, I would recommend you consider to separate your up from your down so to speak. Separate status from command/control.
https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-document.html#delta-state
Fields that are in the reported section and not in the desired section are not included in the delta.
Because of the above, if you separate status and command/control, you will never get the unwanted delta. ie. Where possible, do not have the device independently modify fields in the reported property if those fields (can) appear in the desired property. This separation won't always be convenient.
At scale, you can take advantage of named shadows: have one (or more) shadow for purely reporting device status and one (or more) shadow to handle command and control from app or cloud. In this way, the status shadow document would never have desired or delta properties. The device would just report status by updating the reported property.
Hi Tom,
the device should only report it's state:
- when starting up/reconnecting and
- when a local action is changing its state (say a local switch turning on/off a lamp).
When starting up/reconnecting, the device reports the actual state, in the reported section. If it receives a delta, that indicates that the server has requested a different state while the device was offline, hence the device should update its state and report it.
When a local action is changing the state, the device should update both the desired and reported state, either by setting the desired state equal to the reported state, or to null in case you want to differentiate between server set state and device set state.
Relevant content
- asked a year ago
- asked 2 years ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
Hi Greg Thanks for the quick and detailed reply, looks like I cannot format the reply to your comment here unfortunately.
So if we want to keep the Delta functionality, it seems like our best option is option 1, setting the desired variable to 'null' after the request was met by the device. The settings of the variable to 'null' should be done by the server, if the request was met. Perhaps this can even be done by a function programmed into aws iot core rule engine? To be honest this should be a built-in feature to Shadows if you ask me, since without it, the delta feature is incomplete for any use-case where the device can change states independently of the server (based on built-in sensors or intervals for example). But perhaps I am missing something about using currentState and reportedState? The server updates the shadow with desiredState, the devices will change and update the shadow with reportedState and desiredState? And then the device can update just reportedState if it was self-triggered? I guess this will work and nullify the need to nullify the desiredState parameter :) Finally, if we switch to named shadows, device subscribes to downlinkShadow and publishes to uplinkShadow but then Delta won't work? Or like in example A, device will update downlinkShadow with confirmation after request was met? Similar to option 2, just maybe neater? Looking forward to continuing the discussion with you on this. Regards
Hi Tom. It seems I didn't explain myself very well. I've edited the answer to try to improve clarity.
The setting to null needs to be done by the device. Not the server. Else you will still get the unwanted delta.
In regards to named/multiple shadows, each shadow can have its own desired and delta properties. So the "downlinkShadow" would/could still use desired and delta properties for command/control/configuration. The device would still publish to the "downlinkShadow" but only to acknowledge that it applied the delta.