MQTT is a machine to machine / IoT connectivity protocol transmitted over a TCP/IP connection. It was invented in 1999 by Dr Andy Stanford-Clark of IBM and Arlen Nipper of Arcom to be an extremely lightweight publish/subscribe messaging transport. As of November 2014, MQTT become an OASIS open standard.

MQTT is rapidly becoming the de facto standard for IoT applications due to its low overhead, simple implementation, and reliability. This makes it ideal for constrained devices and unreliable networks such as mobile data networks.

The publish/subscribe nature of MQTT means that devices can selectively choose what data they are interested in receiving and many devices can receive the same information unlike a peer-to-peer protocol.

All MQTT installations require a broker which handles the subscription registrations and routes published messages to the correct subscribers.

All MQTT messages consist of a topic and a payload. The topic is hierarchical string separated by forward slashes and the payload can be any data which can be represented in a binary format. It is possible to send images, files, plain text. MQTT does not specify the topics or the data so this needs to be defined by the publishing client.

Topic Example: kitchen/temperature/value

Topics and the Publish / Subscribe Pattern

The publish / subscribe (pub/sub) pattern used by MQTT is an alternative to the traditional client-server model where clients communicate directly with an endpoint. Clients in a pub/sub model are completely decoupled and do not need to know about the existence of one another. A publishing client does not care if there are any receiving clients, it simply sends the data to the broker which takes care of the forwarding of that data to any subscribing clients.

When subscribing to topics either the full topic name must be used or the topic may contain wildcards. MQTT defines two wildcard characters, ‘+’ which means any value at this location in the hierarchy and ‘#’ which means any value at this location and all subsequent locations in the hierarchy.

Wildcard Topic Example: house/+/temperature/#

The following images show the publish / subscribe pattern:

MQTT in the Real World

Whilst MQTT’s lack of definition or standaradisation of topics and payloads makes it incredibly flexible using it in a real-world application presents some issues. If a client connects to a broker and starts publishing data, any client wishing to receive that data needs to know ahead of time what topics to subscribe to and how the data in the payload will be represented.

In a typical cloud based IoT application this is overcome by predefining the topics and payload format to be used. If a device is to be connected to multiple cloud services, the device must be specifically programmed to communicate with that service. Devices then become unable to communicate with each other and rely on the cloud server to relay messages between them which in turn requires the server to translate all messages and have knowledge of which devices should receive data from any other device.

The publish / subscribe pattern used by MQTT does not provide and mechanism for discovering which clients are attached to a system, what data and services a client could provide, or any mechanism for one device to poll another to request data as all transactions are one-directional.

It is these basic limitations which has so far constrained IoT devices to either be peer-to-peer or device to cloud, with almost all current IoT cloud services offering data collection and analysis with only very limited control capabilities.