MQTT Module Guide
Start Here: Follow One Reading
Picture a field sensor that sends one reading, loses its link, and reconnects later. This guide helps you decide what should be sent, remembered, repeated, and checked.
MQTT means a send-and-subscribe message system. A protocol means the shared rules that systems follow. Telemetry means readings sent from a device for remote use. A broker means the service that routes each message. A payload means the useful data inside that message. QoS means the chosen level of delivery effort and duplicate risk.
Start with the reading and the person or service that needs it. Then trace the topic, route, delivery choice, reconnect rule, and proof. This runway gives you the route; later chapters keep the full packet and production detail.
Follow Broker Bex as one reading crosses a broker, link loss, reconnect rules, and final receipt checks.
-
A field sensor sends one reading to the broker.
-
The link breaks before the full path is proved.
-
The sensor reconnects under a chosen rule.
-
Trace what arrived, repeated, and reached the reader.
Your guide: Broker Bex
“A message with no subscriber is a tree falling in an empty forest — design the topic before the payload.”
MQTT is the application protocol many IoT systems use when devices publish telemetry, receive commands, and reconnect across unreliable links. This module groups the MQTT chapters into a focused book so the protocol can be built, searched, and reviewed as its own route.
Use this book when you need to reason about MQTT as a system design choice, not just as a client library. The chapters move from broker architecture and publish-subscribe roles through topic design, packet features, QoS, sessions, security, first-message practice, implementation patterns, and production evidence.
Start With One Message
Imagine one sensor reading leaving a device: it needs a topic name, a broker route, a delivery promise, a session rule, and proof that the right subscriber received it. This module follows that message from first publication to production operation so MQTT feels like a system you can inspect, not a library call you hope works.
Recommended Route
- Start with MQTT Architecture to understand clients, brokers, routing, sessions, retained messages, and last will behavior.
- Read MQTT Publish-Subscribe Basics to establish the publisher, subscriber, and broker roles.
- Use MQTT Topic Design and Wildcards before building a topic tree or access-control boundary.
- Review MQTT Advanced Fundamentals, MQTT Quality of Service Levels, MQTT Session Management, and MQTT Security Fundamentals before production design.
- Move into MQTT Implementation Basics and First MQTT Message, then continue with MQTT Python Patterns and MQTT Implementation Hands-On Labs.
- Finish with MQTT Production Deployment, then keep the MQTT Quick Reference Card nearby for later work.
Design Questions
- What does each topic represent, and who is allowed to publish or subscribe to it?
- Which messages can tolerate loss, duplicates, delays, or replay?
- Does the system need retained messages, persistent sessions, or last will notifications?
- Where is security enforced: TLS, client identity, topic ACLs, broker policy, or application confirmation?
- What production evidence proves the broker, clients, and monitoring behave as expected?