What is MQTT?
MQTT is an abbreviation of Message Queuing Telemetry Transport. It’s a lightweight network protocol used for publish/subscribe messaging between devices. It’s designed to be open, simple and easy to implement, allowing thousands of lightweight clients to be supported by a single server. An ideal solution for Machine to Machine communication and Internet of Things contexts where a small code footprint is at a premium.
IBM to OASIS
In 1999, Andy Stanford-Clark of IBM and Arlen Nipper of Arcom authored the first version of the protocol. Its original application was to link sensors on oil pipelines with satellites. In late 2014 it officially became an OASIS open standard and multiple open source implementations can be found for a number of popular programming languages. Later in this blog you’ll find an example that uses a JavaScript implementation of the standard called MQTT.js.
Comparison to HTTP
HTTP is a well known and widely used protocol which is used for example to display this webpage. It’s the foundation of data communication for the World Wide Web. It’s a synchronous protocol whereas MQTT is an asynchronous one. The client doesn’t wait for the server to respond which is the case with HTTP. On the contrary with HTTP, MQTT doesn’t use headers and rules which aren’t suitable for constrained networks. In general, MQTT has a faster response time and a lower battery and bandwidth usage.
Messages
At the minimum, a message in the context of MQTT exists of a topic and a payload.
A topic is a string that consists of one or more topic levels. Each topic level is separated by a forward slash. Here are some examples of topics:
- jidoka/mechelen/temperature
- myhome/groundfloor/livingroom/temperature
- Belgium/Antwerp/Wilrijk
The payload of a message is data. This can be text, numbers, image blobs and many other data formats. Messages are sent by clients (publishers) to a broker which sends them to other clients (subscribers).
Clients & Brokers
In the widest sense of the word, a client is a device/machine that subscribes to data or publishes data. Any device that runs an MQTT library and connects to an MQTT broker over a network.
A computer that’s linked to a temperature sensor which publishes the temperature on a regular basis is publisher. A smartphone which is opening a webpage that’s displaying the temperature of a sensor, is a subscriber.
A broker is the heart of an MQTT implementation. It’s responsible for receiving all messages, filtering them and determining which clients are subscribed to each message and sending messages to these subscribed clients.
Internet of Things
MQTT enables us to easily bridge sensors and devices over the web, which the Internet of Things is basically all about: “Connect items/machines to the web”. Think about smart light bulbs, smart doorbells, thermostats but even so called ‘smart cities’ incorporating this technology. It’s expected that IoT will make an impact on government, education, finance and transportation.
With a little bit of imagination, the possibilities are endless. This leads us to the following question: “Should we connect everything to the web”? If we take a quick look to the IoT-parody Twitter-account, @internetofshit, the answer is no. It’s a collection of devices / features where IoT has gone too far.
A Tesla Car with a “Find My Car”-app which honks & flashes lights which gets stuck in loop, preventing the owner of the car entering it. Logging into your Christmas tree to control the lights. The severs of a connected thermostat that are down which prevents people to turn on the heating.
MQTT Example
Our headquarters are located in Hasselt, at the Corda Campus, but we’ve also got a lovely office in Mechelen. Let’s use the office in Mechelen to demonstrate an example MQTT-implementation.
We’re making an online dashboard for our Mechelen office which employees can consult to check the temperature and see if a colleague is present. The temperature can be measured with a DHT22 temperature sensor and the presence with a PIR-motion sensor. Both sensors are wired up to a Raspberry Pi which can read data from the sensors with GPIO pins. A broker is spinned up on a server in the cloud so the sensors can publish data to it.
Our dashboard is a simple frontend application/website that’s subscribing to two topics being:
- jidoka/mechelen/temperature
- jidoka/mechelen/motion
The infrared sensor is triggered every time it’s detecting motion and the temperature is measured every 5 minutes. The dashboard reads these values from the broker which sends them whenever a sensors publishes data or when the sensor is configured so the broker has to store data from the sensor and display it whenever a client subscribes to it. The latter one is the most suitable for a temperature sensor since you don’t want to wait 5 minutes until the sensor publishes new data.
This is what the setup looks like:
On top, you’ll see a Raspberry Pi whose GPIO-pins are connected to a breadboard where our 2 sensors are connected to. The small white square in the center of the board is our DHT22-sensor which can measure temperature and humidity. The passive infrared sensor (PIR), which detects motion, can be found at the bottom of the picture.
Let’s take a look at the code
Here are some simplified code snippets in JavaScript with MQTT.js that illustrate our use case. We’ll be using Mosca for our broker.
Broker
CLIENT – Temperature sensor – PUBLISHER
CLIENT – Infrared Motion Sensor – PUBLISHER
CLIENT – Dashboard Front-end app – SUBSCRIBER
The complete code of the examples can be found on Github.
ESP8266
In the picture of the setup, you may have noticed a small device next to the Raspberry Pi. It’s a NodeMCU microcontroller with an ESP8266 chip. This is a low-cost chip which allows microcontrollers to connect to a Wi-Fi network. The cool thing is that this tiny device is equipped with GPIO pins so any sensor can easily be connected to it. Next to that, it’s very cheap and its power consumption is low. We can replace our Raspberry Pi with this tiny device which makes it very suitable for IoT-applications.
Conclusion
MQTT is a lightweight publish/subscribe protocol. In ‘Internet of Things’ contexts, it’s a valid option when you need devices to communicate with each other. Especially if you want to quickly send sensor-data to multiple clients. The fact that it’s an open standard backed by OASIS and is supported in multiple programming languages, makes it a preferred protocol.
If you’re having questions about MQTT in general or have some cool ideas which you want to discuss, don’t hesitate to contact me at mike.henderyckx@jidoka.be.
Make sure to also check out HiveMQ’s 11-part blog series here if you want to take a deeper dive in MQTT.
