Test-driving the new AWS IoT for fun and profit

AWSIoTHeader

At VIA we are always looking for new ways of using our embedded boards and systems, fortunately these days there is no shortage of new and exciting developments to put to the test. After hearing of last week’s Amazon Web Services (AWS) Internet of Things (IoT) beta release announcement, I couldn’t wait to get some first-hand experience with it.

As the AWS IoT developer guide lays it out, the platform’s aim is to enable communication between Internet-enabled devices and Amazon’s cloud services, following their modus operandi of creating interesting mash-ups of their existing services for new use cases.

Environmental Monitoring

To create a hello-world setup, I put together a small system that should match their vision for potential uses cases: an internet connected board with a sensor to capture real-world data. My setup includes our VAB-820 board running Linux; a GroveHat breakout board for connecting accessories; a SparkFun BMP085 barometric pressure/temperature sensor; and a Grove LED – because every hardware-based hello-world project should have an LED…

The real face of IoT
The real face of IoT

The plan was to record our office temperature and atmospheric pressure, send the data into the cloud for further analysis, and then feed back to the device for some interactivity.

At the core of the AWS IoT setup are the Things – the abstract connected devices in your code that supply a steady stream of sensor data or that can manipulate the physical world. Expanding on this concept is the introduction of Thing Shadows, which represents a device which may send or receive data, but may also go offline. When offline, the “shadow” of the device can be still be manipulated allowing the actual device to catch up once it comes back online. I feel it’s a great idea to include this as a core concept of the platform as connection and data persistency is an issue that comes up in every IoT project without fail.

After digging into the developer guide and studying the examples supplied by the Node.js version of their Device SDK, I managed to get my system up and running.

[bash] root@via:~/awsenvmonitor# npm start

> awsiot1@0.0.1 start /root/awsiot1
> node app.js

connected to things instance, registering thing name
registered thing shadows…
{ temperature: 23.6, pressure: 1013.7641755627757 }
{ temperature: 23.6, pressure: 1013.6727162499275 }
{ temperature: 23.6, pressure: 1013.7375779550399 }

[/bash]

Thing Shadows are an interesting concepts, representing a device, which supplies data to the rest of the system or consume settings, but can go offline. When offline, the “shadow” of the device can be still manipulated and the actual device will catch up once it comes back online. I feel it’s a great idea to make this into a core concept of the platform, connection and data persistency is an issue that comes up in every IoT project, without fail.

The next step was to get my data working for me. This is made possible by setting up Rules about what Actions to take on the data: whether it should be streamed, stored, served, used for alerts and a lot more. An example would be sending an alert message to a phone if the temperature in a server room is above 22°C (as apparently the optimal server room temperature is 20-21°C, TIL), or logging in a database the times when the office lights were on (for security or energy conservation purposes). I didn’t go that far, but did try out a few Rules and Actions to get a feel for it.

Experience

The basics of the setup worked like a charm. Setting up a device and get it running was relatively straightforward, however the documentation leaves room for improvement. There were plenty of simple use cases that I couldn’t figure out in the first few hours of using the platform, for example the intricacies of “desired” and “reported” versions of sensor data, or the dual use case of MQTT channels that is different for Things and Thing Shadows, or workable filtering of data through Rules. The documentation has plenty of information but doesn’t always cover the multiple ways of doing the same thing in the different versions (Embedded C, Node.js, Arduino Yún, mobile and command line interface) of the SDK.

The killer feature of AWS IoT is of course making use of sensor data through other AWS services. This makes the learning curve much steeper as to make the most of it you also need to be proficient in at least a few other services, each with their own quirks. However, even though I am not an AWS expert, I still got a good sense of what advanced users might experience when everything falls into place.

Epilogue

For real world IoT use cases there are three things required: hardware, software, and communication. After having built a number of projects on our hardware platforms, I have a much better understanding of what makes a great solution for the first side of the triangle. For the software side (OS, or application delivery), there are also a number of great solutions coming out, such as Resin.io, which allows people to enjoy painless one-click software deployment. Amazon AWS IoT is aiming to take care of the final side, where one can spin-up an inter-device communication network literally within minutes for example. It is a very exciting time seeing all the required components coming together.

For reference, the source code of this hello-world project is available on Github.

What would you use AWS IoT for? If you build anything, let us know, or you can post your own project on sites like Hackster.io, where you can also find other people’s projects using AWS or VIA devices.

VIA Technologies, Inc.