MQTT is an easy way for Internet of Things (IoT) devices to communicate with each other. This light-weight protocol can be used with a simple 8-bit Arduino to a Raspberry Pi to a multi-core PC to Amazon Web Services. It is that versatile.
This MQTT Tutorial is broken into two parts. Part one is an MQTT Introduction. You’ll understand how publish/subscribe message brokering works. Next week, Part two will be a tutorial on using MQTT to communicate between a PC, Raspberry Pi, and ESP8266.
Right now in my house, I have motion sensors, RGB LED strips, Hue lightbulbs, and a Raspberry Pi with a QT GUI to control it all. My goal is to make the devices communicate with each other.
At first, I thought sending HTTP requests to a web server was the best option for things like motion sensors and the RGB LEDs. My plan was to write a very simple web server that handled RESTful HTTP requests.
That is until I found learned about message brokering and MQTT.
“The nice thing about standards is that you have so many to choose from.” –Andrew Tanenbaum, Computer Networks, 2nd ed, p254.
When it comes to devices communicating over TCP/IP, there is no lack of protocols. The key is choosing the right one. Understanding the protocol is part of choosing it for your application. You could probably use another protocol for message brokering, but most IoT devices use MQTT.
Let’s explore what it means to be a message broker.
Message Broker Introduction
A messaging broker system is a publish/subscribe protocol based on a “hub and spoke” model. Great. What does that mean? First some terms and then an analogy.
Message Brokering Basic Terms
- Broker: The broker accepts messages from clients and then delivers them to any interested clients. Messages belong to a topic. (Sometimes brokers are called “servers.”)
- Client: A “device” that either publishes a message to a topic, subscribes to a topic, or both.
- Topic: A namespace (or place) for messages on the broker. Clients subscribe and publish to a topic.
- Publish: A client sending a message to the broker, using a topic name.
- Subscribe: A client tells the broker which topics interest it. Once subscribed, the broker sends messages published to that topic. (In some configurations the broker sends “missed” messages.) A client can subscribe to multiple topics.
- Unsubscribe: Tell the broker you are bored with this topic. In other words, the broker will stop sending messages on this topic.
Post Office Analogy
Regardless of which part of the world you live in, you probably have a postal service. Somewhere (hopefully) nearby, there is a Post Office. This office sends and receives letters. Clients can either send a letter, receive a letter or both. To send a letter just put a message into an envelope, address it, and submit it to the post office.
When the post office receives your letter, it routes them to the intended receiver.
So this means a client can send or receive letters.
The key is that the letters must go through the post office, and the post office must know about the clients.
The postal service is an example of a message brokering system, built on a hub and spoke model.
In the case of MQTT, there is a broker, and there are clients. The broker is the “Post Office”, or in computer terms, the “server.”
Clients can publish (Pub) messages, or send letters, to the post office. Other clients can subscribe (Sub) to topics, or receive letters, from the post office. Moreover, clients can both publish and subscribe.
That is how MQTT works. There is a broker who communicates with clients. There are topics which can have subtopics. When devices connect, they can either publish information on those topics or subscribe to receive information.
Why not just use HTTP (aka REST)?
HTTP has a bunch of junk in the headers. A message brokering implementation can be tiny. For example, an MQTT packet can be as small as 2 bytes.
HTTP requires multiple POST actions to distribute a message to more than one client. The intent of a broker system is that the broker distributes the message, and, only to the clients interested. This basic functionality means MQTT inherently has provisions for 1 to many.
In some cases, you do not have to choose between a state transfer like REST and a message broker like MQTT. AdafruitIO is an example where their API attempts to offer both.
However, on small platforms like those found on IoT devices, MQTT (or message brokers) represent a significant advantage.
Now that we have had a message brokering and MQTT introduction, we can move onto implementing in our devices. Make sure you subscribe to my RSS feed or email list to get updated when Part Two is available.
Question: What kind of devices are thinking about connecting with MQTT? You can leave a comment by clicking here.