Sensing the disconnection of a device more than t seconds


I have a project where i need to decide if a device stayed disconnected longer than 600 seconds(like triggering a lambda function at 600 seconds mark). I am using pure serverless. I couldn't figure out how to approach the issue to be cost effective. Any ideas?

asked 9 months ago168 views
2 Answers
Accepted Answer

AWS IoT core service publishes device lifecycle events to reserved topics, e.g. $aws/events/presence/connected/clientId for devices that go online. You can create IoT topic rules to process these connected/disconnected events.

If you want to trigger an event after T seconds of the offline event published by the IoT Core service, I would setup an IoT Topic rule with an SQS publish action, then consume SQS messages with a Lambda function. You need to set the SQS queue's default delay as T=600 seconds. Thus, an SQS message published by the topic rule will be visible to the Lambda function after T=600 seconds. In other words, the time when the lambda function is invoked will be timestamp of offline event + 600 seconds. When the lambda function invoked, the function knows that the device emitted a disconnected event T=600 seconds ago. But the lambda function needs to know whether the device went online after that event. To provide this information to the lambda function, you can do one of the following:

  1. Develop a logic on the IoT device to update the thing shadow with timestamp of every successful MQTT client connections. (This would be the timestamp of last_online)
  2. Develop a logic on the IoT device to update the thing shadow with a LWT message when the MQTT client disconnects. (This would be the timestamp of last_offline)

If you need to store and query online/offline history later, you can use a DynamoDB table to store these online/offline timestamps instead of the thing shadow. In this case, you can query the table with thing name and timestamp to check whether the device became online after a disconnected event published by the IoT Core.

Also, similar question is here, you can take a look at the discussion as well;

For the scalability and cost efficiency aspect, I would recommend to configure Batch size and Batch window parameters for Lambda SQS Trigger. For the configuration as Batch size: 50 and Batch window: 10, the Lambda function will be triggered once for messages delivered in 10 seconds time window (if you have 10 seconds of tolerance to perform your action), or number of messages that are delivered reaches to 50. Thus, you can reduce the number of lambda invocations and take advantage of batch calls in your lambda function if you have any, e.g. DynamoDB query or batch writes.

answered 9 months ago

Are you able to have an application on the device send a custom CloudWatch metric? Alternatively, if there is an existing log you could also use metric filters depending on your use case. Once the data is in CloudWatch you can use Alarms and Events to perform notifications and other actions.

answered 9 months 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