We are using AWS IoT "Device Shadow" service to sync settings between cloud back-end services and our embedded device.
The device publishes its "reported" state to $aws/things/xxx/shadow/update:
{ "state": { "reported" : ... } }
And when the back-end wants to change something, it publishes a "desired" state:
{ "state": { "desired" : ... } }
This generates a delta message on $aws/things/xxx/shadow/delta, which we subscribe to on the device. This all works well.
However, sometimes the device needs to reject a change (typically because the device was offline and so the change is too old and not reliable data). In this case, we don't want to keep getting "delta" messages for this change we want to reject.
According to this post, we can set the "desired" state to null to clear it:
[https://repost.aws/questions/QUx_YtxvdmTFODhuuNd4D_Yw/how-to-deal-with-shadow-updates-initated-by-device-not-and-server]
As per the example, I have tried sending this from our device to $aws/things/xxx/shadow/update:
{"state" : {"desired" : null } }
However, this is rejected by the server and causes a message on $aws/things/xxx/shadow/update/rejected:
{
"code": 400,
"message": "Payload contains invalid json"
}
The JSON looks valid. Also, this DOES work if I post it to $aws/things/xxx/shadow/update from the online MQTT client in the AWS console (i.e. it is accepted, and has the desired effect - the desired section of the device shadow is deleted).
Why do I get this error when the message is sent from the device? How do I clear / reject a "desired" change?
asked 5 months ago
AWS OFFICIALUpdated 2 years ago
How do you try to update the shadow? Could you provide a code snippet?
I would suggest to check that the JSON data is serialized correctly. You can also subscribe to
$aws/things/+/shadow/updatein the AWS console to see what message is effectively being sent.If the update works sending it via the AWS MQTT client but does not on your device it points to there most likely being a JSON formatting/Parsing error on the device. Can you please attach as snippet of the publish code so that I may have a look.
Deeper investigation showed that the outgoing message buffer was being overwritten by the next message - AFTER I logged it to check the content but BEFORE the message had been fully sent - due to a threading "misunderstanding". Thanks @MassimilianoAWS for suggesting that I check the "$aws/things/xxx/shadow/update" topic in the AWS console - this made the corrupt content obvious. What can I say, it was a Friday...