Questions tagged with AWS IoT Core

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

AWS IoT Rule SQL republish get thing name as JSON object key

I'm publishing Shadow updates from multiple iot devices. I want to filter those updates and extract only some data that will update another thing shadow (let's call it main shadow) with a list of Json objects. Each json object key is the thing id. For that, I have a rule that is subscribed to $aws/things/+/shadow/update/documents to capture all the devices shadow updates. So for example for the following updates to $aws/things/device101/shadow/update/documents ``` { state: { reported: { "temperature": "28" } } } ``` to $aws/things/device202/shadow/update/documents ``` { state: { reported: { "temperature": "31" } } ``` the main shadow will result in ``` { state: { reported: { "device101": { "temperature": "28" } "device202": { "temperature": "31" } } } ``` In my SQL I still can't find the way to use the thing id as a key in the json data that will be published to the main shadow. I'm using topic(3) as the function to get the thing name and Literals to build the json but it keeps telling me that it expects a key. I tried to cast the topic(3) function but same result ``` SELECT { topic(3): {'temperature': current.state.reported.temperature }} as state.reported FROM '$aws/things/+/shadow/update/documents' ``` ``` SqlParseException Expected a key, but got IDENT(topic). Object literals should follow the format {"keyName": any-expression, "anotherKey": any-expression} topic(3): ``` Any idea how this can be achieved ? thanks
2
answers
0
votes
44
views
mvp
asked a month ago

Device Shadow Handling Failed Update

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!
1
answers
0
votes
34
views
asked a month ago

AWS IoT via MQTT randomly succeeds and fails on subscribe and publish messages

I have an application using the Mosquitto MQTT library that publishes and subscribes using MQTT messages to AWS IoT. The connection succeeds, and the permissions are correct. I am logging using CloudWatch, and can see the successful connection in the log. The application subscribes to about 20 topics when it connects, then sends current values for those same topics. More than half the time, this fails. I get messages like this in the CloudConnect log: ``` { "timestamp": "2022-10-13 10:58:21.254", "logLevel": "ERROR", "traceId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "accountId": "xxxxxxxxxx", "status": "Failure", "eventType": "Subscribe", "protocol": "MQTT", "topicName": "soft/increment/UI2", "clientId": "58af8c4d-d863-449e-b632-d2aae465797b", "principalId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "sourceIp": "xxxxxxxxxxxxxxxxx", "sourcePort": 52524 } ``` After this, AWS IoT drops the connection. If I disable the subscription step in my application, I get similar messages, but for eventType: Publish-In instead of Subscribe. As far as I can tell, I'm not exceeding any of the limits described here: https://docs.aws.amazon.com/general/latest/gr/iot-core.html#limits_iot If I allow my application to re-try the connection, it will fail repeatedly until one time it succeeds. At that point it can publish and receive data without any further trouble. This confirms that the permissions are correct. If I reduce the number of topics from 20 to 8, the chance of success rises substantially, to the point where the connection is almost reliable. If I add a 100ms delay between each subscription request, the chance of success rises substantially. If I add a 100ms delay between subscriptions, make a successful connection, then remove the 100ms delay and try again, the connection almost always succeeds, even though it was always failing prior to adding the 100ms delay the first time. If I remove the subscription step altogether, the chance of success does not apparently change. Using this same application to connect to the Mosquitto broker never fails. * What is going on here? This cannot be explained by permissions, and isn't obviously related to service limits. * How can I find more information than just "Failure" when AWS IoT rejects a message? * How can I make this reliable?
2
answers
0
votes
33
views
asked a month ago