MQTT and the Internet of Things
March 24, 2016
Our technology continues to increase in capability while shrinking in size. We can do more with less than ever before and it’s opening the way for industrial design and manufacturing to build intelligence into their creations. This intelligence comes in the way of embedded sensors, processors, and network connectivity that make it possible to monitor and automate many of the appliances you have at home. This concept of a network of physical objects is referred to as the Internet of Things (IoT).
Since a lot of IoT devices are low-power with limited network connectivity, getting a reliable transfer of data from the device to a server can be problematic. Enter MQTT, a light-weight pub/sub messaging transport protocol.
A Brief History of MQTT
MQTT was invented in 1999 by Andy Stanford-Clark from IBM and Arlen Nipper from Cirrus Link (now Arcom). They needed a protocol that would consume a minimal amount battery power and bandwidth to monitor oil pipelines over satellite connection. They specified the following goals for the protocol:
- Be simple to implement
- Provide Quality of Service (QoS) data delivery
- Be lightweight and bandwidth efficient
- Be data agnostic
- Have continuous session awareness
These goals are still at the heart of the MQTT protocol development project today, however focus has broadened from proprietary embedded system implementation to more open IoT use cases.
So, How Does this All Work?
MQTT is based on the principles of publishing messages and subscribing to topics (pub/sub) and is built on top of the TCP/IP stack. Multiple clients connect to a broker and subscribe to the topics they want updates on. Clients also connect to the broker to publish messages to topics. The publisher could be a sensor on a remote device or something embedded on the box running the broker itself.
Messages in MQTT are published to topics, which are just strings separated by a forward slash (/). This pattern allows for a hierarchical separation of data similar to file system paths — e.g. you could publish weather data from multiple sensors around town to a topic format like this:
Clients can receive messages by subscribing directly to a topic, or by using the two available wildcard characters (+ or #). The + character acts as a wildcard for a single level of hierarchy and could be used to get all information for a particular level — e.g. to get the temperature readings from all sensors in the above example, subscribe to this topic:
The other wildcard character is # and this acts as a wildcard for all remaining levels of hierarchy — e.g. to get all data from a particular weather sensor (temperature, humidity, barometric pressure, etc…), subscribe to the following:
sensor/# to get all data from all sensors.
Quality of Service
MQTT defines three levels of QoS (QoS 0, 1, and 2) and that defines how hard a broker/client will work to ensure message delivery. Messages can be sent at any level and clients can subscribe at any level, but the client determines the maximum QoS it will receive. So, if a message is published at QoS 2 and a subscriber listens with QoS 0, the message will be delivered at QoS 0. If another client subscribes to the same topic at QoS 2, that client will receive the message at QoS 2. On the other hand, if a client publishes a message at QoS 0 and a subscriber listens at QoS 2, it will be delivered at QoS 0.
The levels of QoS are as follows:
- 0: The message will be delivered once with no confirmation
- 1: The message will be delivered at least once with confirmation required
- 2: The message will be delivered exactly once with a four-step handshake
MQTT Clients and Brokers
There are a number of MQTT client and broker libraries available in just about any language you could want. One of the more popular open source projects is Mosquitto. I’m currently running a version of Mosquitto on my raspberry pi box doing various MQTT experiments with an iOS client.