3 MQTT Publish-Subscribe Basics

3.1 Start With One Publication

Why now: Track the cold-store reading so each later subscription has a real message to match. About 16–24 min (estimate)

This section: Start With One Publication — Picture a cold-store sensor sending one numbered temperature record.

Trace One Reading Through Every Subscription

Picture a cold-store sensor sending one numbered temperature record. The alarm screen and the archive may listen to the same topic, yet one can update while the other stays stale. The send is only the start of the evidence path.

Telemetry means measurements and status sent from a remote device for review. MQTT means Message Queuing Telemetry Transport. A broker is the service that routes messages by topic. A payload is the useful content carried inside one message.

Publish one record with source, time, unit, and quality. Add and remove a listener, repeat the record, disconnect one receiver, reconnect it, and restart the sender. Compare what each receiver accepted rather than treating a successful connection as proof.

This runway does not choose a delivery setting or prove an external action. The deeper sections explain topics, subscriptions, retained state, sessions, routing, and the failure boundaries around each receiver.

Imagine a door sensor publishing home/front-door/contact = open. The sensor does not know whether a phone app, alarm panel, logger, or automation rule is listening. MQTT publish-subscribe works because the broker receives one publication, matches it to subscriptions, and leaves evidence about who should receive it next.

3.2 MQTT Pub-Sub Separates Senders, Receivers, and Evidence

Why now: Name the publisher, broker and receivers before testing what each one can prove. About 16–24 min (estimate)

This section: MQTT Pub-Sub Separates Senders, Receivers, and Evidence — MQTT publish-subscribe is a broker-mediated messaging pattern.

MQTT publish-subscribe is a broker-mediated messaging pattern. A device publishes a message to a topic. The broker receives it and forwards it to clients whose subscriptions match that topic. The publisher does not need to know who is listening, and each subscriber does not need to know which device produced the message.

This decoupling is why MQTT fits many IoT telemetry and command workflows. A sensor can keep publishing readings as dashboards, rules engines, data stores, and maintenance tools subscribe or unsubscribe over time. The broker becomes the routing and delivery boundary that must be designed, secured, observed, and tested.

Before separating client responsibilities, inspect Figure 3.1 to locate the topic name, subscription filter, and broker match that connect otherwise independent applications.

+

Follow one message through the broker. Check who receives it. Read Figure 3.1 from the publisher’s concrete topic to the broker, then from the subscriber’s filter into the broker’s matching decision and onward to delivery. The publisher never addresses the subscriber, and the subscriber never needs the publisher’s address; their shared contract is the topic taxonomy and payload meaning. This flow anchors the chapter’s later discussion of wildcard scope, QoS, retained state, and evidence.

That separation is helpful only when the topic contract is explicit. The publisher owns the message family and payload version. The broker owns the match between concrete topic names and subscription filters. Each subscriber owns the reason it needs the stream and the limit on how broad its filter may be. When a new dashboard or analytics job is added, the sensor firmware should not need a new destination list; the broker should start routing after the new client subscribes to the approved filter.

A quick pub-sub review therefore asks for a small evidence trail: publisher client id, publish topic, subscriber filter, broker access-control result, delivery count, and any retained or queued state. Without that trail, "decoupled" can become hidden coupling because nobody can prove which clients are supposed to receive which messages.

The One-Minute MQTT Roles

Beginner Examples

These examples show how subscriptions add consumers and set their scope. A soil sensor publishes moisture readings. A dashboard and irrigation rule both subscribe without requiring firmware changes on the sensor. A maintenance service subscribes to device health topics. It can be added after deployment because the publisher only knows the topic, not every future consumer. A broad wildcard can be useful for operations but dangerous for normal applications. It may expose unrelated devices or overload a subscriber.

Overview Knowledge Check

If this explains the role split, you can stop here. Continue to Practitioner when you need to design a topic and subscription record for a real deployment.

3.3 Design the Topic and Subscription Record

Why now: Set the topic contract next so the broker has clear filters to match. About 16–24 min (estimate)

This section: Design the Topic and Subscription Record — A useful MQTT design starts with one message family, not with a broker product.

A useful MQTT design starts with one message family, not with a broker product. Name the message, its topic, the publisher identity, the allowed subscribers, the delivery behavior, and the evidence that shows routing worked.

Topic Record Workflow

Worked Example: Greenhouse Telemetry

