In this initial lab, we will go through the overall architecture of the CDD. At the end of the lab, you will come away with the understanding of:
When interacting with the cloud, the architecture utilizes two main paths, AWS IoT Core for MQTT communication and then a dispenser app with authentication to interact with the device and supporting databases.
For each individual user, there is a set of resources created and related during the user account creation process. A user, foo, authenticates with Cognito and is returned a signed JSON Web Token (JWT) that contains information used by the dispenser app and API Gateway. For instance, user foo is associated with dispenserId of 123. Any API calls made use the dispenserId attribute to ensure that requests are only for the user’s dispenser and not someone elses. The value is also used to send and receive messages on specific MQTT topics so that one dispenser cannot be affected by another dispenser’s actions. This is a common field used throughout the backend cloud services.
Your dispenser will only use MQTT to communicate with the cloud services. There are two main methods that a device uses to communicate. The first is through regular topics such as telem/123 where the device can subscribe to receive messages, or it can publish messages directly to the topic. In this case, telem indicates telemetry and normally would be messages sent from the device to the cloud.
For this workshop. instead of command topics you will actually use the shadow set of topics. This is a provided service of AWS IoT that tracks the state of a device. Each device has both a desired and reported state. It is common that cloud services would set the desired state, and the next time the device is online, it would read those values, set them locally, and update the reported state accordingly.
A device can also use the delta state that tracks the difference between desired and reported states.
The shadow document will look similar to this:
{
"desired": {
"led_ring": {
"count": 0,
"color": "#FF00FF"
},
"led": "on",
"dispense_time_ms": 4000,
},
"reported": {
"led_ring": {
"count": 0,
"color": "#FF00FF"
},
"led": "off",
"dispense_time_ms": 2500,
},
"delta": {
"led": "on",
"dispense_time_ms": 4000
}
}
In this example, there are two values that have been requested to be changed, led and dispense_time_ms, as reported by the delta state.
Finally, there are AWS IoT Rules that are triggered upon the content of messages published. In the diagram above, the IoT rule LogEvent is triggered when the shadow document changes, passing the details to an AWS Lambda function that will write the parsed message content to the Events database table.
This module provides a high-level description of the various components used in the workshop. After completing this lab, you should have an understanding of:
As this lab is informational only, there are no specific checkpoints that need to be completed.