- 최신
- 최다 투표
- 가장 많은 댓글
Thank you for the reply. I am not the developer of the firmware on the device so I do not know exactly what it is doing. However, I believe that the firmware developers started with a framework produced by Amazon or at least one that's been used elsewhere (AmazonFreeRTOSManager?).
In my case, only the last 'desired' state is important, so I don't care if the device receives the intermediate ones as long as it processes the most recent. I can see the reports coming back from the device but I'm not doing anything with them.
On a related note, I am using Amazon's Java SDK to communicate with the IoT service. In particular, the class 'software.amazon.awssdk.crt.mqtt.MqttClientConnection'. In my application there is one instance of this class that in some cases is used by multiple threads to send messages in parallel. Is this safe? Or should I be using a different instance per thread?
Hi Frank. When your application updates the desired part of the document, the shadow service will produce a delta section that lists all elements that differ from the reported section of the document. If the application makes multiple changes while the device is offline, the delta will reflect the cumulative state. When your device eventually comes online and receives the delta, it should apply the changes, and report the new state. Once the reported section no longer has any conflict with the desired, the delta will no longer exist. If your delta is persisting, then your device hasn't received it and/or hasn't applied it and changed the reported part of the shadow.
Typical workflow in steps: https://iotatlas.net/en/implementations/aws/command/command2/
This has some comments about message order: https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html#device-shadow-using
And processing messages when the device reconnects: https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html#device-shadow-comms-device-reconnect
Hi Frank. You said "I am seeing cases where it appears to not be working", but didn't really explain what you're seeing. I explained the delta part because, if the device is working correctly, you should see the delta disappear from the shadow. If the delta is persisting, the device isn't doing its part.
Hi Greg, I subscribed to the /update/accepted topic and then sent a message to the /update topic. I was expecting to see a response on the /update/accepted topic, but I didn't get one. However, I later unsubscribed from /update/accepted and then resubscribed, an at that point I immediately received the message I was expecting earlier.
I think I figured out why my subscription was failing; it's because I was inadvertently closing the MqttClientConnection elsewhere in my code. After fixing this I'm seeing the expected responses.
I was confused about whether or not I needed to create multiple MqttClientConnection instances. I believe that one instance is all I need as long as I synchronize access to it (because I do not think it is thread-safe, at least it isn't marked as such).