MQTT · Study deck

MQTT Publish-Subscribe Basics

Picture a cold-store sensor sending one numbered temperature record.

Broker Bex is your guide for this deck.

fundpubsub
A numbered temperature record leaves a cold-store sensor for a broker and interested consumers.
iotclass.org

After studying this chapter

Learning objectives

Trace a numbered reading from publisher to broker to subscribers.

  • Trace one publication route.A publisher sends to the broker; subscribers register their interests.
  • Match topic names and filters.Check the packet topic and the filter levels that select it.
  • Keep evidence boundaries clear.Delivery, freshness, and physical action need different evidence.
Trace publisher → broker → subscriber. Match a topic to a filter. Read a PUBLISH packet’s topic, packet identifier where used, and payload. Explain what QoS, retained state, sessions, and a last will change. Keep routing evidence separate from freshness and action evidence.
iotclass.org

Major section

Start With One Publication

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.

Why it matters

MQTT publish-subscribe works because the broker receives one publication, matches it to subscriptions, and leaves evidence about who should receive it next.

iotclass.org

Major section

Start With One Publication (continued)

A broker is the service that routes messages by topic.

  • A payload is the useful content carried inside one message.
  • This runway does not choose a delivery setting or prove an external action.
  • The sensor does not know whether a phone app, alarm panel, logger, or automation rule is listening.
iotclass.org

Major section

Broker Routing, Sessions, and Failure Boundaries

A PUBLISH packet carries a topic, a packet identifier when used, and a payload.

  • Topic name directs routing.The broker matches the published topic against subscribed filters.
  • Packet identifiers support exchanges.For QoS one, it supports the protocol delivery exchange.
  • Payload carries application data.A matching route does not validate the reading or its unit.
An MQTT boiler sensor publishes through a broker to two matching subscribers above a field-by-field PUBLISH packet.
An MQTT boiler sensor publishes through a broker to two matching subscribers above a field-by-field PUBLISH packet.

TOPIC NAME → broker routing
PACKET IDENTIFIER → QoS 1 exchange
PAYLOAD → value and unit for the application
A valid topic match does not validate the temperature schema.

An MQTT boiler sensor publishes through a broker to two matching subscribers above a field-by-field PUBLISH packet.
iotclass.org

Major section

Route a Boiler Reading Through Topic Filters

Compare the boiler topic with each filter, one level at a time.

  • Operations receives the temperature.The plus wildcard covers the single boiler level.
  • The alarm receives the branch.The hash wildcard covers the remaining topic levels.
  • Pressure does not match temperature.The final literal topic level must agree.
Boiler sensor publishes topic plant/7/temp and payload 83.4 through a broker to an operations UI and alarm service, with both matching filters and packet fields.
MQTT publisher, broker, and subscriber message flow

Publish plant/boiler7/temperature = 83.4 C
plant/+/temperature → match
plant/# → match
plant/boiler7/pressure → no match: final level differs.

Boiler sensor publishes topic plant/7/temp and payload 83.4 through a broker to an operations UI and alarm service, with both matching filters and packet fields.
iotclass.org

Major section

Route a Boiler Reading Through Topic Filters (continued)

A last will reports a lost session; an online publication reports reconnection.

  • A last will reports connection loss.It is a status publication, not a new temperature measurement.
  • Record reconnection separately.The topic names boiler 7 or boiler 8.
  • Broker permissions separate clients.Boiler 7 must not publish under boiler 8’s identity.
Last will reports ungraceful session loss; a later online publication reports reconnection. Neither is a temperature measurement. plant/+/temperature receives boiler 7 and boiler 8; broker permissions must separate their publisher identities.
iotclass.org

Major section

Summary

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.
iotclass.org

Deck summary

Key takeaways

The alarm screen and the archive may listen to the same topic, yet one can update while the other stays stale.

  • A broker is the service that routes messages by topic.
  • Both consumers can receive the same publication without knowing the sensor's address.
  • A boiler publishes plant/boiler7/temperature with payload 83.4 C.
  • If boiler 7 loses its MQTT session without a clean close, the broker can publish the stored will to a status topic.
iotclass.org

Retrieval practice

Recall check 1 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q1What is the main design value of MQTT publish-subscribe in an IoT deployment?

APublishers and subscribers are decoupled through broker-routed topics.
BEvery device sends messages directly to every dashboard, rule engine, and database.
CThe broker removes the need for authentication, topic design, or delivery evidence.
DSubscribers choose sensor firmware behavior by changing the publisher code at runtime.
Show answer

Answer: A MQTT's broker and topic model lets producers and consumers evolve independently, as long as the topic contract remains stable.

iotclass.org

Retrieval practice

Recall check 2 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q2A retained command waits for a device that has been offline. What should the design review do before using retained state?

ACheck stale command safety on reconnect and define a retained-state rule.
BKeep every old command even when reconnect makes its action unsafe.
CUse a broad wildcard instead of reviewing the command's age and effect.
DRaise QoS and skip the stale-command review after device reconnection.
Show answer

Answer: A A retained command can be delivered later; its age and effect need an explicit policy.

iotclass.org

Retrieval practice

Recall check 3 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q3A broker accepted a publication, but the dashboard shows no update. Which record best checks the routing boundary?

AKeep the sensor payload because its receipt at the broker proves the dashboard subscription delivered the update.
BKeep only a frozen dashboard screenshot with no subscriber trace.
CKeep only broker product name, without subscription or QoS evidence.
DCheck publish acceptance, topic match, forwarding, subscriber, and QoS ACK.
Show answer

Answer: D The trace separates broker acceptance, filter matching, and forwarding; QoS 0 has no protocol acknowledgement.

iotclass.org

Retrieval practice

Recall check 4 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q4A dashboard needs all temperature readings from greenhouse 2, but not other sites or other signal types. Which subscription is the best fit?

Asite/greenhouse-2/+/air/temperature for all its matching sensors.
Bsite/#, also receiving readings from other sites and signal types.
Csite/greenhouse-2/sensor-17/air/temperature for one sensor only.
Dgreenhouse-2-temperature, which misses the published site hierarchy.
Show answer

Answer: A The single-level wildcard covers multiple devices while keeping the site and signal type constrained.

iotclass.org

Retrieval practice

Recall check 5 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q5A new dashboard receives every topic under site/#, including maintenance commands and device credentials events it should not see. Which broker-boundary fix is strongest?

AKeep site/# because subscribers can ignore unwanted messages after receiving them.
BMove all topic meaning into the payload so every subscriber uses one flat topic.
CDisable broker logs because the dashboard currently displays the expected data.
DUse a narrower topic filter and enforce subscriber authorization in the broker ACL.
Show answer

Answer: D Topic design and broker authorization should constrain what the dashboard can receive.

iotclass.org

Print reference

Answers

Answer key.

  1. A · MQTT's broker and topic model lets producers and consumers evolve independently, as long as the topic contract remains stable.
  2. A · A retained command can be delivered later; its age and effect need an explicit policy.
  3. D · The trace separates broker acceptance, filter matching, and forwarding; QoS 0 has no protocol acknowledgement.
  4. A · The single-level wildcard covers multiple devices while keeping the site and signal type constrained.
  5. D · Topic design and broker authorization should constrain what the dashboard can receive.
iotclass.org
Topic contract → retained-state policy → broker trace → narrow filter → broker authorization.