MQTT (Part 1): Introduction

This tutorial series is all about MQTT – the messaging protocol that is excellent for exchanging data between devices. Imagine you want to monitor the temperature in your greenhouse. To do this, you install temperature sensors that send their readings via MQTT to a central broker. The broker then distributes the data to all “interested” recipients, such as a microcontroller that controls irrigation.

In this introduction, we will first clarify what MQTT actually is and how it fundamentally works.

What is MQTT?

MQTT stands for “Message Queuing Telemetry Transport.” It is a lightweight, open messaging protocol ideal for M2M (Machine-to-Machine) communication. MQTT enables devices to exchange data in a simple and efficient manner.

The protocol was developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Cirrus Link). Today, MQTT has become a standard in the IoT field.

Key Advantages of MQTT

Lightweight: Requires minimal network bandwidth and low hardware resources.
Publish/Subscribe Model: Decouples message senders (publishers) and receivers (subscribers). Devices do not communicate directly with each other but through a broker.
Scalability: Excellent for large networks with many devices.
Reliability: Offers three Quality of Service (QoS) levels to meet different requirements.
Flexibility: Easily integrates into existing systems and supports various programming languages and platforms.

How Does MQTT Work?

To understand how MQTT works, a diagram is often helpful:

This diagram illustrates a possible smart home scenario. Let’s go through the individual elements:

___STEADY_PAYWALL___

Broker: At the center of the image, you see a green circle labeled “Broker.” The broker is the heart of the MQTT system and acts as a central intermediary between all devices.
Publisher (Sender): On the left side, there are three blue circles with thermometer symbols. These represent the publishers – in this case, temperature sensors at different locations:
- A sensor in the house (home/temperature) measures 19°C
- A sensor in the garage (garage/temperature) measures 15°C
- A sensor in the garden (garden/temperature) measures -4°C
Subscriber (Receiver): On the right side, two red circles with chip symbols represent the subscribers – devices that receive and process temperature data:
- A device interested in the indoor temperature, which, for example, regulates the heating.
- A device monitoring the garden temperature, which, for example, lowers the blinds to better insulate the house.
Publishing Process: The black arrows from the publishers to the broker indicate the publishing process. Each sensor sends its measured values with a specific topic (e.g., “home/temperature”) to the broker.
Subscribing Process: The gray arrows from the broker to the subscribers indicate the subscribing process. The subscribers inform the broker which topics they are interested in (e.g., “home/temperature” or “garden/temperature”).
Message Distribution: The black arrows from the broker to the subscribers show how the broker forwards the received messages to interested subscribers.

The special feature of MQTT is the decoupling of senders and receivers. The temperature sensors (publishers) do not know who is receiving their data. The receiving devices (subscribers) do not know where the data comes from. Everything runs through the central broker.

This system enables flexible and efficient communication in IoT networks. New devices can be easily added by registering the relevant topics with the broker, without requiring adjustments to other devices.

Topics and Topic Hierarchy

MQTT messages are always assigned to a specific topic, structured similarly to a file path:

home/temperature
garage/temperature
garden/temperature

Wildcards for Topic Subscriptions

Plus (+): Replaces a single hierarchy level (e.g., home/+/temperature).
Hash (#): Replaces multiple hierarchy levels (e.g., home/#).

Practical Example

Consider a smart home with multiple sensors:

home/livingroom/temperature
home/kitchen/temperature
garden/sprinkler/status

A subscriber interested in all temperature sensors could subscribe to home/+/temperature, receiving data from multiple rooms without explicitly listing each sensor.

Quality of Service (QoS) Levels

MQTT offers three levels of message delivery guarantees:

QoS 0 (At most once)

The sender transmits the message once without storing it.
The broker forwards the message without confirmation.
Use case: Non-critical sensor data (e.g., periodic temperature updates).

QoS 1 (At least once)

The sender stores the message until it receives confirmation.
If no confirmation is received, the message is resent.
Use case: Important messages where duplicates are acceptable.

QoS 2 (Exactly once)

Uses a four-step handshake to ensure exactly one delivery.
The most reliable but also the slowest level.
Use case: Critical data like financial transactions or industrial controls.

Choosing the Right QoS Level

Each QoS level serves different needs:

QoS 0 is best for low-power devices that send frequent, non-critical updates.
QoS 1 ensures messages are received but may introduce duplicates.
QoS 2 guarantees reliability, making it ideal for high-stakes applications.

Retained Messages and Last Will and Testament (LWT)

Retained Messages

A retained message acts like a digital sticky note. Any new subscriber immediately receives the last retained message instead of waiting for a new update.

Example: A smart light switch sends a retained message (ON or OFF). When a new subscriber connects, it instantly knows the current state.

Last Will and Testament (LWT)

Imagine you go to a party and tell the host: “If I don’t come back within the next hour, tell everyone I had to leave suddenly.” That’s basically how the Last Will and Testament (LWT) works in MQTT. LWT allows a device to notify others if it unexpectedly disconnects.

Example: A greenhouse sensor sets an LWT message: Greenhouse sensor offline. If it loses connection, the broker automatically sends this message to all relevant subscribers.

Conclusion

That concludes Part 1 of this series. The next part will focus on setting up an MQTT broker on a Raspberry Pi and exploring practical implementations of publishing and subscribing to data.