Introduction to MQTT

Intro to MQTT

In this post I will cover some fundamental structural info about the MQTT protocol. It’s the sort of stuff that many will be inclined to skip, but doing so will leave aspects of the protocol opaque and make it more difficult to use.

What is MQTT?

MQTT is a data agnostic, transport protocol. As a transport protocol it concerns itself with moving messages between devices. This is analogous to a channel in the Shannon model we explored at beginning of term.

There are several competing threads to what MQTT stands for — if anything at all. MQTT was created by IBM as a proprietary protocol built around MQ devices in the late 90s. There is disagreement over whether MQ stands for message queuing, or its just ‘MQ’ the device series from IBM We don’t need to get too hung up on what it stands for — we just need to be able to use it and understand that it differs from other transport protocols like HTTP, FTP or simple TCP connections.

MQTT is Server/Client

MQTT is an internet of things protocol that is designed to be lightweight. It operates on a server/client model. This is essentially the same as how a web page works but in much lighter format. Unlike a webpage, screen display is not prioritized.

In the web page context a (usually) remote server holds page information and a client (a web browser) connects to the server and request information (this is how our p5js scripts operate). A bunch of behind the scenes dialog takes place between the server and client software and the the web content that you requested appears on your screen.

MQTT Brokers

With MQTT the server is called a broker. We will be using shiftr.io. Like so many web tools shiftr is just one of many ways to make MQTT happen quickly and easily. shiftr details will be described in an additional post.

Brokers can be (run locally for installations)[https://mosquitto.org/] and even setup on a raspberry pi. Tom Igoe’s Making Things Talk 3rd edition outlines the process in clear and concise way. There is a copy in the makerspace.

MQTT Clients

MQTT clients can be any device capable of sending an MQTT message. This means we are not restricted to screen enabled web browsers running on computers, laptops or phones. An Arduino Uno with a wifi shield or any of the countless microcontrollers with built in WiFI can all act as MQTT clients sending and receiving MQTT messages. For this reason MQTT has been adopted as a primary tool for building IOT experiences.

MQTT Message Structure

MQTT messages have two parts: a message topic and a message payload. At a high level we can superficially think of them as looking something like this:

message = topic, payload

Topics

When you start out it may be helpful to think of topics as tags or labels. They are used to create a category of messages. Topics should be unique in a single broker to ensure you don’t get data collisions.

Topics are simple Strings. They can be nested with ‘/’ (slashes – like URLs) and these can be used for routing. In top level topics the ‘/’can be omitted.

So,

/myTopic

and

myTopic

Are equivalent when used at top level. One can find epically tense debate about this online — once again we will ignore the ‘/’-anger and realize both work. You will see some examples with top-level topics including the slash, and some without.

Note that nested topics can also be used:

pets/cats

or

pets/hedgehog

and even

/pets/hedgehog

Are all valid. Advanced routing can take advantage of this pattern.

Payloads

MQTT payloads are data agnostic. This means the protocol does not specify anything about how message content is formatted. You will see lots of strategies for packing and unpacking payloads. We will use plain strings and JSON before the course ends.

We will begin by using our simple serial protocol of [*,,#].

MQTT is a PUB/SUB protocol

MQTT uses a publish/subscribe (pub/sub) model. There are many flavours of pub/sub and you will encounter different approaches with associated libraries and accounts when you start to dig into the field.

In general, a device (client) sends a message to a broker by publishing a topic. Other devices can receive that message by subscribing to the message topic on the broker

A single device can publish and subscribe to multiple topics. Most initial examples will use single topic messaging, but more complex topologies can be imagined and implemented easily.

Summary

MQTT is a lightweight transport protocol optimized for the internet of things. It uses web architecture and a pub/sub model to enable small devices to publish and subscribe to unique messages.

Going Further

There are many layers of the protocol not discussed here. Quality of Service and other nuances can be explored at the links below.

mqtt.org defines the specification

mosquitto.org provide an alternative to shiftr if you are running in gallery or need a local broker.

Igoe’s Making Things Talk 3rd Ed has a great walk through of setting up local MQTT brokers (p393)

hivemq.com/ is resource I often turn to for a deeper dive into the protocol. If you want to know about rPis and MQTT brokers — this thread looks promising