AWS Thing Shadow
Representations with the IoT Gateway
Representations with the IoT Gateway
During re:Invent 2015, Amazon unveiled its AWS IoT offering, aptly named AWS IoT. At the heart of this offering is the concept of Thing Shadows. Thing Shadows are “always on” server side representations of 'Things' in the physical world. They mirror physical Things by maintaining a set of attributes constituting a representation of the state of the Thing and provide state access to appropriately permissioned agents.
The manner in which a Thing Shadow mirrors a physical Thing is up to how you chose to model your data. For example, if you are tracking the temperature, light, and sound level of a room, each individual sensor might be a Thing, or the room itself might be a Thing with properties for temperature, light, and sound. In order to modify a particular Thing Shadow, the modifying agent must have appropriate permissions which can be granted either via X.509 certificates or Cognito. Certificates are meant to be issued to physical devices or gateways, allowing them to act autonomously while Cognito permissions are issued to users affording individuals access to appropriate Thing Shadows.
The state of a Thing Shadow is represented by three sets of attributes: Reported, Desired, and the Delta. Attributes of the Reported state are intended to indicate the true state of the physical Thing, whereas attributes of the Desired state indicate a potential future state as requested by an agent external to the physical Thing. When the Reported state differs from the Desired state, the Delta state will be populated with the difference. Such a setup allows for Things to communicate their state as well as interact with other Things by requesting updates to their states. Similarly, it allows for many common recipes such as remote controlling of Thing behavior by end users.
To further consider the flow of modifications to the state of a Thing Shadow, a recipe for a remote control is considered. In our example, we will investigate the steps which would be involved in controlling a connected thermostat using a consumer facing mobile application.
As the example starts, the Thing Shadow representing a particular thermostat has a Reported state of 68°F, no Desired state, and no Delta. The thermostat itself is connected to the Internet and has installed on it, along with its logic, an X.509 certificate identifying it and giving it access to modify its own Thing Shadow. The user, who plans to change the temperature setting of the thermostat to 70°, has a mobile application installed on their phone. This user has authenticated to the application via Cognito and their Cognito identity has been afforded access to read the state of the thermostat’s Thing Shadow and to update its Desired state.
The user sets the thermostat temperature to 70° by way of their mobile application. This triggers a request to update the Desired state of the thermostat’s Thing Shadow.
Once the Desired state of the thermostat's Thing Shadow is set to 70°, a Delta is calculated. The thermostat itself is subscribed to changes in the Delta of the Thing Shadow and as such is alerted of this modification.
The thermostat reacts to the report of its Thing Shadow Delta by changing the temperature which it is set to. It then updates the Reported state of its Thing Shadow to reflect this change in the physical world. Since this brings the Reported state in line with the Desired state, the Delta is removed.
Finally, the user's mobile application, which is subscribed to updates in the Reported state of the thermostat's Thing Shadow, receives an update indicating that the Reported state of the Thing Shadow is now 70°. This serves as confirmation of the acceptance of the user's request.
AWS IoT is part of the AWS platform and as such integrates cleanly with a number of the AWS technologies, allowing for seamless streaming of data to and from the IoT Gateway. For example, updates to the Thing Shadow may flow through the AWS Rules Engine and be routed to Lambdas for further processing, or may flow through the Rules Engine and into S3 for processing and further propagation to RedShift for warehousing and later BI analysis. Further, updates and state of the Thing Shadows are exposed via HTTPS and MQTT allowing for straightforward external integrations. With a strong understanding of the concepts of Thing Shadows and the manner in which information is intended to flow to and from them, you are made free to leverage them fully in a broader system.
Can’t stop. Won’t stop.
Our AEM and Managed Services teams opine on what this means