MQTT Concepts

Learning Goals 5 min

Arduino IoT Cloud was easy because it hid everything. Underneath, IoT Cloud (and almost every commercial smart-home product) speaks MQTT — a tiny, fast, reliable pub/sub protocol that runs on top of TCP/IP. Today you learn its four concepts before wiring up a real broker tomorrow. By the end of this lesson you will:

1. Define the four MQTT concepts: broker, client, topic, message.
2. Explain QoS levels 0, 1, 2 and pick the right one for "sensor stream" vs "turn off the pump".
3. Describe retained messages and last-will, the two features that make MQTT pleasant for IoT.

Warm-Up 10 min

No hardware today — just the model. Tomorrow we publish from an ESP to a real broker.

The pub/sub pattern in everyday terms

HTTP is request/response: client asks, server answers, both wait around. MQTT is publish/subscribe: clients drop messages into "mailboxes" (topics), and any other client subscribing to that mailbox automatically receives a copy. The middleman is the broker — a small server, often free or self-hosted, that fan-outs messages.

Why IoT loves it

• Tiny on-the-wire footprint (~2-byte header).
• Stays connected over hours/days (one TCP socket per device).
• One device can listen to thousands of topics or publish to one.
• No client needs to know about another client — broker decouples everyone.

New Concept · The four pieces 25 min

1. The broker

A small server program. The most popular open source one is Mosquitto. Free public brokers include test.mosquitto.org, broker.hivemq.com — fine for school projects, not production.

Brokers run on:

• Your laptop (install Mosquitto for testing).
• A Raspberry Pi on your home network (the standard Home Assistant setup).
• A cloud service (HiveMQ Cloud, AWS IoT Core, Adafruit IO).

2. The client

Any device that connects to a broker. Each client has a unique client ID (a string, like a username). Clients can both publish and subscribe.

Your ESP is a client. Home Assistant is a client. Your phone app might be a client. They never talk to each other directly — all messages flow through the broker.

3. The topic

A slash-separated label that names a kind of message. Examples:

home/livingroom/temperature
home/garage/door
sensors/plant1/moisture
robot/wheels/left/speed

Topics are hierarchical. Wildcards:

• + matches one level: home/+/temperature matches home/livingroom/temperature and home/bedroom/temperature but NOT home/livingroom/temp/raw.
• # matches everything below (multi-level): home/# matches every topic under home/.

4. The message

The payload sent under a topic. MQTT doesn't care about content — bytes are bytes. By convention, smart-home products send JSON payloads ({"temp": 22.5}) or plain text (22.5 or ON).

Quality of Service (QoS)

Pick the lowest QoS that's safe. Sensor streams at QoS 0; commands at QoS 1; rare critical things at QoS 2.

Retained messages

Normally, if a subscriber connects AFTER a publisher sent a message, the subscriber missed it. With the retain flag, the broker keeps the last message on each topic; new subscribers receive it immediately on subscribe.

Use case: sensor reports temperature once a minute (retained). Phone opens dashboard → broker delivers the most recent reading instantly, no waiting for the next push.

Last Will and Testament (LWT)

When a client connects, it can register a "will": "if I disconnect ungracefully (no proper goodbye), publish this message on this topic."

Use case: ESP-based sensor sets LWT = "offline" on topic home/plant1/status. On boot it publishes "online" (retained). If WiFi drops, the broker auto-publishes "offline" after a timeout. Dashboards see the device's connection state in real time.

The mental picture

Think of MQTT like a school bulletin board:

• The bulletin board = broker.
• Anyone reading = subscriber.
• Anyone posting = publisher.
• The categorised sections (Sports, Drama, Lost Property) = topics.
• The actual notes = messages.
• "Last seen Tuesday: closed" = retained message.
• "If I'm absent without notice, post that I'm sick" = last will.

Worked Example · Trace a smart-home message 20 min

Imagine your home Mosquitto broker running on a Raspberry Pi. Three devices:

• ESP-A: living-room temperature sensor.
• ESP-B: kitchen light switch.
• Home Assistant (Raspberry Pi dashboard).

