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.
That was an amazing article.
also i want to design mqtt server on raspberry pi , Giving state ON or OFF requets from Postman service that goes to Raspberry pi (server), from where arduino subsrcibes to the message and turn on or off the device
can please help me out or provide me with a direc tion.
i hope to get a reply soon
Pingback: Tut08: Mosquitto als MQTT-Datenbroker – IoT an der WVSS
I just stumbled across this site today. I have to say it has opened my eyes to a completely different scheme for a project I am working on.
Picture if you will.. Pi web server an a network with 9 (current count) arduino connected via WIFI that drive LED strips. I have been looking for a simple way to get them to communicate. MQTT might just be the most elegant solution. The plan is that the display is selected through the website(saves me writing an app for my phone 🙂 ) and then the PI tells the arduinos what to do.
Sounds like a good use for MQTT, depending on how much latency you can tolerate. If you’re trying to do animations, you’ll probably want to use something on top of TCP to reduce latency. (but you could still use MQTT as a management channel.) If it is just turning lights on and off, that’s what I do with my Pi and ESP8266 now.
I want to monitor my workshop door with esp8266-12 and also my front door with esp8266-12 I would like to run both on battery power so they sleep until the doors are opened then send and go back to sleep to send a message with time and have a message arive on my phone that is it with no web or cloud service for security reasons but not sure where to start!!
Any help would be good thanks Bob UK
You want to use one of the ‘sleep’ modes on the ESP processor and interrupts to wake the device. In deep sleep mode the device pulls about 20 uA so even a coin cell (CR2032) should power it for about a year (depending on how many times the door is opened). I’d suggest also having the device transmit the current battery level along with each alert (use the ADC channel & a voltage divider). That way you know if the battery is dying without having to physically check the device itself.
Another option is to have a ‘heartbeat’ message every ‘n’ minutes / hours / days. For example, at midnight every day send a MQTT message with the current battery voltage. Even in deep sleep, the RTC is still running.
Here’s an article on sleeping the ESP8266: https://www.losant.com/blog/making-the-esp8266-low-powered-with-deep-sleep
Here’s an article on coin cell power: https://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-
You can host your own MQTT server (search for MQTT mosquitto or see mosquitto.org) on pretty much any platform including a raspberry pi. That way you are running everything internal (no external web service, etc.).
You’ll have to create a tool to monitor the MQTT broker and send an SMS or other notification to your phone.
I would like to use MQTT so that when I activate something from a GUI on an android tablet, it will trigger the raspberry pi to publish a message of which the we most d1 will be subscribed to and then either transmit an IR frequency to turn off my remote control bedroom light or make live a GPIO pin on a solid state relay or even introduce it into a stepper motor to control the light dimmer in my living room.
I just need to familiarise myself with all this as well as stuff like if this then that.
we can use sockets.io also to send device to device communication.can anyone say what are the disadvantages while using socket.io and what are the disadvantages while using MQTT? Thanks in advance .I am waiting for uour reply.
Great and simple introduction. Thanks!!
Excellent article. Thanks!
I’m going to try the mosquitto mqtt broker on a Pi Zero W and want to know how I can get the client side on an ESP8266 (Wemos D1 mini) using Arduino IDE.
You provided a very informative introduction. I look forward to reading more about mqtt programming
I would recommend https://github.com/ItKindaWorks/ESPHelper to setup the ESP on your network and your MQTT server
I like ‘ESPEASY’. It is feature rich and all seems to work but the docs are a bit sparce. Hope this is helpful.
Nice introduction. Thanks!!
love the article. Would love to see a time stamp when you publish things.. info on the internet is very difficult to discern how “recent” it is..
Otherwise, appreciate the conciseness. Will be looking at your follow on articles.
It’s at the bottom of the article, right above where you add comments…
dear sir : MQTT is a device or a link provider to raspberry pi and if this is a hardware thin from where bought this hardware
Pingback: replica bvlgari black ring
I am working on field force automation for predictive maintenance, devices are located at different places. i am working on architecture. can you advice me.
Sorry, I don’t know what “field force automation for predictive maintenance is.”
Thanks for your tutorial,i hope i will have much understanding about IOT
I have created ILI9341 and NodeMCU based message display using web server. (https://github.com/jatinkgandhi/NodeMCU-Projects)
Planning to make it as unified display for multiple sensors.
By subscribing to various events/sensor values, it will collect data from distributed sensors and consolidate them in one GUI.
Thanks for the simple and clear explanation. Now off to part 2.
What a tease, looking forward to the next chapter in this. I had considered sending JSON to my arduinos but the overhead is just too high. MQTT looks like the ticket. I wonder if there is a way to offload the handling of the protocol directly onto the esp8266. Hopefully that is where you’re going with this.
Stay tuned. The next tutorial is going to cover simple MQTT messages. But I have something coming on more complex messages (and it isn’t JSON.)
The funny thing is… if I understand it the right way. RSS feed is some kind of message broking system. 😉