MQTT Messaging Explained for Sensor Projects

The problem it solves

Imagine three sensors and two displays. If each sensor must know the address of each display, adding a fourth sensor means changing every display, and a display that is switched off causes errors in the sensors. The connections multiply quickly, and everything depends on everything else.

MQTT takes a different route. It places a broker in the middle and lets devices talk to the broker rather than to each other. A sensor says “here is a reading” without knowing who will read it. A display says “tell me about readings” without knowing who produces them. The protocol is lightweight, designed for small devices and unreliable links, which is why it is so common in connected projects.

Publish and subscribe

The model has three roles.

• Publisher: a client that sends a message. A temperature sensor publishing a reading is a publisher.
• Subscriber: a client that asks to receive messages of a certain kind. A dashboard showing temperatures is a subscriber.
• Broker: the server that receives every published message and forwards it to every client that has subscribed to a matching topic.

One device can be both. A heating controller might subscribe to temperature readings and publish a command to a heater. Publishers and subscribers do not need to be online at the same moment, and they do not need to know how many others exist. That looseness is the main benefit.

Topics

Messages are labelled with a topic, a text string that looks like a path, with levels separated by slashes. A tidy scheme might be something like building, then room, then measurement. The exact names are yours to choose.

Subscribers can use wildcards to cover many topics at once. One kind of wildcard matches a single level, for example every room’s temperature, and another matches everything below a point. This lets a dashboard follow a whole house with one subscription.

Topic naming deserves thought early on, because changing it later means updating every device. Some habits that tend to help:

• Use a consistent order, from general to specific.
• Keep names short and lowercase, and avoid spaces.
• Separate readings (what a device reports) from commands (what you ask it to do), so that it is clear which direction information flows.
• Include a device identifier so you can tell two similar sensors apart.

What a message contains

A message is a topic plus a payload, the content. The payload is just bytes. Many projects send a plain number or a short piece of structured text. MQTT does not care what is inside; you and your subscribers must agree on the format. Agreeing on units (degrees Celsius versus Fahrenheit, for example) and a time convention up front saves confusion later, and the same thinking applies to any web APIs you build alongside.

Keep payloads small. The protocol’s strength is low overhead, and small messages suit constrained devices and slow links.

Quality of service

MQTT offers three levels of delivery assurance, chosen per message or subscription.

1. At most once. The message is sent and not confirmed. It may be lost, but it is cheap. Suitable for frequent readings where one missing value does not matter.
2. At least once. The message is confirmed, and resent if needed, so it may arrive more than once. Suitable when losing a message is worse than seeing it twice, provided the receiver can cope with duplicates.
3. Exactly once. The message is delivered once, using a more involved exchange. It costs more traffic and is rarely needed for sensor readings.

Higher levels use more bandwidth and more power. For most hobby sensors, the lowest or middle level is typically enough. The guarantee applies between each client and the broker; it does not guarantee that a subscriber acts on the message.

Retained messages and last will

Two features are especially useful for devices that come and go.

• Retained messages. The broker can remember the most recent message on a topic and give it to any new subscriber immediately. A dashboard that starts up can then show the last known value rather than a blank until the next reading.
• Last will. When a client connects, it can ask the broker to publish a message on its behalf if the client disappears unexpectedly. This is a simple way to mark a sensor as offline. Without it, a dead sensor and a quiet sensor look identical.

Combining the two lets a dashboard show a status for each device that stays right even after restarts.

Choosing and running a broker

A broker can run on a small computer at home, on a server, or as a hosted service. For a household with a few sensors, running one on a small board on your own network is common and keeps data local. Larger deployments plan for capacity and reliability.

Points to consider:

• Access control. An open broker lets anyone publish commands. Require usernames and passwords, never rely on default credentials, and restrict which clients may use which topics.
• Encryption. Without protection, messages cross the network readable by anyone who can see the traffic. Enabling data encryption in transit is generally advisable, particularly if messages leave your home network.
• Exposure. Do not open the broker to the whole internet unless you have a clear reason and the protections to match. Safer options for reaching it from outside are discussed under remote access.
• Persistence and backups. Decide whether the broker keeps messages across restarts and whether its configuration is saved.

Where MQTT fits and where it doesn’t

MQTT is good at moving small readings and commands among many devices. It is less suited to sending large files or video. It also does not store history by itself; a separate database or logging tool usually subscribes and records the values for graphs. Whether to use a relational or a flexible store is a general question of database choice.

It is one of several ways to move data. The choice of radio, for example in the comparison of wireless protocols, determines how a device reaches the network; MQTT works above that, regardless of whether the packets travelled by Wi-Fi, Ethernet or something else.

Common pitfalls

• Topic sprawl. Without a naming plan, topics multiply into confusion.
• Hidden duplicates. At-least-once delivery can repeat a message, so commands should be safe to repeat.
• Silent failures. A sensor that has crashed may look the same as one with nothing to report unless you use a last-will notice or a heartbeat.
• Clock differences. If readings carry a time, make sure devices agree on how it is set.
• Forgotten devices. Old clients that still publish or subscribe can clutter the system.

A good first project is small: one sensor publishing to a broker, one subscriber printing the values, then a second sensor to see how little needs to change. That small experiment shows the main idea better than any description.