A New Hope — AWS IoT & Active groups

TensorIoT Editor
TensorIoT
Published in
5 min readJan 19, 2018

This is a story from a galaxy far far away, a land where empire has a strong hold of the galactic systems and adding devices to the AWS IoT groups have to be handled by the application manually. However, there is talk among the rebel’s camp, a new force is born in Tatooine and pretty soon real time active groups are going to become a reality. Now that we have established that I am a star wars fan, let’s get into the details of creating Active groups on AWS IoT.

While this has nothing to do with AWS IoT yet — There is still hope :)

Background

AWS IoT device management was announced at re:invent with a whole suite of features that aimed at making the on-boarding, organization, monitoring and remote management parts of the IoT ecosystem easier. In this blog, we are going to concentrate on the organization functionality of AWS IoT.

Any decent scale IoT deployments tends to have thousands of devices that perform various tasks and are usually tied to each other in a certain hierarchy. Hence AWS IoT groups was introduced as part of the device management capability which allows the grouping of devices in a certain hierarchy to make the device management and search easier. This was a welcome addition to the AWS IoT suite and as you are going to see below, one that can have far reaching benefits.

Why do we need Active Groups

Now that we agree on the fact that not all star wars movies are created equal and that IoT groups is an awesome feature, Let’s ask the next inevitable question, What about the ability of devices to be able to placed into or removed from groups automatically based on their device attributes in the shadow?

Such a capability is needed in any IoT implementation to track and group assets automatically. It reduces a lot of application logic that will otherwise be needed to implement such a functionality there by reducing the complexity of IoT implementation.

Active Groups Use cases

What are the use cases for this active groups feature. Well here are some

a.) Ability to add or remove devices from the group that monitors devices that has crossed the high temperature threshold

b.) Ability to track and place devices in groups based on the reported location. This can help inventory management and asset tracking tremendously

c.) Ability to track devices that has older version of the firmware, this can help in automated device updates based on the firmware version.

d.) Specialized and additional care to patient groups with elevated vital signs.

The above list is just a sample of all that is possible with Active groups implementation.

Active Groups Wish list

So, having the ability to automatically add and remove devices to IoT groups is great, so what will the feature look like? What should be the capabilities of such a feature?

  1. Have the ability to monitor a specific attribute on all device shadows
  2. Add the device to a group when the attribute goes over the threshold value.
  3. Remove the device from a group when the attribute goes below the threshold value
  4. This has to happen only when the device breaches the threshold and not for every change in the attribute value
  5. Have a rest API to be able to add and remove these active groups, so that it can be linked to an awesome UI interface
  6. Make all of this serverless, so that I don’t have to manage any instances

Well, today is your lucky day :) This is exactly what we have been working on and today we are releasing a micro service called as “Active Groups”.

Architecture

Active group REST operations

Architecture to create an active group

The above picture represents the architecture to create an Active group. Here the deployed micro-service will expose an API endpoint which is used by the caller to either add, retrieve or delete an active group.

Adding an Active group:

To add an active group the caller provides the following attributes in a JSON document body

  1. Operation: This indicates whether the restapi operation is either NEW, GET or DELETE. In this case it is “NEW”
  2. Operator: This indicates the comparison operator that is used by the rule to evaluate the device attribute value against the threshold
  3. Threshold: The value at which the device either added or removed from the group
  4. Attribute: This is the indication to determine the name of the shadow attribute that is being watched
  5. GroupName: The name of the active group that is being created as part of this call

Example:

{
"Operation": "NEW",
"GroupName": "HighTemperature",
"Attribute": "Temperature",
"Operator": ">",
"Threshold": "100"
}

Retrieving an Active group:

To retrieve an active group the caller provides the following attributes in a JSON document body

  1. Operation: This indicates whether the restapi operation is either NEW, GET or DELETE. In this case it is GET
  2. GroupName: The name of the active group that is being created as part of this call

Example:

{
"Operation": "GET",
"GroupName": "HighTemperature"
}

Deleting an Active group:

To delete an active group the caller provides the following attributes in a JSON document body

  1. Operation: This indicates whether the REST API operation is either NEW, GET or DELETE. In this case it is DELETE
  2. GroupName: The name of the active group that is being created as part of this call

Example:

{
"Operation": "DELETE",
"GroupName": "HighTemperature"
}

Active groups in action

Active group run-time architecture

The above picture represents the architecture of the real-time activity of an Active group. When any of the devices in the fleet send a shadow update, the AWS IoT rule is fired to investigate if the attribute threshold is breached. In the event of a threshold breach, the Lambda function is then fired which will then add or remove the device from the dynamic group depending on the direction of the breach.

Here is a sample rule SQL for a active group

(Note: This is just for reference, you will not need to create any such rule, the active groups rest implementation does all the magic for you)

SELECT 
'temp' as attribute,
current.state.reported.temp as value,
topic(3) as topic,
'>' as operator,
30 as threshold,
'Ravigrp' as groupname
FROM
'$aws/things/+/shadow/update/documents'
WHERE
(current.state.reported.temp > 30 AND NOT (previous.state.reported.temp > 30)) OR (NOT (current.state.reported.temp > 30) AND previous.state.reported.temp > 30)

How to deploy

To deploy the Active group micro-service, head to the below git hub repo and follow the readme for deployment instructions.

https://github.com/tensoriot/active-groups

No, I am your Father — Darth Vadar

While the Active groups in AWS IoT does not have same cinematic impact of epic proportions as when Luke learnt that Darth Vadar was his father, i do believe that Active groups when used right, can be the answer to a lot of use cases within your IoT applications stack. Apart from the use cases mentioned above in this blog, the use of this feature is only limited by the imagination of the user.

--

--