What is MQTT?
MQTT stands for MQ Telemetry Transport. Well, that’s not useful. Simply put it is a lightweight messaging protocol where clients can publish & subscribe to topics in order to share data. It works really well in networks with very low bandwidth, high latency or poor reliability. But because of the ability to store messages, it can still maintain a high degree of reliability. This makes it a perfect protocol for so-called “Internet of Things” devices which may need to run off batteries or cellular connections and cannot always be powered on.
The nerdy stuff
- Who invented MQTT?
- MQTT was invented by Dr. Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom in 1999.
- What ports does MQTT use?
- Two ports are reserved with IANA. Port 1883 is reserved for use with MQTT. Port 8883 is also registered, for use over SSL.
- Does MQTT support passwords?
- You can send a username and password since V3.1 of the protocol.
Okay, that’s great but what do I need to use it?
There are two critical software parts to an MQTT setup. The Broker and the Client.
The Broker
What is a broker? Well simply put the broker or server is the centralized component where the actual messages are exchanged. There are several options for a broker available to you.
- You can host one yourself. There are both free and paid options a couple of common ones are:
- Mosquitto – Free and very commonly used
- HiveMQ – Free and paid options. The paid version has high-availability features
- You can use a cloud-hosted version. While I’ve never used any of them here are a few options:
Ultimately unless you intend to have devices at diverse locations that need to communicate through the open internet we generally recommend running a local broker for security and the ability to function if there is an internet interruption
In later articles we will discuss setting up your own broker and performing actual communication.
The clients
Clients can be hosted on anything you might imagine. In a modern connected home, MQTT clients can be found on everyday things like light bulbs, switches, electrical outlets, and thermostats. But also on a vast variety of sensors like door/window contacts, motion, temperature, and moisture sensors. There are also clients you can run on your computer, tablet or phone. As well as being available to automation software like Home Assistant, Node-Red and many others.
Combined with known topics and payloads these devices and software can talk to each other an offer control or critical information between components from many manufacturers.
In a later article we will discuss a powerful desktop client you can use to monitor the traffic passing through your broker. This can be useful to troubleshoot any problems you may be having.
Topics?
Clients can Publish, Subscribe or both to a topic. (publish/subscribe is often call pub-sub for short). Devices that cannot be controlled generally only publish and devices that only monitor generally just subscribe.
Topic structure
Topics are fundamental to the function of MQTT. They have a defined syntax which allows for multiple levels. By using a delimiter of the forward-slash ( / ) devices of similar types can be grouped together and still have unique device control.
So if for example, you have 3 temperature and one moisture sensor in your home. One in the kitchen, basement & bathroom. To keep their data separate, you could define your topic structure like:
- sensor/temperature/kitchen
- sensor/temperature/basement
- sensor/moisture/basement
- sensor/temperature/bathroom
Devices generally only publish to a single topic, so a monitoring client has to subscribe to all those topics to get all the temperatures. That’s fine for a few devices but tedious for many. Thankfully there’s a built-in solution for that:
Wildcards
There are two wildcards + and #. They perform slightly different functions
+ Matches any topics a specific level # Matches any topics a that level and above
So if I wanted every sensor regardless of the type I could subscribe to sensor/# But if I wanted every temperature sensor I would use sensor/temperature/# Now what if I wanted every sensor in the basement then I could use sensor/+/basement This allows for great flexibility in retrieving data.
One thing to be aware of. Topics can start with a / so /sensor/temperature/kitchen and sensor/temperature/kitchen are not in fact the same topic
QoS – Quality of Service
By default when a topic is published, the message (Commonly known as “Payload”) is discarded once sent. This is QoS Level 0
QoS Level 1 tries to ensure that at least one client receives the message. It does this by requiring the client to send back a message received packet.
QoS Level 2 is rarely used and often not available as it requires the sending of 4 messages and can take up considerable overhead on a low powered device.
Regardless of QoS Level if no clients are subscribing to a topic then any message sent to it are immediately discarded
Retained Topics
But what if I want a message to stick around until changed. Or what if a client was offline when a message was sent and it needs to know the status on startup. This is where the retained flag comes in.
When a broker receives a message sent to a topic with it enabled it holds onto the message. Then when a client subscribes to the topic it already has data to forward on.
How is this useful? Let’s take one of our previously mentioned temperature sensors. If a device is battery powered it will often only wake up and send data when there is a significant change in time or the temperature. If the last data sent isn’t retained and we have an automation system that’s meant to act based on a specific threshold. What might its behaviour be if there is no data to act on?
Conclusion
While this is only a brief overview of MQTT and its features. Hopefully, you can begin to see some of the endless possibilities this fault-tolerant, lightweight protocol can do for you.
Stay tuned for more where we go through setting up our own broker. A walkthrough of our favourite client for testing and monitoring MQTT is available here MQTT.fx
