MQTT: Introduction to MQTT — The IoT Messaging Protocol

When IoT devices need to communicate reliably over constrained networks — slow connections, unreliable links, battery-powered sensors — MQTT is the protocol of choice. Designed for exactly these constraints, MQTT powers billions of IoT deployments from home automation systems to industrial monitoring platforms.

What Is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol designed for:

• Low-bandwidth networks — minimal protocol overhead
• High-latency networks — asynchronous design that tolerates delays
• Unreliable networks — quality-of-service levels that ensure delivery

MQTT operates on top of TCP/IP and uses a broker to route messages between connected clients.

[Device / Sensor]                    [Device / Application]
  MQTT Client                          MQTT Client
  Publisher                            Subscriber
      |                                      ^
      |   PUBLISH "home/temp" = 22.5°C       |
      v                                      |
  +--------------------------------------------+
  |             MQTT Broker                    |
  |    (routes messages by topic)              |
  +--------------------------------------------+
      |
      | SUBSCRIBE "home/temp"
      |
  [Dashboard / App]
  MQTT Client
  Subscriber

Core Concepts

Broker

The MQTT broker is the central server that routes all messages. Clients do not communicate directly with each other — all communication flows through the broker.

Key broker responsibilities:

• Accept connections from clients
• Receive published messages
• Route messages to all clients subscribed to matching topics
• Manage client sessions and subscriptions

A widely used open-source MQTT broker is Mosquitto — a lightweight, reliable broker written in C, suitable for everything from Raspberry Pi deployments to production servers.

Client

An MQTT client is any device or application that connects to the broker. Clients can be:

• Publishers — sensors, devices, and services that send data
• Subscribers — applications, dashboards, and devices that receive data
• Both — most IoT devices publish sensor data and subscribe to control commands

Examples of MQTT clients:

• A temperature sensor (publishes readings)
• A Flutter mobile app (subscribes to device states, publishes control commands)
• A cloud backend (subscribes to all device telemetry)
• An actuator (subscribes to control topics)

Topic

A topic is a string that defines the message channel — it tells the broker which messages a subscriber is interested in and where a publisher should send its data.

Topics use a hierarchical structure with / as the separator:

home/livingroom/temperature
home/bedroom/humidity
factory/line1/machine3/status
building/floor2/hvac/setpoint

Topics enable fine-grained routing — a subscriber can listen to a specific sensor, a whole room, an entire floor, or everything at once.

Wildcards:

• + — single-level wildcard: home/+/temperature matches home/livingroom/temperature and home/bedroom/temperature
• # — multi-level wildcard: home/# matches everything under home/

Publish

A client publishes a message by sending a payload to a specific topic. The broker then routes that message to all subscribers of that topic.

# Python example using paho-mqtt
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.connect("broker.example.com", 1883)
client.publish("home/livingroom/temperature", "22.5")

Subscribe

A client subscribes to a topic to receive messages published to it. Once subscribed, the client receives every message published to matching topics.

# Python example
def on_message(client, userdata, message):
    print(f"Topic: {message.topic}")
    print(f"Payload: {message.payload.decode()}")

client = mqtt.Client()
client.on_message = on_message
client.connect("broker.example.com", 1883)
client.subscribe("home/livingroom/temperature")
client.loop_forever()

Message Flow

The complete MQTT message flow:

Step 1: Subscribers connect and register interest
[Subscriber 1] --SUBSCRIBE "home/temp"--> [Broker]
[Subscriber 2] --SUBSCRIBE "home/temp"--> [Broker]

Step 2: Publisher sends a message
[Temperature Sensor] --PUBLISH "home/temp" = 22.5°C --> [Broker]

Step 3: Broker routes to all subscribers
[Broker] --DELIVER "home/temp" = 22.5°C --> [Subscriber 1]
[Broker] --DELIVER "home/temp" = 22.5°C --> [Subscriber 2]

This decoupled model means:

• Publishers do not need to know who is subscribed
• Subscribers do not need to know who is publishing
• Adding new subscribers or publishers requires no changes to existing clients

Quality of Service (QoS) Levels

MQTT defines three levels of message delivery guarantee:

Choose QoS based on the cost of lost vs. duplicate messages:

• Temperature readings: QoS 0 or 1 (a missed reading is acceptable)
• "Unlock door" command: QoS 2 (must arrive exactly once)

Mosquitto — A Production MQTT Broker

Mosquitto is an open-source MQTT broker maintained by the Eclipse Foundation. It is:

• Written in C — lightweight and fast
• Available on Linux, Windows, macOS, Raspberry Pi, and Docker
• Widely used in both development and production IoT deployments
• Supports MQTT 3.1, 3.1.1, and 5.0

Basic Mosquitto Setup

# Install Mosquitto on Ubuntu/Debian
sudo apt-get install mosquitto mosquitto-clients

# Start the broker
sudo systemctl start mosquitto

# Test with command-line tools
# Subscribe in one terminal
mosquitto_sub -h localhost -t "home/temp"

# Publish in another terminal
mosquitto_pub -h localhost -t "home/temp" -m "22.5"

Mosquitto Configuration

# /etc/mosquitto/mosquitto.conf

# Listen on default MQTT port
listener 1883

# Allow anonymous connections (development only)
allow_anonymous true

# For production: require authentication
# password_file /etc/mosquitto/passwd
# allow_anonymous false

MQTT vs. HTTP for IoT

MQTT and HTTP are both used for IoT communication, but they serve different needs:

Choose MQTT when:

• Devices are constrained (battery, bandwidth, CPU)
• Real-time, push-based communication is needed
• Many devices need to receive the same update simultaneously

Choose HTTP when:

• Simple request/response interactions are sufficient
• Integration with existing REST APIs is required
• Stateless communication is preferred

Summary

MQTT is purpose-built for IoT communication:

• Lightweight — minimal overhead, suitable for constrained devices
• Publish/Subscribe — decoupled architecture that scales naturally
• Broker-based — central routing without direct device-to-device connections
• QoS levels — flexible delivery guarantees for different use cases
• Topic hierarchy — structured addressing with wildcard subscriptions

For any IoT project that needs reliable, scalable, low-overhead messaging between devices and applications, MQTT is the standard starting point.