MQ Telemetry Transport, or MQTT, was a protocol designed back in 1999 by a number of folks (mostly IBM) for sending telemetry data over satellite links from oil pipelines back to control centers to keep track of things. Originally it was going to be part of the IBM MQSeries product line, but it never really caught on (“MQ” stands for Message Queuing). It wasn’t until about 2013 or so that people started using the protocol for IoT applications….and it is now the #1 protocol for IoT (CoAP is also used a lot).
MQTT is a publish-and-subscribe messaging protocol. This means that a client can “publish” data into the MQTT Broker, and it in turn will send that data back out to those clients that have “subscribed” to the topic. Since multiple topics and subtopics are supported, you can run lots and lots of different applications through the same MQTT Broker.
Fun Fact: Facebook Messenger uses MQTT to send your messages
One advantage of this for us is that I don’t have to program any real smarts into a sensor — I just have to have it publish its data to a topic that makes sense, and then I can create another client that has all the smarts in it to do the things I want my DIY Smart Home to do. This leads to John’s Rule #1 of DIY Smart Homes:
Let Sensors Sense, not Think
You learn this rule really quick when you want to add a new feature or capability into something that is also a sensor that is located in a really inconvenient place, like a roof top or attic. Put the smarts into something you can get to easily, and just let the sensor sense and report out its data.
Another advantage is that I don’t have to put all my smarts into one program…I can just write a new program that subscribes to the same topic to get the same data and do something different with it. A good example is the alerting system of my DIY Smart Home. I have one alert program running on my main desk computer, and another one on a different computer that uses a different notification method. This worked great for what it is intended to do, but I soon figured out that I needed something else to alert me when I was away from the house….so I wrote another program to push my alerts out via a IFTTT webhook to my cellphone via SMS messages. I’ll be writing about my alert system in another blog post soon.
MQTT Packets
So, what makes up an MQTT packet? The two most important parts are the Topic, and the Payload. The Topic is what clients subscribe to, and looks like this:
temp/read/Outside1This would be the Topic for a thermometer temperature reading. The ‘temp’ part is known as the Main Topic. The ‘read’ and ‘Outside1’ are Sub-Topics. When a client goes to subscribe to a particular Topic, a wildcard can be used to match Topics or Sub-Topic. For example, my client might need to see all the temperature readings, so it will subscribe to this Topic:
temp/#This will match any Topic that begins with ‘temp’. The ‘#’ wildcard says to match anything on this sub-topic and below. You can also use the ‘+’ wildcard to just match anything at that level. So for example, I could Subscribe to ‘temp/read/+’ to match any sensor reporting its temperature reading. I could subscribe to ‘temp/+/Outside1’ to match any temperature topic from sensor ‘Outside1’.
Where do you run the MQTT Broker?
The nice part about using MQTT is that the Broker can be just about anywhere you want it. I happen to use the Mosquitto MQTT Broker and I run it as a Docker Container. There are lots of folks that setup a Raspberry Pi and run it as a dedicated IOT server. Some folks just install it on an existing server and connect to it there….All you really need is an IP address that your clients can connect to, and at least port 1883 available (and port 8883 for SSL connections if you want to do that) for MQTT connections.
Security
One thing that I don’t stress about much on my home network is security (I have a number of network security systems in place that are not normally found in your normal home setup.) You can encrypt your MQTT packets by using SSL and the SSL option on your MQTT Broker. You can use user IDs and passwords if you like as well. In my DIY Smart Home, I don’t use any of those options –here’s why: If a hacker breaks into my home network, they are more than welcome to tap my MQTT packets and find out what the temperature is outside my house. 😉 Since I don’t have anything critical connected up (at least not yet), I haven’t been focused on the security side of things. That may change in the future, and if so, I’m sure I’ll come back and write more about it.
What MQTT is NOT good at
MQTT was really designed for sending small amounts of sensor data, not binary picture files — use something else for that. Technically, you can send around 1,000 bytes of data in the Payload part, but most of my payloads are well under that number (my largest MQTT payload that I have on my networks is 99 bytes.)
Hopefully that helps you to understand MQTT a bit better. Please feel free to ask questions in the Comment section below!