Register a device in AWS IoT Core and read its device shadow

short · 25 min · Task statement 3.8

Task

Register an invented temperature sensor as a thing in AWS IoT Core, publish a reading through IoT Core's message broker and watch it arrive in the console's MQTT test client, then use the sensor's device shadow: record the temperature the device reports, set the temperature an application wants while the device is "offline", and read back the difference IoT Core works out between the two. At the end you can name the three jobs IoT Core does for devices, and tell them apart from what Amazon Kinesis or Amazon EventBridge would do.

Steps

  1. Find your account's IoT Core data endpoint, the address devices connect to, and keep it in a variable for the later steps:
EP=$(aws iot describe-endpoint --endpoint-type iot:Data-ATS --query endpointAddress --output text)
echo $EP

It ends in -ats.iot.us-east-1.amazonaws.com. If CloudShell times out later, run the first line again. 2. Register the sensor in the IoT Core registry, the list of devices IoT Core knows:

aws iot create-thing --thing-name clf-lab22-sensor
aws iot describe-thing --thing-name clf-lab22-sensor --query thingName --output text

The second command prints clf-lab22-sensor. A real sensor would also get a certificate to prove its identity; that is the authentication job, and this lab skips it because nothing physical connects. 3. In the AWS IoT Core console, open Test, then MQTT test client. Under Subscribe to a topic, enter clf/lab22/# as the topic filter and choose Subscribe. The # matches every topic under clf/lab22/. Leave the tab open. 4. Publish a reading to the broker, as the sensor would:

aws iot-data publish --endpoint-url https://$EP --topic clf/lab22/temperature --cli-binary-format raw-in-base64-out --payload '{"temperature": 21}'

Within a second or two the message appears in the MQTT test client under clf/lab22/temperature. That is the brokering job: the publisher and the subscriber never talk to each other directly. A real device would use MQTT; the CLI publishes over HTTPS, which IoT Core also accepts. 5. Record the state the device reports in its device shadow:

aws iot-data update-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor --cli-binary-format raw-in-base64-out --payload '{"state": {"reported": {"temperature": 21}}}' clf-lab22-out.json

The last argument is the file the response is written to. 6. Now act as the application, while the sensor is imagined to be offline: ask for a different temperature by setting the desired state, then read the whole shadow back:

aws iot-data update-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor --cli-binary-format raw-in-base64-out --payload '{"state": {"desired": {"temperature": 19}}}' clf-lab22-out.json
aws iot-data get-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor clf-lab22-shadow.json
jq '.state' clf-lab22-shadow.json

The shadow holds reported 21, desired 19, and a delta of 19: the change still to be made. When the sensor reconnects, it reads the delta and acts on it. That is how an application can set a device's state while the device is offline. 7. In the console, open All devices, then Things, then clf-lab22-sensor, and choose the Device Shadows tab. Open Classic Shadow and see the same reported, desired and delta values. The third job, routing messages to other services with the rules engine (for example, storing readings in Amazon S3), is not built here; it is the step a real project would add next.

Verify

Read the thing and its shadow back (set EP again first if CloudShell timed out):

aws iot describe-thing --thing-name clf-lab22-sensor --query thingName --output text

Expected output: clf-lab22-sensor.

aws iot-data get-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor clf-lab22-shadow.json
jq '.state.reported.temperature, .state.delta.temperature' clf-lab22-shadow.json

Expected output: 21, then 19, on two lines.

Cost and clean-up

IoT Core charges per message and per shadow or registry operation, and the AWS Free Tier covers some of this where your account is eligible. Nothing here charges by the hour, and the thing itself costs nothing to keep, but delete it and its shadow now so the account holds nothing you did not mean to keep.

Created by this lab: the thing clf-lab22-sensor in the IoT Core registry; the classic device shadow of clf-lab22-sensor; the MQTT test client subscription to clf/lab22/#; the CloudShell files clf-lab22-out.json, clf-lab22-shadow.json and clf-lab22-delete.json.

  1. Delete the device shadow, then the thing. Deleting a thing does not remove its shadow, so do both:
aws iot-data delete-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor clf-lab22-delete.json
aws iot delete-thing --thing-name clf-lab22-sensor
  1. In the MQTT test client, end the subscription to clf/lab22/# from its menu, or close the tab; the test client's subscriptions last only while the page is open.
  2. Remove the local files:
rm -f clf-lab22-out.json clf-lab22-shadow.json clf-lab22-delete.json

Check it is gone

aws iot list-things --query "length(things[?thingName=='clf-lab22-sensor'])"

Expected output: 0.

aws iot-data get-thing-shadow --endpoint-url https://$EP --thing-name clf-lab22-sensor clf-lab22-gone.json

Expected output: an error, ResourceNotFoundException, saying no shadow exists for clf-lab22-sensor. If the failed call leaves an empty clf-lab22-gone.json behind, remove it with rm -f clf-lab22-gone.json.

Notes

Telling neighbours apart: Amazon Kinesis takes in large streams of data, but it does not authenticate devices or speak MQTT to them; Amazon EventBridge routes events between applications. Connecting, authenticating and brokering for devices is IoT Core's job.

The lesson's other services are recognised rather than built here. Amazon WorkSpaces and Amazon AppStream 2.0 charge while their desktops and fleets exist, and AWS Amplify is built around deploying from a code repository, so a short lab would add cost without teaching more than the lesson does. The capstone for this lesson builds the developer-tools part: a release pipeline with AWS CodePipeline and AWS CodeBuild.

This is an independent study companion for the AWS Certified Cloud Practitioner (CLF-C02) exam and is not produced by or endorsed by Amazon Web Services. AWS, Amazon Web Services and AWS Certified Cloud Practitioner are trademarks of Amazon.com, Inc. or its affiliates.

This is an independent study companion for AWS Certified Cloud Practitioner CLF-C02 and is not produced by or endorsed by CompTIA.