IoT Hub: A Quick Introduction to the MQTT Protocol

Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol that allows two remote devices to communicate via messages asynchronously with low bandwidth. The protocol, specifically dedicated to the world of M2M (machine to machine) and IoT (Internet of Things), has now become a standard.

Scaleway Elements IoT Hub implements the most used protocol in the IoT world: MQTT 3.1.1.

Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol based on TCP/IP developed in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper of EuroTech.

The protocol, specifically dedicated to the world of M2M (machine to machine) and IoT (Internet of Things), has now become a standard.

The MQTT protocol, allows two remote devices to communicate via messages asynchronously with low bandwidth. It is increasingly used to communicate between connected objects. These connected objects collect different information from integrated sensors and this data is sent through MQTT.

The Architecture of MQTT

At the heart of a standard MQTT based IoT structure, there is a remote server, the Broker. All objects and services connect to it as clients. The broker forwards messages between clients. Clients can send messages as publishers and receive messages as subscribers. Published messages contain a topic which describes the message's contents (for example: weather in Paris, France). Subscribers each receive a copy of the message if they have subscribed to the topic of the published message.

In MQTT, clients identify themselves using a unique ClientID. If left empty the Broker will generate a random one.

When a client connects to a Broker, it can choose to start a new session or resume the existing one. A session contains clients' subscriptions and pending messages.

Topics are used to forward published messages to subscribers. A topic is a character string indicating the message's contents (example: home/2ndfloor/kitchen/temperature). With MQTT, by default, all subscribers receive a copy of the messages published with matching topics.

Please see our blog post about topics to learn more.

Upon publishing a message, a client can request that the Broker keep it in memory. This is called a retained message. Any future subscription matching the retained message topic will immediately receive a copy of it. A new retained message for the same topic will discard the previous one.

Quality of Service Levels

MQTT’s Quality of Service levels determine how the relationship between the client and the Broker should unfold when they are communicating. It indicates the level of commitment to the delivery of a message between the communicating parties.

Please note QoS levels apply between a client and the Broker, not between a publisher and a subscriber.

• QoS 0 - "At most once": Also known as "fire and forget". On this level, a message is sent (PUBLISH) and may be received at most once. The sender does not store the message for future transmissions, meaning that if a message is sent and the receiver is not available at the time of the expedition, the payload may not reach them at all. Furthermore, no confirmation of receipt is provided.

• QoS 1 - "At least once": This level guarantees that a message sent (PUBLISH), will be received at least once. In this case, if the sender does not receive an acknowledgement of receipt (PUBACK) within the expected timeframe, the message might be sent multiple times until it is acknowledged. The acknowledgement is sent by the receiver, as a response to the original message, only once. This means that if the original sender of a message is unavailable at the time the response is conveyed, it will not get a confirmation of receipt and will continue to send the same message until it does. The receiving end will not, however, understand that this a duplicitous message and will interpret the information as new.

• QoS 2 - "Exactly once": This level of service guarantees that the message sent is being received exactly once. It consists of:

1. The message being sent (PUBLISH).

2. Its receipt being acknowledged by the receiver (PUBACK).

3. The sender confirming they have, in their turn, received the acknowledgement (PUBREL).

4. A final recognition of the PUBREL by the receiver (PUBCOMP).

This level of quality is the safest, as it ensures that the message is not interpreted as two different information. However, the QoS 2 flow requires that a high number of data be vehiculated back and forth, which is not ideal when it comes to low-memory clients.

Last Will

When connecting, a client can provide a Last Will message to the Broker. This is a regular message which will be published by the Broker if the client disconnects unexpectedly. This mechanism allows clients to make sure other clients will be notified when they disconnect, whether properly or unexpectedly.

MQTT in Practice

MQTT has many implementations, which work with different programming languages and environments. Your choice will depend on the types of devices you are working with and which MQTT tools you might already have at your disposal.

Software called MQTT clients are used for collecting or processing data generated by connected objects. They can be used to configure a device as a Client and to set-up what actions they should take based on messages received in the topics they are subscribed to.

Some devices like Arduino, Rapsberry Pi and several industrial controllers come with embedded microcomputing platforms that allow configuration throught built-in MQTT clients. Other devices might require the use of a third-party software. A popular open-source alternative is Eclipse Paho.

You can also find web-based clients that connect to the Broker via web sockets, like the HiveMQ client. If you need to run tests without using hardware, you will find tools like MQTT Lens and MQTT-Spy useful, as they simulate MQTT clients.

For Broker implementation, there are many open source projects available. The most used is Mosquitto, which provides MQTT protocol versions 5.0, 3.1.1 and 3.1. The project provides a C (programming language) library for implementing MQTT clients. It is also responsible for the mosquitto_pub and mosquitto_sub command line MQTT clients.

At Scaleway, we take the MQTT system one step further with IoT Hub by allowing connected devices to interact with cloud services.

Under the hood, Scaleway IoT Hub acts as an MQTT broker. On top of that, Hub Routes allow devices to benefit from Scaleway’s ecosystem. For example, Object Storage Routes allow you to store your metrics in a S3 compatible Object Storage bucket. Database Routes are available for storing specific messages in a database and for triggering the execution of any other SQL query on the given database. And REST Routes allow you to forward any messages published on a selected topic to a REST service.

If you want to find out more about MQTT, take a look at the protocol's complete specifications here. To dive deeper into the world of IoT, check out our IoT Hub documentation pages here.