The “Internet of Things” (IoT) is not only a vision for future communication and interaction systems, but an active and emerging field of research in both academia and industry. IoT is not just a new term for “remote controlling a device over the Internet”; IoT is a concept of multiple devices communicating and interacting with each other and the environment mostly without human interaction. There can be human interaction, but it is considered to be a subset of the interaction with the environment. This introduces new requirements on the communication protocol, such as machine-interpretable data and – especially if small embedded devices shall be included into the network – resource restrictions. This article is focused on the implications of the latter, and shows a possible solution based on two small examples.
The Drawbacks of HTTP
Thinking of “the Internet”, many people – including those with a technical background – think of the Hypertext Transfer Protocol (HTTP) that is used to transport information mostly in HTML- and XML-Files. HTTP is great for the communication between powerful devices from Smartphones up to large Serverfarms. But, HTTP has its limitations: As it has been presented in an earlier Blog-Post, the resource usage and overhead is not negligible, especially not in an embedded setting. When an Ethernet-based protocol shall be used to send and receive live information data that is characterized through frequent but very small messages, the ratio between overhead and intended Information gets even worse. So HTTP is not in every case the protocol of your choice.
The MQ Telemetry Transport (MQTT) Protocol is a lightweight TCP/IP based messaging system. It is mainly characterized through it’s simple, yet powerful subscribe-publish mechanism: Every client can subscribe to topics that are published on the network. Each time, a client publishes a message to a specific topic, all subscribers receive this message and are able to use the information to their needs. Besides the clients, a server – “broker” in the MQTT terms – manages the topics and the subscribers. This enables dynamic adding and removing of clients. As the message headers are only a few bytes, the communication overhead is reduced to a minimum. This leads to a minimal network load and client resource usage. Furthermore, MQTT supports different encryption and authentication mechanisms, as well as message delivery control by applying a QoS-Flag (Quality of Service) to each message.
These characteristics qualify MQTT to be seriously taken into consideration when designing Internet of Things applications.
There are several implementations of MQTT available that target different applications and architectures. Below, two examples of the usage of existing implementations are shown. Additionally MQTT is supported by several middleware solutions, such as RabbitMQ or Spring.
Example 1: MQTT on an Arduino
In a first example, an implementation of the MQTT protocol on an Arduino Ethernet R3 shall be illustrated. For this, the PubSubClient by Nick O’Leary can easily be used. This Client, combined with the standard Arduino Ethernet API, lets you implement a responsive client in just a few lines of code that uses only a fraction of the very limited resources. An implementation of the same functionality with a HTTP-Server would have used about half the Arduino’s resources. When you add just a little functionality, a HTTP-Server runs into the limits of an embedded platform.
Example 2: MQTT on a Raspberry Pi
Although a Raspberry Pi offers enough resources to host a Webserver, MQTT can also be used there. For example, when you use a Raspberry to collect information from Arduino-based sensors for logging and user presentation. Assuming the Raspberry Pi is using Rasbian or another Linux-Distribution, mosquitto is a useful framework for the usage of MQTT. With the C++-Wrapper class mosqpp::mosquittopp, you are given the full functionality of the MQTT protocol. Just derive a class from the base class and implement the client-specific behaviour, and you’re ready to go.