AWS IoT Core takes too long to update the connectivity information of a device


I'm using a lambda function to process the lifecycle events : $aws/events/presence/disconnected/clientId . I noticed there is BIG delay on IoT service updating the status of the device that triggered the event.

When running:

aws iot search-index --index-name "AWS_Things" --query-string "thingName:thingA"  --region us-east-1 

the response returns connected : true up to 120 seconds after the disconnection event is fired. This delay is unacceptable in some scenarios. Is there a way to improve that update time? Will it be fixed in the future?

Thank you.

asked 10 months ago159 views
3 Answers

I would use AWS IoT fleet Indexing to investigate, and troubleshoot your fleet of devices, for example to get stats on how many disconnected devices you have in your device fleet. Here a 1-2 minute delay before Fleet Indexing updates the index is less relevant. If you need to act quickly on a disconnect event, you should consume the Lifecycle Event in your own backend, for example in a Lambda function. A second options to get notified when device disconnect is the MQTT Will Flag (LWT)

profile picture
answered 10 months ago
  • Hi Jan_B, thanks for the answer. On my case, I already have the setup with lambda and SQS. I want to check if the device is still disconnected 30 seconds after the lifecycle event, in that case, send a push notification to the user associated with that device. The thing is that if the fleet index has a delay of 2 minutes, it will return "connected:true" when I do the check after 30 seconds, but I really don't know the state of the device, it could be disconnected and the index does not know yet. That is why the delay is relevant to me, I can only send the notification 150 seconds after the disconnection event. I don't want to send the notification right away because it could be a device reset and I don't need a push notification in that case. Could the will flag be used instead of the fleet index for that purpouse?

  • Based on the need to detect a a frequency less than 150 seconds, fleet indexing on connectivity isn't viable (it is a great tool for large fleets of devices in less granular timeframes). In your case, I'd look to process lifecycle event for both device CONNECT and DISCONNECT events, process via SQS/Lambda, and track the deviceId, lastState, and the event's timestamp in a persistent datastore such as DynamoDB. Then poll in a similar manner to fleet indexing and SELECT devices disconnected > 30 seconds.

  • Thanks @Gavin_A ! That's actually a very good idea, going to give it a try!


A similar question is posted today; you can check my response as well;

You can take advantage of SQS queues with delay configuration to perform your action in a Lambda function In summary, if you setup a IoT topic rule to send message to an SQS queue and set the queue's delay=30 seconds, the lambda function will be invoked after 30 seconds of the event. You can use Thing shadow to store last timestamp of online/offline event. Then you can perform the action in a lambda function that triggered by the SQS queue, after checking last online/offline value from the thing shadow.

answered 9 months ago

The time taken to for a Disconnect event to show up is impacted by the Keep Alive time set for the MQTT connection. If the Keep Alive is set to 60 seconds as an example, and the connection is lost un-gracefully (like a power loss to the device or cable disconnected) - it can take up as much as 60 seconds (since a check for connected status is deferred till the time Keep Alive runs out for the connection) for the message to show up on the MQTT topic - $aws/events/presence/disconnected/clientId . Try reducing the keep alive for faster disconnect notifications.

answered 7 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions