Serverless IoT

Video

Introduction

Today I will present a simple serverless IoT architecture. Serverless is a popular designing concept for cloud applications. It is not always obvious that it can be used in IoT systems.

I will show a sample design of a system with three Thermometers and Fan (illustrating an air conditioning device).

Those connected devices have very limited capabilities:

• Thermometers are able to send readings to the cloud
• Fan is able to receive commands (on/off) from the cloud

MQTT Topics

Before we start actual implementation, we need to define MQTT Topics used in our system.

Assumptions:

• Our system can be used by multiple Users.
• Every User can define multiple Rooms.
• User can install multiple Thermometers (Temp) in every Room and single air conditioning device (Fan).

This is extremely simplified example, but it presents an approach that can be extended in real-file scenarios.

Thermometers

The MQTT Topic structure used by Thermometers looks as follows:

USER_ID/ROOM_ID/TEMP/TEMP_ID

where:

• USER_ID - is an unique identifier of an User (i.e. USERABC)
• ROOM_ID - is an unique identifier of a Room that belongs to above User (i.e. ROOM1)
• TEMP - is a MQTT Topic level reserved for Thermometers
• TEMP_ID - is an unique identifier of a specific Thermometer (i.e. 1)

Fan

The MQTT Topic structure used by Fan looks as follows:

USER_ID/ROOM_ID/FAN

where:

• USER_ID - is an unique identifier of an User (i.e. USERABC)
• ROOM_ID - is an unique identifier of a Room that belongs to above User (i.e. ROOM1)
• FAN - is a MQTT Topic level reserved for a Fan assigned to the ROOM_ID

MQTT QoS

The MQTT Quality of Service (QoS) level is an agreement between the sender of a message (i.e. Thermometer) and the receiver of a message (i.e. AWS IoT Core). It defines the guarantee of delivery for a specific message.

There are 3 QoS levels in MQTT:

• 0 - at most once
• 1 - at least once
• 2 - exactly once

💡Note: At the time of writing, AWS IoT Core does not support the QoS 2 (docs).

A typical approach when defining the MQTT QoS is following:

• non-critical messages should be sent using the QoS 0
• critical messages should be sent using the QoS 1 (we need the guarantee that message will be delivered)

Temperature readings are frequently send to AWS; they are not critical - we will use the QoS 0.

Fan control messages are important; a fan should be turned on/off when needed - we will use the QoS 1.

Overview

We defined the MQTT Topic structure and the Quality of Service for specific messages.

💡Note: If you are interested in additional information about the MQTT Topics design I recommend this pdf: Designing_MQTT_Topics_for_AWS_IoT_Core.pdf

AWS Setup

There are many ways to implement the logic of our system. I recommend using the IoT Rules.

Rule query statement:

1

SELECT 'on' as state FROM 'userabc/room1/temp/+' WHERE temp > 25

Our Fan will be turned on once the temperature raise above the 25C.

We need to add an action to our Rule:

We want to republish the MQTT message to the MQTT Topic assigned to the Fan.

Topic: userabc/room1/fan
QoS: 1

You may need to create an IAM Rule that allows IoT Core to send MQTT Messages to specified MQTT Topic.

In the same way, we will create the second IoT Rule that turns off a Fan of when the temperature falls below 20C.

Rule query statement:

1

SELECT 'off' as state FROM 'userabc/room1/temp/+' WHERE temp < 20

Our solution looks as follows:

Test run

In order to keep this example simple, we will use the AWS IoT MQTT test client.

Test 1

Let’s pretend that the Thermometer 1 sent value 26.

Topic:

userabc/room1/temp/1

Message payload:

1
2
3

{
  "temp": 26
}

Our Fan received message:

1
2
3

{
  "state": "on"
}

Test 2

Let’s pretend that the Thermometer 1 sent value 23 (the Fan already decreased a temperature in this room).

Topic:

userabc/room1/temp/1

Message payload:

1
2
3

{
  "temp": 23
}

There is no new message in userabc/room1/fan as the temperature in Room1 is between Min (20C) and Max (25C) - there is no need to change the state of a Fan.

Test 3

As the final test, we will send the following message.

Topic:

userabc/room1/temp/1

Message payload:

1
2
3

{
  "temp": 19
}

The reported temperature is lower than 20C. The IoT Rule published {"state": "off"} message to turn off the Fan.

Feel free to test how this system will behave when you publish messages from other Thermometers (i.e. userabc/room1/temp/2)

Summary

It was meant to be a short article, but we covered a lot:

• MQTT Topic structure design
• MQTT QoS levels
• AWS IoT Rules
• AWS IoT MQTT Test client

This simple example presents a real solution architecture. The Serverless design ensures that an IoT system will scale to meet the required load without any changes in deployed infrastructure.