MQTT · Study deck
MQTT Publisher-Subscriber Setup
Picture a desk sensor sending a button state to a small program on the same laptop.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
Name the three roles and prove one round trip.
- Name the publisher, broker, and subscriber.Identify what each role does in one local exchange.
- Prove one publish-subscribe round trip.Check both the broker route and the received subscriber message.
- Compare simulator and local broker paths.Choose the next exercise from the evidence you need.
- Choose the next test.Keep a prototype separate from a deployment claim.
Major section
In 60 Seconds
Telemetry means readings and status sent by a remote device.
- Message Queuing Telemetry Transport (MQTT) means a lightweight way for devices to exchange messages.
- A broker means the service that passes messages from senders to receivers.
- A payload means the useful data inside one message.
- Transport layer security means protection for a network stream; it is called TLS.
Major section
In 60 Seconds (continued)
Quality of service means the delivery promise chosen for a message; it is called QoS.
- Old state must not appear as a new button press.
- This runway does not prove a cloud path or production security.
- Getting started with MQTT requires three components: a broker (message server like Mosquitto), a publisher (sends data to topics), and a subscriber (receives data from topics).
Major section
Mobile Visual Flow
A sensor reading reaches the subscriber through the broker.
- The ESP32 reads the DHT22 sensor.
- The publisher sends a temperature every ten seconds.
- The subscriber checks the received value and its age.
Trace the reading into the broker, then to a matching subscriber.
After Wi-Fi loss, record reconnect and subscriber delivery evidence.
Major section
Mobile Visual Flow (continued)
Question: You want to build a soil moisture monitor that sends alerts to your phone when plants need watering.
- A learning exercise may use test.mosquitto.org, while a controlled deployment uses its own broker; in either case, the broker receives the ESP32 publication and routes it to every matching, authorized subscription.
- A Python service or mobile application subscribes to garden/moisture/plant1, interprets the payload, and triggers a notification when moisture is below the chosen threshold.
- The separation lets the phone move independently of the garden sensor while the topic remains their shared contract.
- Multiple family members can all get alerts (multiple subscribers).
Major section
Common Mistake: Using test.mosquitto.org in Production
The Mistake: A developer builds a prototype using the public MQTT broker test.mosquitto.org, gets excited about how well it works, and deploys a real sensor fleet without changing the broker.
- Third, there is no project-specific reliability guarantee when the public service restarts.
- Together these are deployment boundaries, not limitations that application code can repair.
- Each outcome connects a missing broker control to a concrete product failure.
Major section
Common Mistake: Using test.mosquitto.org in Production (continued)
The consequences follow the same order: an unauthorized subscriber can infer product behavior, another user's retained value can pollute the application's state, and a broker outage can suppress a time-critical greenhouse alert.
- A public broker is useful for learning but provides no project-specific authentication, privacy, or uptime accountability.
- A private broker can be inexpensive to self-host, while making the team responsible for accounts, TLS certificates, patching, and monitoring.
- This progression connects the prototype warning to an explicit operational choice instead of implying that one hosting model fits every product.
Major section
Deep-Dive Note: MQTT Connection Evidence Boundaries
A random client ID can make every reconnect look like a new device, so queued session state is never resumed.
- The client sends CONNECT; the broker replies with CONNACK.
- A duplicated client ID can make two gateways disconnect each other in a loop.
- That record makes later reconnect, duplicate-ID, and offline-presence bugs diagnosable.
Major section
Deep-Dive Note: MQTT Connection Evidence Boundaries (continued)
That first exchange carries the client identifier, clean-start or clean-session intent, keep-alive interval, optional will message, credentials, and the broker's acceptance or refusal result.
- A robust client subscribes again when Session Present = 0, but avoids duplicating subscriptions when the broker says the old session was resumed.
- The client declares the interval in seconds; if it has no other packet to send, it sends PINGREQ and expects PINGRESP.
- Any MQTT control packet sent by the client resets that timer, so a telemetry publisher that sends every 20 seconds does not need separate pings for a 60 second keep-alive.
Major section
Deep-Dive Note: MQTT Connection Evidence Boundaries (continued)
If the broker receives no control packet within 1.5 x keep-alive, it disconnects the client.
- In MQTT 3.1.1 it publishes a configured will; in MQTT 5 a Will Delay Interval can defer or cancel that publication if the session reconnects in time.
- Setting keep-alive to 0 disables this timeout mechanism, which can leave half-dead connections lingering.
- For the first broker smoke test, save one packet trace or broker log containing CONNECT, CONNACK, client ID, clean-start/session-present state, keep-alive value, one accepted publish/subscribe path, and one expected refusal.
Deck summary
Key takeaways
Telemetry means readings and status sent by a remote device.
- Quality of service means the delivery promise chosen for a message; it is called QoS.
- The ESP32 publisher reads the DHT22 sensor and sends a temperature message every 10 seconds.
- Question: You want to build a soil moisture monitor that sends alerts to your phone when plants need watering.
- The Mistake: A developer builds a prototype using the public MQTT broker test.mosquitto.org, gets excited about how well it works, and deploys a real sensor fleet without changing the broker.
Retrieval practice
Recall check 1 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q1In an MQTT-based temperature monitoring system, an ESP32 sensor node reads temperature data and sends it to a broker. A Python dashboard running on a laptop displays the readings. Which statement correctly identifies each component's role?
Show answer
Answer: B The three MQTT roles are publisher (data source), broker (message router), and subscriber (data consumer).
Retrieval practice
Recall check 2 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q2Using this chapter's broker CPU-load formula (CPU% ~ 0.01 x R_out + 0.005 x N_conn), what CPU load does the chapter compute for 10,000 devices publishing 0.1 msg/sec each with 3 subscribers per topic?
Show answer
Answer: A Under the worksheet's assumed coefficients, R_out = 10,000 x 0.1 x 3 = 3,000 msg/sec and modeled CPU% = 0.01x3,000 + 0.005x10,000 = 80%. Benchmark the actual broker before using this estimate for a cluster decision.
Retrieval practice
Recall check 3 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q3This chapter's 'Common Mistake' warning concerns the unauthenticated, plaintext port 1883 listener at test.mosquitto.org. Which of the following is one of its four production dangers?
Show answer
Answer: A The chapter's four dangers of using test.mosquitto.org in production: Zero Authentication, Zero Encryption, No Reliability Guarantee, and Topic Collisions -- each with a stated production consequence.
Retrieval practice
Recall check 4 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q4Complete the MQTT publisher with broker configuration:
Show answer
Answer: A MQTT's default unencrypted port is 1883 (8883 is for TLS).
Q5What opens the MQTT listener that mediates publisher and subscriber exchange?
Show answer
Answer: A Starting the broker opens the MQTT listener that mediates the publisher-to-subscriber exchange.
A. Install broker → start broker → subscribe → publish.
B. Publish → install broker → subscribe.
C. Subscribe → publish → start broker.
D. Start broker → publish → install broker.
Show answer
Answer: A MQTT's default unencrypted port is 1883 (8883 is for TLS).
Show answer
Answer: A Starting the broker opens the MQTT listener that mediates the publisher-to-subscriber exchange.
Retrieval practice
Recall check 5 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q6Per this chapter's Deep-Dive Note, what does the broker do if it receives no control packet from a client within 1.5x the declared keep-alive interval?
Show answer
Answer: A A client-sent control packet resets the keep-alive timer.
Print reference
Answers 1 of 2
Answer key.
- B · The three MQTT roles are publisher (data source), broker (message router), and subscriber (data consumer).
- A · Under the worksheet's assumed coefficients, R_out = 10,000 x 0.1 x 3 = 3,000 msg/sec and modeled CPU% = 0.01x3,000 + 0.005x10,000 = 80%. Benchmark the actual broker before using this estimate for a cluster decision.
- A · The chapter's four dangers of using test.mosquitto.org in production: Zero Authentication, Zero Encryption, No Reliability Guarantee, and Topic Collisions -- each with a stated production consequence.
Print reference
Answers 2 of 2
Answer key.
- A · MQTT's default unencrypted port is 1883 (8883 is for TLS).
- A · Starting the broker opens the MQTT listener that mediates the publisher-to-subscriber exchange.
- A · A client-sent control packet resets the keep-alive timer.