AWS IoT – mass device control for home and industry
Two years ago, I created my first IoT project for home. It was a smartphone-driven remote control for a gas boiler. The app made it possible also to control temperature at home. In my previous article, I showed you how I had solved some of the problems related to live data synchronization and connecting to a driver in a GSM network. Today, I’d like to show you how to use the IoT service in the AWS (Amazon Web Services) cloud to connect to many appliances at home in a much easier way.
Table of contents
This text will make you familiar with the pros and cons of AWS IoT and – if you have some time to spare – teach you how to build a simple control system for your household devices.
In its IoT service, Amazon offers a real lot of functionalities such as monitoring and certificate or statistics generation. The platform has numerous opportunities and a wide range of uses. This subject is really broad and actually deserves a series of books, but in this article, I’d like to touch upon the most interesting issues related to it.
Knowing the rudiments will be a great introduction to more advanced functionalities, which you can read about in, for instance, the AWS documentation. For now, let’s begin with relatively simpler topics.
My experience with IoT
When I began creating my driver, I wanted to install REST API inside it. However, it soon turned out that it was impossible to connect to the driver via internet because the internet connection was provided by a GSM operator. This kind of device in a way belongs to a subnetwork of a given GSM operator, which makes the connection virtually impossible – due to the specifics of the GSM technology. To solve that problem, I had to use a proxy server with a public IP. I chose a simple AWS EC2 microinstance, where I placed the REST API and the WebSocket servIn my previous text, I told you how I’d created a gas boiler driver. The app consisted of three modules:
- the client application – the driver was connected to the boiler, connecting with the server through WebSockets,
- the server application – it ran the WebSockets and REST API servers for the Android mobile application,
- Android mobile application – its function was to control the boiler.
Eventually, the architecture I developed and implemented was the following:
- The boiler driver connected to the GSM server and listened for commands, maintaining the connection through WebSockets.
- The REST API awaited requests: in the case of a request to change the driver state or providing information about the driver status, appropriate notifications were sent through WebSockets with the client driver, and then a reply was passed to API.
The drawback of that solution was that I could not read the changes from the level of the app. Any time I wanted to check the driver status, I had to click refresh. The missing piece was duplex communication.
One of the solutions to that problem could be to put up a queue: the driver could push information about its status there, through WebSockets; the Android mobile app could listen for changes by means of the listener pinned to the adequate topic in the queue. In that case, however, the queue must be configured and managed, logs must be examined, etc. The response to that inconvenience is AWS IoT.
The service includes many facilities: queues, status refresh, certificates, safety connection, reports, and statistics.
What is AWS IoT?
IoT is one of the fastest-developing branches in the market of modern IT technologies. The Internet of Things has many applications in consumer solutions, e.g. house or car systems, as well as in industry. The problem these networks face is the variety of connected devices. Their uses and work conditions differ. To maintain such a diverse infrastructure and take care of its safety, you need to spend a lot of money and time.
AWS IoT helps solve these problem. You can easily add any device to the universal, stable, and secured cloud. Apart from the synchronization as such, this service focuses on collecting, storing, and analyzing data. All that can be found in one place, you don’t need to create your own backend. Thanks to the serverless architecture, AWS IoT solves a great majority of the creation and management problems as well as the issues related to maintaining the server layer. In combination with built-in AI modules, it expands the functionalities of your devices.
The service is available in the AWS Cloud, used by global brands. Quick, stable, and available in the whole world, the servers perfectly suited for scaling are definitely a good choice. No matter how many devices you have – AWS IoT will free you from analyzing the technical aspects of that server and it will help you concentrate on developing your idea.
Basic services
As I’ve mentioned in the introduction, Amazon offers plenty of services under the common name of IoT. The graph below is a sum-up of these services.
I’d like to highlight the crucial functionalities which form the basis of AWS IoT:
- sending the info about the device state to a given topic in the queue,
- device state update – Device Shadow service.
Further in the article, I will focus on a couple of examples showing how to create an app which collects and sends messages to the queue. I will also show you how to update the device state (resulting from the connection loss) thanks to the Device Shadow service.
Communication
The way of communicating in AWS IoT is pretty easy. Each device which is connected to the internet makes a connection with the AWS Cloud. The connections are encrypted based on certificates generated by either AWS or the user.
A certificate may be acquired in two ways:
- you can generate a one-click certificate in the AWS Console,
- you can deliver your own certificates to establish connections; however, the certificates must be signed by a CA.
According to AWS, each device should connect using its own certificates. Therefore, one certificate should not be used by multiple devices for security reasons.
Only an authorized device can send data to a given topic in the queue (for example, temperature sensors) or listen for the state change request. What’s more, you can assign particular policies to individual certificates to determine whether a given device should listen for requests or push to queues.
Why not EC2 and your own queue?
In the case of the EC2 instance (Amazon Elastic Compute Cloud), the developer’s task is to make sure the queue is configured and to select a proper instance to traffic. In order to ensure high availability, you must use the cluster, the load balancer, etc. You also need to perform stress tests to ultimately achieve something you might get at a reasonable price in AWS IoT.
In professional applications, e.g. in industrial automation, having your own queue set in a cluster is justified. However, when you use automation at home, when you simply need to start a few sensors or drivers controlling no more than twenty devices, using EC2 makes little sense.
In AWS IoT, you send a proper communication to the topic, without having to worry whether the cluster is overloaded or if the instance works properly. AWS manages the queues and the infrastructure. It’s not the service provider who is responsible for ensuring high availability and that’s where the greatest advantage of AVS over EC2 lies.
Shadow Device Service
In my opinion, the Shadow Device service is the most interesting one offered by AWS IoT. What is it all about? If any device registered in the cloud disconnects for an unknown reason, and you want to change its state, for example, to send a request to a lightbulb to turn it on, the Device Shadow takes on the responsibility for the state of this device (in this case, being online) after reconnecting to the cloud. How does it work in practice?
Each message sent to the device, e.g. from your smartphone to the lightbulb, goes in two directions:
- the first message is sent to the lightbulb itself through the cloud,
- the second message is sent to the Shadow Device service and stored there. If the lightbulb is offline, after reconnecting it to the cloud, the Device Shadow will update its state.
Since AWS manages this kind of data on its own, the developer doesn’t need to update the state. The Shadow Device sends one update of the latest state. In other words: if the lightbulb was offline and its state changed three times in the meantime, the Shadow Device will only send one update about its latest state. Thanks to that, the developer won’t have to worry about the state update of each single device.
That means tangible benefits. Imagine your cloud operates 20 lightbulbs, 5 temperature sensors, 3 humidity sensors, and 30 electrical relay switches at your home. Verifying the availability and updating the state of over 50 devices is problematic and, above all, time-consuming. Apart from implementing the logic of change, measurements, and the device control, the developer has to manage all the corner cases for each type of device, such as connection loss, message redelivery, etc.
This way, the programmer is able to concentrate on the device state change logic, and the updates will be handled the Shadow Device.
The piece of code below will show you how I’ve created a class representing the lightbulb state in the code. The object in this class is automatically synced with the Shadow Device.
In order to automatically change the device state, you need to declare the class, just like in the example below, with annotations indicating specific attributes of the object:
public class BulbDevice extends AWSIotDevice {
@AWSIotDeviceProperty
private boolean activated;
public BulbDevice(String thingName) {
super(thingName);
}
public boolean getActivated() {
return activated;
}
public void setActivated(boolean activated) {
this.activated = activated;
}
}
The class of the device should inherit from AWSIotDevice, and the managed attribute should be annotated as @AWSIotDeviceProperty.
The device status in the Shadow Device is saved in the JSON file in “state”. Here you can see the simplified version of this object:
{
"state": {
"reported": {
"activated": false
}
}
As you can see, the lightbulb state indicates it’s off. If you want to turn it on, you must send the request for state change in the “desired” object.
{
"desired": {
"activated": true
},
"reported": {,
"activated": true
}
}
To update the state of the device, you can use two methods:
- send a request manually,
- edit the JSON object defining the device state in the web interface of the AWS Console.
The Shadow Device service will make sure the state of the lightbulb is updated.
Protocols
Owing to the variety of the connected devices, AWS IoT offers lots of bidirectional communication protocols with its platform. All of them support encryption and IPv6.
MQTT
One of the most available and used protocols in the queue systems for non-uniform devices. It’s lightweight and simple to use, based on the publication/subscription pattern. In AWS IoT it’s used to send messages to queues.
MQTT over the WebSocket Protocol
You might think that the MQTT protocol is absolutely sufficient and doesn’t require any alternatives. That’s partly true – MQTT itself perfectly meets its own requirements, but what if you want to use it on a website? Unfortunately, they don’t support this technology for now. However, this can be remedied by implementing MQTT in WebSockets, available in most browsers. Messages channeled this way are delivered without being blocked by firewalls and proxies.
HTTP
If you don’t need a real-time connection, you can use the widely accessible HTTP. AWS IoT gives access to REST API, which helps you place a given task in a queue. This action can be performed even at the level of the request line:
curl --tlsv1.2 --cacert root-CA.crt --cert 4ba4f63de5-certificate.pem.crt --key 4ba4f63de5-private.pem.key -X POST -d "{ "message": "Hello, world" }" "https://j843ks1202jnsj3.iot.us-east-1.amazonaws.com:8443/topics/my/topic"
Jobs
The possibility of managing particular, individual devices out of a thousand of others, provides a lot of opportunities. However, it may happen sometimes that a much smaller functionality is needed. This might be mass communication with all the devices at once.
The AWS IoT Jobs module has been created to execute and track bulk tasks sent to the whole device fleet. They are sent at the same time to selected or all devices. The advanced technology makes it possible to simultaneously track the action results in each separate device.
There are numerous application of this service: you can use it for mass firmware, software, or file update (e.g. certificates). The Jobs modules allows you to perform administrative actions as well, such as restarting devices or running diagnostics. In extreme cases (which I don’t wish to anyone), you can also restore the connected devices to the delivery state – or any other state.
Applications in global businesses
LG
One of the leading technology companies made use of AWS IoT to connect – among others – TV, fridges, and cooling systems.
Bayer Crop Science
This division of the Bayer pharmaceutical corporation improves the agricultural industry by systematic monitoring and analyzing crops and harvest in the whole world.
GoPro
This brand, popular with all lovers of recording, has used the Amazon IoT platform to connect devices, mobile apps, and other software in real time.
Summary on AWS IoT
As I’ve shown you in this text, AWS IoT offers a number of conveniences for people who construct automation systems for home or industry. The most important and interesting functionalities – which I always missed while creating my own automated networks – are the following:
- real-time bidirectional communication,
- state update for an offline device.
AWS found solutions to these issues thanks to the IoT service. However, they are not the only things you should focus on here. IoT features much more: statistics, jobs, various communication protocols. AWS solutions are available at reasonable prices, which makes their offer even more attractive. Why don’t you try using IoT on your own?
Share this article: