What is MQTT?
MQTT is a lightweight publish/subscribe messaging protocol designed for M2M (machine to machine) telemetry in low bandwidth environments.
It was designed by Andy Stanford-Clark (IBM) and Arlen Nipper in 1999 for connecting Oil Pipeline telemetry systems over satellite.
Although it started as a proprietary protocol it was released Royalty free in 2010 and became an OASIS standard in 2014.
MQTT stands for MQ Telemetry Transport but previously was known as Message Queuing Telemetry Transport.
MQTT is fast becoming one of the main protocols for IOT (internet of things) deployments.
There are two versions of MQTT.
The original MQTT which was designed in 1999 and has been in use for many years and designed for TCP/IP networks.
Currently there is little support for version 5 but that should change in 2018.If you are wondering what happened to 4 then see here.
An overview of the key ideas in version 5 is here.
MQTT-SN which was specified in around 2013, and designed to work over UDP, ZigBee and other transports.
MQTT-SN doesn’t currently appear to be very popular. and the specification hasn’t changed for several years, but I expect that to change as IOT deployments start. See MQTT-SN working Notes.
MQTT Basics -How MQTT Works
MQTT uses a publish /subscribe model which requires the use of a central Broker as shown in the diagram below:
Clients do not have addresses like in email systems, and messages are not sent to clients.
Instead messages are published to broker on a topic.
The job of an MQTT broker is to filter messages based on topic and then distribute them to subscribers..
A client can receive these messages by subscribing to that topic on the same broker
In this model there is no direct connection between a publisher and subscriber.
However unlike the broadcast TV/radio model in MQTT all clients can publish (broadcast) and subscribe (receive).
Topics – MQTT Addressing
These are like channels in the TV radio model. Topics are what connects the publisher and subscriber.
In MQTT there is no formal structure and a publisher is free to choose it’s own topic names and structure.
There are however naming rules:
Taken from the Specification MQTT V3.1
Topic names look very similar to URLs.
As long as a topic name follows the naming standards it is accepted by the Broker.
A Topic name is a UTF-8 string, and must comprise of at least one character.
Topics can be created in a hierarchical manner (levels) using a forward slash as a delimiter.
Simple topic examples are:
topic = bulb1, topic = bulb2, topic = bulb3 or
topic =bulbs/ bulb1, topic =bulbs/ bulb2, topic =bulbs/ bulb3
What Happens to Published Messages?
When a client publishes a message on a topic then the broker will distribute that message to any connected clients that have subscribed to that topic.
Once the message has been sent to those clients it is removed from the broker (see note).
If no clients have subscribed to the topic or they aren’t currently connected then the message is removed from the broker. (see note)
In general the broker doesn’t store messages.
Note: Retained messages, persistent connections and QOS levels can result in messages being stored on the broker/server.
MQTT Broker Connections
MQTT uses TCP/IP to connect to the broker. TCP is a connection orientated protocol with error correction and guarantees that packets are received in order.
However that doesn’t mean that messages can’t be lost.
MQTT QOS Levels
Networks are unreliable and MQTT lets you select from 3 QOS levels depending on your requirements. If your application can tolerate lost or missing messages then you can choose the lowest level QOS 0.
Otherwise you will need to use QOS level 1 (at least once) or QOS level 2 (At most once). See
The higher the QOS level the more message overhead is involved.
Because MQTT clients don’t have addresses like email addresses, phone numbers etc. you don’t need to assign addresses to clients like you do with most messaging systems.
There is client software available in almost all programming languages and for the main operating systems Linux, Windows, Mac from the Eclipse Paho project.
On this site I will be using the Python client.
MQTT Brokers or Servers
Note: The original term was broker but it has now been standardized as Server. You will see Both terms used.
There are many MQTT brokers available that you can use for testing and for real applications.
If you don’t want to install and manage your own broker you can use a cloud based broker from Cloud service providers like IBM, Microsoft (Azure) etc
Eclipse has a free public MQTT broker and COAP server that you can also use for testing. The address is iot.eclipse.org and the port is 1883 or 8883(SSL).
See this article for a list of cloud hosting options
MQTT supports various authentications and data security mechanisms.
It is important to note that these security mechanisms are configured on the MQTT broker, and it is up to the client to comply with the mechanisms in place.
MQTT Overview Video
If you are familiar with the web and email then you will probably find, as I did, that MQTT is very different. These are some of the questions I had, and saw on other sites and forums that may clear things up a little.
Q- What happens to messages that get published to topics that no one subscribes to?
A- They are discarded by the broker.
Q-How can I find out what topics have been published?
A- You can’t do this easily as the broker doesn’t seem to keep a list of published topics as they aren’t permanent.
Q- Can I subscribe to a topic that no one is publishing to?
Q- Are messages stored on the broker?
A- Yes but only temporarily. Once they have been sent to all subscribers they are then discarded. But see next question.
Q- What are retained messages?
A- When you publish a message you can have the broker store the last published message. This message will be the first message that new subscribers see when they subscribe to that topic. MQTT only retains 1 message.
Real World MQTT Example Deployments
It’s often useful and interesting to see how a particular technology is actually being used. Here are some examples I’ve come across:
- Freight Farms-MQTT
- IP pinger swarm using MQTT
- How do you use MQTT- Mosquitto.org
- Owntracks -Location tracking
Fortunately when I started to learn about MQTT I came across the very good MQTT essentials series that explained the main features of MQTT.
However there is one thing reading about something and another seeing it really work so I started using Python to create simple scripts to demonstrate some of the aspects of MQTT that I found confusing.
Before you start I would recommend that you read through the MQTT essentials articles as they cover the theory in more detail.
To create these example I used my own Mosquitto broker installed on my local network.
However most of the examples would work using the public Mosquitto broker at iot.eclipse.org.
I use the Paho Python MQTT client for the client scripts.
However A knowledge of python isn’t really required to understand the examples.
MQTT Protocol with Examples:
- Clean Sessions and QOS (quality of service)
- MQTT Retained messages Explained
- Last will and testament-Example
- Username and Password authentication
- MQTT Keep Alive Interval Explained
Using the Python MQTT client
- Getting started with the Paho MQTT Python Client for Beginners
- Client Objects-Working with The Python MQTT Client
- Client Connections-Working with The Python MQTT Client
- Subscribing to Topics Messages Using The Paho Python Client
- Publishing Messages Using The Paho Python Client
- Really good introductory series- Recommended reading MQTT essentials.
- Very good MQTT pdf with detailed examples.
- Installing and setting up The Mosquitto broker.