If two devices have to talk to each other, they must adopt the same protocol. In the past, I’ve already shown different types of communication, for example between Arduino and a C# program, Arduino and a website or Arduino and an NTP server.
All those communications are point-to-point ones, that is between two actors. Today I’m instead going to introduce you a quite special protocol: MQTT (MQ Telemetry Transport).
The MQTT protocol was invented in 1999 by two researchers (Andy Stanford-Clark of IBM and Arlen Nipper of Arcom) and its specs are public (IBM website). Its most important features, that make it very suitable for machine 2 machine communication, are:
[checklist]
- it’s a publish/subscribe protocol
- it’s very simple
- it has a very low overhead (= amount of data to be sent for the protocol itself)
[/checklist]
Publish/Subscribe
The main feature of MQTT is to be a publish/subscribe protocol.
In a traditional communication, the source of the data (for example a temperature sensor) sends it directly to the final user (for example the thermostat):
In a publish/subscribe communication, instead, the sensor sends (publishes) the data to a central system called broker. All the devices that need that data talk to the broker (they subscribe to it) and the broker sends them the data when available:
The main advantage of the pub/sub paradigm is to decouple the data source and the destination:
[checklist]
- spatial decoupling: there’s no need of a direct connection between data source and destination;
- temporal decoupling: the data source doesn’t need to be active at the same time of the destination;
- synchronization decoupling: operations are not halted during publish or receiving.
[/checklist]
From what above said, it’s easy to understand why the MQTT protocol and the pub/sub paradigm in general is very used in the Internet of Things: the simplest devices, often powered by batteries, can activate every tot seconds, send the data to the browser and return to power saving mode. It’s the broker, that is always active, to send the data to the end users (actuators, dashboards…) when it’s needed.
Topics
A broker can manage a huge number of messages, coming from different sources and intended for different users. How can it correctly route those messages? Thanks to the topics: each message is published to a specified topic (a temperature sensor for example can use temp as the topic for its data). When subscribing, the user has to specify one or more topics it wants the data of (in our example, to receive data from the temperature sensor, the thermostat should subscribe the temp topic):
Later I’ll explain how topics are structured and how it’s possible to subscribe more topics using wildcards.
Mosquitto
After the introduction part, let’s see how to use the MQTT protocol. You now know that the most important element is the broker: one of the most used software as MQTT broker is mosquitto.
Mosquitto is available for almost all the operating systems (Windows, Linux, MacOS); today I’ll show you how to install and use it under Windows.
First, download the latest version from the official site and unzip the archive in a new folder.
We also need two external libraries, from OpenSSL and pThreads. Let’s start downloading the OpenSSL build for Windows (very important is to download a version from the 1.0.x tree):
From the folder where OpenSSL was installed, copy libeay32.dll and ssleay32.dll to the mosquitto folder:
Now download the pthreadVC2.dll library from SourceWare and copy this file too in the mosquitto folder
This is the final content of the mosquitto folder after having copied the three libraries:
First example
Now we can run mosquitto. Open 3 command prompts: one to run the broker, one to simulate the temperature sensor (publish) and one to simulate the thermostat (subscribe).
In the first prompt, run the broker, with the -v parameter to activate the verbose output :
In the second prompt, use the mosquitto_sub to subscribe the temp topic:
In the third prompt, use the mosquitto_pub command to publish the temperature value (21° for example) to the temp topic:
If you go back to the prompt where the mosquitto_sub is running, you can see that the temperature value has correctly been routed and received:
Conclusions
In this first article, I introduced the pub/sub paradigm and the MQTT protocol. I’ve also shown how to use mosquitto as a broker to send/receive messages. In the next articles, I’ll show you some real examples, with Arduino (and not only…).
1 Comment