Filter on Thing Group from AWS IoT Rule

1

Is it possible to select only messages in a certain thing group from an IoT Rule SQL query?

For Example: SELECT * FROM '$aws/events/presence/disconnected/#' WHERE clientId.thinggroup = "dev"

asked 2 years ago884 views
1 Answer
2
Accepted Answer

Approach 1: build a lambda function which extracts a group name from the device and use:

SELECT * FROM '$aws/events/presence/disconnected/#' WHERE aws_lambda("MyLambdaToExtractGroup",{"clientid":clientId}).groupname= "dev"

When using this approach, please consider the quotas for ListThingGroupsForThing API you will find in https://docs.aws.amazon.com/general/latest/gr/iot_device_management.html (50 or 10 TPS depending on region, adjustable). If you face some limits here, the approach 2 provides an almost limitless scalability.

Approach 2: Alternative approach would be to save a group name for each of clientId in DynamoDB, and then use:

SELECT * FROM '$aws/events/presence/disconnected/#' WHERE  get_dynamodb("ClientIdToGroupMapping", "clientId", clientId, "arn:aws:iam::12345678910:role/getdynamo").groupname = "dev"

To store Group name for each client id, you could use https://docs.aws.amazon.com/iot/latest/developerguide/registry-events.html in another IoT Rule.

However, there may be more cost efficient options available depending on how you want to process the payload of IoT Rule. Can you tell more about it? (i.e. which Actions do you intend to use)

answered 2 years ago
  • Basically I am trying to implement the recommended delayed SQS queue for handling lifecycle events. I would like to put the message on the queue and after a delay, trigger a lambda to make sure the device is still offline before updating any connect status info. The issue is that we currently don't take advantage of using multiple accounts for dev test and prod. It's just one account with tagged resources. This becomes an issue when using the rules as they are triggered regardless of what Thing Group the device is in (e.g. dev or prod). In the long run I think the best solution would be to move to a multi account setup so Dev Things are not triggering the same resources as Prod Things, but for now it sounds like the lambda you suggested may be the only option for how our infrastructure is currently set up.

  • Splitting dev and prod into different accounts is certainly most cost-efficient and sustainable solution here.

    If you use SQS queue for handling lifecycle events and need to build Lambda for that anyway, you could also implement the filtering logic in that Lambda. The cost calc needs to be done as always, but I could imagine that it would not result in significantly higher costs then using the Lambda approach I proposed.

  • For sure. This is more of a temporary solution until we can get our environments split up. So until then I am going to go with your first suggestion of writing a quick lambda to extract the group name. Thanks for the help.

  • You are very welcome!

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