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.
About MQTT
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.
Hi, you referred me to MQTT and I first would like to thank you for it. I do have some questions regarding MQTT for which I can not find answers to. For the client library PubSubClient.h from Nick O’Leary, I see the standard packet size is 128bytes, I would like to know:
1. How many bytes are added to the original payload as oppose to HTML?
2. What are the size limitations for a packet and what are the concerns?
3. There is a keep alive interval set for 15 seconds, can I make this indefinite (as long as the Arduino is powered) or is there some concerns?
I know the settings are configurable, but I require a reliable system, I have tested up to a 1000 runs and I have not experienced any data loss although the Arduino client library is limited to QOS 0:
6. what configurations would increase the likelihood of data loss?
I have since grown very fond of MQTT and I am excited to teach those at my university. Thank you
Hi Christo
Thank you for your interest. Always glad to help and discuss. Most of your Questions are answered by the MQTT Specification.
1. The fixed standard header is two bytes. The size of the variable header for publishing messages depends on the length of the topic name.
2. With the packet size limitation, splitting the payload over mulitiple MQTT messages can be prohibited.
3. The Keepalive interval tells the boker after what timeout started on the receiption of the last message, the client is considered as disconnected. It is limited to two bytes, i.e. 65536 seconds
4. The likelihood of data loss is increased by increasing traffic on and the size of the network between your publisher and your subscriber, i.e. if you use a small local network with only one arduino and one Raspi the likelihood is significantly smaller than when you push your messages over the internet all around the globe.
5. Yes, a client can be publisher and subscriber simultaneously. A subscription is kept until you unsubscribe or disconnect.
Best Regards
Stefan