If you build anything beyond a single-brand smart home, MQTT eventually appears. It is a lightweight messaging protocol designed for devices with little power and unreliable links, and it has become a common glue between sensors, gateways, and automation software. The core ideas fit on one page, and learning them removes a lot of mystery from device documentation.

The Publish and Subscribe Idea

Most protocols you know are request and response: you ask, a device answers. MQTT works differently. Devices and applications connect to a central server called a broker. A device publishes a message to a named topic. Anything interested in that topic subscribes to it, and the broker forwards messages to all subscribers.

The sender and receiver never talk directly. A temperature sensor publishes a reading and does not care who listens. Your dashboard, a logging service, and an automation rule can all subscribe independently. Adding a new consumer requires no change to the sensor. That decoupling is the main reason people like it.

Topics Are Just Structured Names

A topic is a text string with levels separated by slashes, for example a pattern like home, then room, then device, then measurement. There is no built-in meaning; you and your software agree on a convention. Subscribers can use wildcards to receive groups of topics: a single-level wildcard matches one level, and a multi-level wildcard matches everything below a point.

Naming deserves thought early. A consistent structure such as location first, then device, then the quantity, makes wildcards powerful and keeps things readable. Avoid spaces and unusual characters, keep names lowercase, and do not put changing values like dates inside topic names. Renaming topics later means updating every device and rule that uses them.

Payloads Carry the Data

The payload is the message content. It can be plain text, a number, or structured data such as JSON. MQTT does not care. JSON is common because it can carry several fields, like a value, unit, and timestamp, in one message. For simple devices, a bare number on a dedicated topic is fine. Pick one style per system and document it.

Messages That Stay and Messages That Warn

Two features solve common problems. Retained messages tell the broker to keep the last message on a topic and deliver it immediately to new subscribers. Without this, a dashboard that starts after a sensor published would show nothing until the next update. Retention is useful for state, such as whether a light is on, and less useful for events, such as a button press, where replaying an old event would be wrong.

Last will and testament lets a device register a message the broker publishes if the device disconnects unexpectedly. It is the standard way to show offline status: the device announces “online” when it connects, and the broker announces “offline” if it vanishes.

Quality of Service in Plain Terms

MQTT offers three delivery levels. Level zero sends a message at most once with no confirmation, which is fine for frequent readings where losing one hardly matters. Level one guarantees at least one delivery, so duplicates are possible. Level two ensures exactly once delivery at the cost of extra exchanges. Most home and light industrial uses are fine with levels zero or one. Higher levels cost battery and bandwidth, so choose by consequence: a lost temperature sample is harmless, a lost command to close a valve is not.

Concept	What it does	When it helps
Broker	Routes messages between clients	Always required
Topic	Names a stream of messages	Organizing devices and data
Wildcard	Subscribes to many topics at once	Dashboards and logging
Retained message	Keeps last value for new subscribers	State such as on/off
Last will	Announces unexpected disconnects	Online/offline status
QoS level	Sets delivery guarantee	Commands versus routine readings

Run and Secure a Broker Sensibly

Many hobbyists run an open source broker on a small always-on computer or a home server. Keep it simple: one broker, backed up configuration, and a documented topic scheme. Do not leave a broker open without authentication. Create separate credentials for each device or class of device, restrict which topics each may publish or subscribe to, and use encrypted connections where your devices support them. Never expose a broker directly to the internet without careful hardening; secure remote access is usually better handled through a VPN. Check the broker’s current documentation for security options.

Example: A Garden Moisture Sensor

Imagine a small soil moisture sensor in the garden. It connects to the broker and publishes the moisture value every ten minutes to a topic structured like garden, bed one, moisture. It sets a last will so the broker announces when the sensor drops off. A dashboard subscribes to everything under garden and shows current values. An automation subscribes to the moisture topic and, if the value stays low for a while and no rain is forecast, publishes a command to a topic that a smart valve listens on. The valve, sensor, dashboard, and automation never know about each other. Replacing the moisture sensor later just means publishing to the same topic.

Troubleshooting Habits

When something does not work, subscribe to everything with a multi-level wildcard using a command line or desktop client and watch what flows. Check that the topic matches exactly, including case. Confirm the client is authorized for that topic, since many brokers silently drop unauthorized publishes. Check for a duplicate client identifier, because two clients using the same ID can kick each other off repeatedly.

Frequently Asked Questions

Is MQTT a replacement for Wi-Fi or Zigbee? No. It is an application-level protocol that runs over a network connection such as Wi-Fi or Ethernet. Zigbee devices usually reach MQTT through a gateway.

Do I need MQTT for a basic smart home? Not necessarily. Many consumer systems work without it. It becomes valuable when you mix devices, build custom sensors, or want flexible automation.

What is the difference between a broker and a hub? A hub often handles device radios and pairing. A broker only routes messages between clients. Some systems include both.

Should I use retained messages for everything? No. Retain state, not events, or new subscribers may act on stale triggers.

Can I use MQTT over the internet? Yes, but secure it carefully with encryption, authentication, and ideally a VPN. Follow the broker’s security guidance.

Next Step

Install a broker on any spare computer, connect a free desktop client, and publish a test message to a topic you invent. Subscribe from a second window and watch it arrive. That ten-minute experiment makes every future MQTT document easier to read.