Sensing the disconnection of a device more than t seconds

0

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?

質問済み 2年前671ビュー
3回答
2
承認された回答

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; https://repost.aws/questions/QU5zUQchQ3SWyLWQPeDH7umQ/aws-io-t-core-takes-too-long-to-update-the-connectivity-information-of-a-device

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.

AWS
回答済み 2年前
0

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.

回答済み 2年前
0

We just launched a feature yesterday that is dedicated to monitor devices that are disconnected longer than a predefined threshold level. Please check announcement here and step by step blog here. This metric was designed to be very low cost compared to other metrics in Rule Detect. Check calculator below, within Rule-Detect, plug in your number of devices and there is a drop down menu that ask if Disconnect Duration is one of the metrics. Select included. This will help you estimate monthly cost. Ballpark is less $20 per 100K devices per month.

AWS
回答済み 8ヶ月前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

質問に答えるためのガイドライン

関連するコンテンツ