Scenario 1 — Sensor publishes a reading

1. ESP-A reads temperature → 22.5 °C.
2. ESP-A publishes {"value": 22.5} to topic home/livingroom/temp with QoS 0 and retain=true.
3. Broker stores it as the retained message for that topic.
4. Home Assistant is subscribed to home/+/temp → receives the message → updates its dashboard.

Scenario 2 — Phone toggles a light

1. User taps a button in Home Assistant's app.
2. Home Assistant publishes ON to home/kitchen/light/set with QoS 1.
3. Broker receives, ACKs to Home Assistant, fans out to subscribers.
4. ESP-B (subscribed to home/kitchen/light/set) receives → switches the relay.
5. ESP-B publishes ON to home/kitchen/light/state to confirm. Home Assistant's UI shows it as on.

Scenario 3 — ESP-A loses WiFi

1. ESP-A registered LWT on connect: topic home/livingroom/temp/status, message offline, retain=true.
2. WiFi drops. Broker waits ~30 s (keep-alive timeout).
3. Broker publishes offline to home/livingroom/temp/status on its own.
4. Home Assistant's "living room sensor" indicator turns red.
5. When ESP-A comes back, it publishes online → indicator goes green.

Why this is so much nicer than HTTP polling

• ESP-A pushes once per minute, not every second.
• ESP-B receives commands in < 100 ms.
• Connection state visible to all parties without polling.
• One broker can handle hundreds of devices.
• One TCP socket per device, kept alive — no reconnect overhead per message.

Try It Yourself · Paper exercises 15 min

home/kitchen/fridge/main/temperature
home/kitchen/fridge/main/door
home/kitchen/fridge/freezer/temperature
home/kitchen/fridge/freezer/door
home/kitchen/fridge/status        (online/offline)

Mini-Challenge · Sketch the topology 10 min

1. Draw a square in the middle = Broker.
2. Draw three circles around it = three IoT devices.
3. Label each device's "publishes" and "subscribes" topics.
4. Draw arrows showing the message flow for a typical scenario (e.g. user toggles light).

This diagram is the "system architecture" of any smart home. Tape it next to your wiring diagram.

Recap 5 min

MQTT = pub/sub through a broker. Four pieces: broker, client, topic, message. Wildcards + and #. QoS 0 / 1 / 2 trade reliability for speed. Retain = "keep the last one for new subscribers". LWT = "auto-publish this if I die without saying goodbye". Tomorrow we'll connect a real ESP to a public broker and publish our first message.

MQTT

Message Queuing Telemetry Transport — lightweight pub/sub protocol designed for IoT. Tiny header, runs over TCP, used by Home Assistant, AWS IoT, Adafruit IO, and most commercial smart-home gear.

Broker

Server that receives published messages and fans them out to subscribers. Mosquitto is the open-source standard.

Client

Any device connected to a broker. Identified by a unique client ID.

Topic

Slash-separated label naming a message channel. Hierarchical, case-sensitive.

Wildcards

+ = single level, # = multi-level (rest of the tree). Only allowed in subscribe topics, not publish.

QoS (Quality of Service)

0 = at most once, 1 = at least once, 2 = exactly once. Higher = more reliable, slower.

Retain

Broker keeps the last message on each retained topic; new subscribers get it on subscribe.

Last Will and Testament (LWT)

A message the broker auto-publishes if a client disconnects without a clean goodbye. The IoT "heartbeat" pattern.

Keep-alive

Interval at which clients send a ping to confirm they're alive. Broker triggers LWT after a missed ping.

Mosquitto

The most popular open-source MQTT broker. Runs on Raspberry Pi, laptops, cloud VMs. Free.

Homework 5 min

1. Install MQTT Explorer (free desktop app — Mac/Win/Linux). Connect to test.mosquitto.org on port 1883.
2. Subscribe to #. Watch the firehose of public test traffic.
3. Publish your own message to advaslearning/<your-name>/hello. Take a screenshot.
4. Read ahead to ARD-L04-14 (PubSubClient Library). Tomorrow we publish from an ESP.