A greenhouse sensor publishes air temperature every few minutes. The dashboard needs fresh values. The automation rule needs alerts. The data warehouse needs history. A topic record keeps those needs separate instead of forcing the sensor to know every consumer.

This record avoids two common mistakes: making the topic too vague for authorization, and using wildcards so broadly that subscribers receive data they do not need or should not see.

Practitioner Knowledge Check

If your job is to design a usable MQTT namespace, this topic and subscription record is the artifact to keep. Continue to Under the Hood for broker and session boundaries.

3.4 Broker Routing, Sessions, and Failure Boundaries

Why now: Check broker state next so a routed message is not taken as proof of device action. About 16–24 min (estimate)

This section: Broker Routing, Sessions, and Failure Boundaries — The MQTT broker is not just a pipe.

The MQTT broker is not just a pipe. It authenticates clients, checks authorization, stores session state when configured, matches topic filters, forwards messages, handles retained messages, and may publish last-will status when a client disconnects unexpectedly.

A staff display that needs room temperatures should receive read permission for those temperature topics while command topics remain outside its ACL.

Broker Boundary Ledger

Mechanics That Matter

Topic filters are routing rules. The + wildcard matches exactly one topic level; # matches all remaining levels and should be tightly controlled. QoS is delivery behavior, not application truth. MQTT QoS can help with message transfer, but the application still needs freshness, idempotency, and duplicate handling. Retained messages are state snapshots. They help new subscribers see the latest value, but can make old state look current if freshness is not visible. Last will is failure evidence. It gives the broker a way to publish an offline status when a client disappears without a graceful disconnect.

Common Review Pitfalls

Follow the sequence from decision to evidence. First, Using # for normal applications. Broad subscriptions are easy during testing and risky in production. Next, Putting authorization only in application code. Broker topic ACLs should prevent the wrong publisher or subscriber path before the message reaches application logic. Next, Confusing retained with fresh. A retained value can be useful and still be old; show age or source timestamp. Finally, Ignoring offline semantics. Without a status topic, last-will policy, and stale-data rule, missing devices can look healthy.

Under-the-Hood Knowledge Check

At this depth, MQTT is a broker contract. The topic tree, subscription filters, client identity, delivery state, and failure semantics should be explicit enough that routing behavior can be reviewed after deployment.

The end-to-end flow in Figure 3.2 ties broker fan-out to the actual fields carried by one QoS 1 publication.

+

Follow Figure 3.2 from the boiler sensor to the broker’s topic match, then compare the filters used by the operations UI and alarm service. Both consumers can receive the same publication without knowing the sensor’s address. In the lower packet, the topic name drives routing, the packet identifier supports the QoS 1 exchange, and the payload retains the application value and unit. These fields prove different things: a valid route and completed MQTT handshake still do not establish that the physical reading is true or safe to act upon.

3.5 Route a Boiler Reading Through Topic Filters

Why now: Test the boiler topic against filters to see which subscribers receive the reading. About 16–24 min (estimate)

This section: Route a Boiler Reading Through Topic Filters — A boiler publishes plant/boiler7/temperature with payload 83.4 C.

A boiler publishes plant/boiler7/temperature with payload 83.4 C. In Figure 3.1, follow the publisher to the broker and then to each matched subscriber. Figure 3.2 separates the TOPIC NAME, PACKET ID where used, and PAYLOAD, so a valid topic match is not confused with a valid temperature schema.

An operations client subscribed to plant/+/temperature receives the boiler reading because + covers one topic level. An alarm client subscribed to plant/# also receives it because # covers the remaining levels. A client subscribed to plant/boiler7/pressure does not match, even if it can decode the same text payload.

3.6 Summary

This section: Summary — MQTT publish-subscribe routes messages through a broker, so publishers and subscribers do not need direct knowledge of each other.

MQTT publish-subscribe routes messages through a broker, so publishers and subscribers do not need direct knowledge of each other. Topic design is a product and operations contract, not just a string convention. The + wildcard matches one topic level; # matches the remaining levels and should be restricted. QoS, retained messages, persistent sessions, and last will shape delivery evidence, but they do not remove the need for application-level freshness and duplicate handling. A defensible MQTT design records publisher identity, topic shape, subscriber filters, broker ACLs, delivery behavior, and stale-data handling.

3.7 Key Takeaway

This section: Key Takeaway

3.8 See Also

This section: See Also