ProcirelMQTT Explained: The Protocol Behind Practical IoT
MQTT is a tiny publish/subscribe protocol: devices publish messages to named topics. Anyone subscribed to those topics receives them. Neither side needs to know the other exists which is exactly why it scales from one sensor to factory floors.
> At a glance: 8 minute guide · part 4 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.
## Topics and the broker
A broker (Mosquitto, HiveQ…) routes everything. Topics are hierarchical strings home/livingroom/temperature and subscriptions accept wildcards: home/+/temperature or home/#. One broker, hundreds of quiet clients.
| C | o | n | c | e | p | t | | | | | |
| — | — | — | — | — | — | — | — | — | — | — | — |
| W | h | a | t | | i | t | | d | o | e | s |
| T | y | p | i | c | a | l | | u | s | e | |
| Topic | Named channel | home/kitchen/temp | | | | | | | | | |
| + / # wildcards | Subscribe patterns | + filters one level | | | | | | | | | |
| QoS 1 | At-least-once delivery | Most telemetry | | | | | | | | | |
| Retained | Last value kept for new subscribers | Switch/desired state | | | | | | | | | |
| LWT | Announces unexpected death | Device offline alerts | | | | | | | | | |
## QoS levels and retained messages
QoS 0 sends and forgets; QoS 1 guarantees at-least-once (duplicates possible). QoS 2 guarantees exactly-once with more overhead. Retained messages let a new subscriber instantly learn the last known value perfect for state topics like switch positions.
## Keepalive, LWT and security
Keepalive pings detect silently dead clients; the Last Will message publishes on ungraceful drops. Use username/password at minimum, TLS where feasible. Never expose a broker to the raw internet VPN or an authenticated bridge is the sane pattern.
## How to apply this in your build
Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Design a topic tree before wiring any devices
2. Publish telemetry to state topics, subscribe to command topics
3. Enable retained messages for state, not for streams
4. Set keepalive and a Last Will for every device
### Worked example
A thermostat publishes home/bedroom/setpoint (retained) and home/bedroom/temperature (QoS 0, every 30 s). Home Assistant restarts and instantly knows the setpoint without asking. Run the numbers yourself with the related calculator and the result should agree to within rounding.
> Practical note from the bench. Topic naming pays compound interest: location/device/measurement reads itself. We document the tree in the project README before flashing anything.
## Common mistakes to avoid
– Publishing high-rate streams as retained brokers bloat
– Chatty QoS 2 on battery devices handshakes cost milliamp-hours
– Open broker port forwarded to the internet “temporarily”
## Key takeaways
– Topics and the broker the foundation of this guide; revisit it if any measurement here surprises you.
– QoS levels and retained messages the foundation of this guide; revisit it if any measurement here surprises you.
– Keepalive, LWT and security the foundation of this guide; revisit it if any measurement here surprises you.
## Prerequisites and preparation
Before starting. Design a topic tree before wiring any devices and publish telemetry to state topics, subscribe to command topics. Keep a calculator to hand every number in the worked example is reproducible. Total time including the bench steps: about 6–8 minutes.
## Who benefits most
Hobbyists meeting this topic for the first time, students who want the version with real numbers instead of abstract symbols. Returning engineers refreshing a corner of the craft. The mistake list alone justifies the visit every entry in it was learned the expensive way.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Topics and the broker |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Common mistakes to avoid |
## How this fits the complete IoT and ESP32 guide track
This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [Mosquitto broker setup](/tutorial/mosquitto-mqtt-broker-setup) and [WiFi reconnection patterns](/tutorial/esp32-wifi-reconnection-strategies).
## Frequently asked questions
MQTT or HTTP for my project?
Telemetry and commands between machines → MQTT. Serving web pages or one-off cloud calls → HTTP.
Does MQTT need the internet?
No a local broker on a Raspberry Pi runs your smart home entirely offline.
Where do I go next?
Back to the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page it indexes every guide in this track and updates as new ones are published.
## Continue this track
– Building a foundation? The [iot, sensors & esp32 complete guide](/tutorial/iot-esp32-complete-guide) maps every step in order.
– Next: [Gyroscope Sensor Explained: Working, Arduino & Uses](/tutorial/gyroscope-sensor)
– Next: [5G Architecture Explained: What Actually Changed](/tutorial/5g-architecture-explained)
– Next: [Arduino to ESP32 Microcontroller Guide for Engineers](/tutorial/arduino-to-esp32)
– Work the numbers: [battery life estimator](/tools/battery-life) · [LM317 designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
## Measurement discipline
Keep a lab notebook entry for every build in this track. The measured values, the deviations from the guide and the reason for each. Six months from now, those notes are worth more than any tutorial. They describe your bench and your components rather than a general case.
When a result here disagrees with your expectation, write down both numbers before changing anything. The gap between predicted and measured is where the real engineering lives. It is usually a tolerance, a parasitic or an assumption that was never checked.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## Hard-won notes
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.
Location, then device, then measurement. Document the tree before flashing the first device.
## How to revisit this guide
Second readings work best with a purpose. Pick one section from Topics and the broker,QoS levels and retained messages,Keepalive, LWT and security and rebuild only that part at the bench, predicting each value before measuring. Prediction errors mark exactly which concept needs the next pass, and the linked iot calculators resolve any arithmetic doubt in seconds. Keep the marked sections in your notebook: after a month of builds, that list becomes your personal IoT syllabus.