Device Shadow Handling Failed Update

Question

I trying to understand how AWS Device Shadow handles a failed update to a local device.

For example, say an application wants to configure some property on this device, let's call this property "mode". My device accepts two values for "mode"; either "on" or "off". Now say some app updates the "desired" component of the shadow state document to the following:

{
  "desired": { "mode": "invalid_mode" },
  "reported": { "mode": "off" },
}

When my device receives the delta for this situation, it will attempt to set "mode" to "invalid_mode"; my device does not permit this value for "mode", so this operation will not be applied. Therefore, I want to report back to the Device Shadow somehow that the update was not applied, i.e. I want the "reported" part of the state document to be unaltered for the setting "mode". The trouble is, leaving the property "mode" unaltered in "desired" means the delta will persist and I will keep receiving it over and over.

Some solutions I saw recommended to send back the following to the shadow:

{
  "desired": { "mode": null }
}

Which will erase the property from "desired" and stop the endless loop of deltas. However, I wanted to know if this is indeed the optimal/recommended approach to handling this case where "desired" updates were not applied. Are there any other ways of going about this?

Additionally does the Device Shadow service provide any mechanism for reporting an invalid/rejected "desired" update as in this case?

Thank you!

Answer

Hi,

one option is to report back additional state in the shadow so that the application that set the desired state is able to take the appropriate action to solve the issue.

For example, you device could report:
```
{
   "reported": {
       "error": "Invalid mode invalid_mode not applied",
       "mode": "off"
   }
}
```

You can then have a rule subscribing to shadow updates messages and check for any errors.

To avoid the infinite loop with deltas, you should use the `timestamp` metadata associated with the delta:
```
{
  "version": 19,
  "timestamp": 1665991032,
  "state": {
    "mode": "invalid_mode"
  },
  "metadata": {
    "mode": {
      "timestamp": 1665991016
    }
  }
}
```
By storing the `timestamp` value of the latest delta you answered to, you can check if the the new delta changes are related to something you have already processed or not. Above is the delta you get after sending the update leaving `mode` unchanged. The timestamp associated to the `mode` indicates the time when the desired `mode` was changed and this enables your client to track which updates you have already processed and which not.

I would also advise to validate the desired values you set in the shadow cloud side.

For a more powerful and flexible mechanism to send updates to devices you can also look into [AWS IoT Jobs](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) which allow you to [report additional status information and errors](https://docs.aws.amazon.com/iot/latest/developerguide/jobs-workflow-jobs-online.html#jobs-job-processing).

Device Shadow Handling Failed Update

Relevant content