Lab Notes: Exploring the AWS IoT Platform

For our latest stop on our tour of Internet of Things (IoT) development platforms, we explore Amazon’s AWS IoT platform. We have made our way through a number of the most well-known platforms currently available and we are doing the same use case on each one. Our previous exploration was of the Microsoft Azure IoT Platform, and you can read more about that here.

We have based each of our examples around monitoring the climate, and this example is no different. The variables have been the platform and hardware used. For the AWS IoT platform there are a range of devices available with the easiest being the AWS IoT button that we have written about previously. Some of the available IoT kits have better documentation than others, but for us part of the appeal is knowing the entire stack and its challenges so we skipped the normal kits and went with the brand new Espressif ESP32 device for this evaluation. The Espressif ESP32 is the big brother of the popular ESP8266 and includes more IO options, two cores, and more memory. The increased memory is the most critical part for this project.

What We Did

The ESP32 is new enough that there isn’t a good Arduino port for it yet so we had to use the command line build system. They have taken care to make it really easy to use, however, so it wasn’t too bad to get set up with a simple demo using their template. One of the critical parts that the ESP32 development environment comes with is support for TLS via mbedtls. The AWS IoT system doesn’t support unencrypted traffic and if your device can’t support TLS you have to use a proxy. This is one of the reasons we picked the ESP32 instead of the existing ESP8266 platform. The ESP8266 doesn’t have quite what it takes to connect directly to the AWS IoT system.

Amazon has created an embedded device SDK specifically made to support devices like the ESP32. The SDK does a lot of the heavy lifting for you and even comes with support for the more advanced AWS IoT concepts like device shadows. This SDK doesn’t support the ESP32 right out of the box so we had to do some work to create a port. We are sharing the resulting port, build setup and a complete ESP32 AWS IoT example on Github.

For the environmental sensor we used the DHT22 temperature-humidity sensor again. The lack of a complete Arduino port for the ESP32 again meant that we had to hand roll our own driver but that wasn’t too difficult. We adapted the existing Adafruit DHT22 library and after some tweaks it was working well. The readings from the DHT22 sensor are bundled into a simple JSON payload and then sent off to the AWS IoT system via the AWS embedded device SDK. It is worth noting that the ESP32 development environment comes with a JSON library that makes creating a JSON payload a snap.

There are a number of steps that are required to provision devices in the AWS IoT system. Due to the complexity of provisioning AWS IoT devices we will assume that is something you are already familiar with, and if not, please check out the security section of the AWS IoT developers guide. It is important to note that Amazon has put a lot of care into the security of their platform and that is one of the reasons provisioning is complicated. They also have provided a lot of flexibility for both simple use and very complex use of their provisioning system so that it is usable at both a small and large scale.

The AWS IoT platform is an entry point for any of the existing server side processing options on the AWS platform itself. For the most part that is anything you can imagine. In the AWS IoT button post we described one of the best positioned options and that includes AWS Lambda. Because we had already built a system for handling our other devices using Python + PostgreSQL we decided to reuse that instead of creating something new using Lambda.

We did have to modify our server side system slightly to support the AWS IoT platform but it has a model very similar to that of Azure so it didn’t require much. We used the AWS IoT Python SDK and installed it using the pip command:

pip install AWSIoTPythonSDK

On the device side we are putting the JSON payload into a queue that is then pulled off the queue using the Python SDK. We wanted to support multiple devices with the same server so the Python system listens to the root name of the queue we created, “/awsiotdevices”, while the devices publish to a device specific queue, e.g. “/awsiotdevices/aws-device-100001”. For now we are building the device IDs used in the queue name by hand but there is evidence that every ESP32 has a globally unique identifier and if we continue to use this conversation we will work on finding a way to read that for use in the queue instead.

Challenges

The biggest challenge we had was working with the ESP32. Because it is so new there are very few examples or drivers for it at the moment so it required more attention than what we would normally have to provide for a hardware platform. Beyond what was mentioned above, when we started the project there wasn’t a good way to synchronize the time on the device with a time service but by the time we finished the work they had updated the ESP libraries to provide a solution. Over time, the lack of examples and drivers for the ESP32 will resolve itself but in the short term it will continue to be something to consider.

The complexity of setting up security and provisioning can also be a challenge. We opted for the simplest solution for a single device but there are more complex options available that can grow to a device manufacturing scale and involve very detailed measures to ensure both security of the system as a whole and flexibility to provide a simpler way of managing devices by the end user.

Next Steps

Overall the AWS IoT platform has had the best documentation of all the platforms we have evaluated. It appears to be the most well thought out of the bunch as well with a path to work both at a small scale and a large scale with the same platform. At the moment we believe that the AWS IoT platform represents the best platform for those who need a larger deployment and even smaller deployments that have the potential for needing to scale. For rapid prototyping a proof of concept it is hard to beat Particle.io, as it also has a great deployment system.

Given that we have landed on two well-positioned platforms we are going to concentrate more on extending the work we can share with those two platforms. We will also continue the overall evaluations of various platforms that we have been doing but they are likely to be spread out more. A few of the items we have in mind are creating a dashboard for the information we have been gathering and utilizing more of the available infrastructure from each platform such as device shadows and functions.