MQTT · Study deck

MQTT Python: Reliable Client Patterns

A Python MQTT program does not run only as a straight script after it connects.

Broker Bex is your guide for this deck.

implpythonpatterns
Broker Bex, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

Trace client callbacks, network work, access, and capacity.

  • Identify the callback and network loop.Explain how incoming messages reach application code.
  • Check client access.Separate transport protection from topic permission.
  • Measure broker capacity.Test connection limits and resource use on the chosen service.
  • Trace a missing message.Compare the publisher topic with the dashboard subscription.
iotclass.org

Major section

Start With the Decision

A Python MQTT program does not run only as a straight script after it connects.

  • MQTT sends device messages through a broker, a service that routes them by topic.
  • A callback is a function the broker client runs when an event occurs.
  • A retry is another attempt after a failed step.
iotclass.org

Major section

In 60 Seconds

A short demo can look healthy even when the network loop, subscription, or repeated delivery state is wrong.

  • 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.
  • Quality of service means the selected delivery level for a message.
iotclass.org

Major section

In 60 Seconds (continued)

QoS is its short name.

  • TLS means protected transport that checks the service identity and can also check the client.
  • This runway does not prove fleet capacity or end-to-end business success.
  • The deeper sections cover callback structure, loop choices, connection limits, secure setup, retry timing, and tests for production clients.
iotclass.org

Major section

Python Implementation Patterns

Protocol methods test each part of a client route.

  • Connect with the selected client identity.
  • Subscribe before expecting a matching message.
  • Publish a known value and check the subscriber.
MQTT client methods connect, subscribe, publish, unsubscribe, and disconnect on one TLS-protected connection, with topic hierarchy shown separately.
Use the protocol methods as implementation checkpoints: connect with credentials, subscribe to the topics your callbacks handle, publish telemetry or commands, unsubscribe when a stream is no longer needed, and disconnect cleanly during shutdown.

Connect with the chosen identity.
Subscribe to the topic your handler expects.
Publish one known value and check the subscriber.
Unsubscribe when the stream is no longer needed; disconnect cleanly.

MQTT client methods connect, subscribe, publish, unsubscribe, and disconnect on one TLS-protected connection, with topic hierarchy shown separately.
iotclass.org

Major section

Putting Numbers to It: loop_forever() vs loop_start() CPU Overhead

Python paho-mqtt provides two loop modes. Loop_forever() runs the network loop in the calling thread, while loop_start() runs it in a background thread.

  • Both wait for socket activity; neither is inherently a busy poll.
  • Elapsed time per loop cycle (illustrative): Tcycle=Twait+Tpacket+Tcallback T_{\text{cycle}} = T_{\text{wait}} + T_{\text{packet}} + T_{\text{callback}} Tcycle​=Twait​+Tpacket​+Tcallback​.
  • For applications that do other work in that thread, use loop_start() or integrate loop() with a disciplined main loop.
iotclass.org

Major section

Checkpoint: Callback and Loop Basics

Keep callback work short while the network loop continues.

  • Assign callbacks before connecting.
  • Run the network loop while messages arrive.
  • Schedule retry work outside the message callback.
Assign callbacks before connecting, then keep a network loop running.
A topic filter ending in the plus sign matches one level. A filter ending in the hash sign covers a branch.
Port 1883 is the plain local path. Production also needs TLS, client identity, and topic permission.
iotclass.org

Major section

Common Misconception: "Public Brokers Are Fine for Production"

The Mistake: Many developers prototype with test.mosquitto.org and then deploy the same code to production, assuming a unique topic name provides adequate security.

  • Production impact: On an open public broker, an outsider can subscribe to door commands and publish a replayed unlock command.
  • Sensor readings, command topics, and status messages can be visible to unrelated subscribers.
  • Blocking only a literal # subscription does not protect messages.
iotclass.org

Major section

Common Misconception: "Public Brokers Are Fine for Production" (continued)

Anyone who can reach the broker may be able to publish fake commands to predictable topics.

  • Retained messages and topic collisions can leak state or mix unrelated test traffic into a real deployment.
  • Developers don't realize: On the unauthenticated test listener, another user can subscribe with +/# to read ordinary application topics and commands.
  • False security: Topic names like myapp/device123/data feel private but are completely visible.
iotclass.org

Major section

Pitfall: Broker Connection Limits Causing Silent Failures

The Mistake: Developers deploy IoT systems without considering broker connection limits.

  • New devices fail to connect with cryptic errors like "connection refused" or timeout, while existing connections work fine.
  • Each TCP connection consumes a socket and broker memory; TLS and queued session state add more.
  • At a configured limit, new connections may be refused or time out, depending on the broker and failure point.
iotclass.org

Major section

Pitfall: TLS Handshake Timeout on Constrained Devices

In the field, slower crypto, Wi-Fi reconnects, network latency, and broker load can push the handshake beyond a default timeout and cause intermittent connection failures.

  • Their CPU and elapsed-time cost varies with hardware, network path and broker load.
  • A timeout copied from a laptop test can be too short after Wi-Fi reconnect and TLS negotiation on the target device.
  • Provision device certificates before deployment when that is part of the authentication design.
iotclass.org

Major section

Worked Example: Debugging "Messages Not Received" Issue

Compare each client subscription with the sensor topic.

  • The terminal probe receives an accepted SUBACK.
  • The dashboard has a different filter.
  • A probe result does not prove dashboard receipt.

Key terms

What this
What this means: The broker can acknowledge QoS 1 reception from the publisher yet deliver to this subscriber at QoS 0.
Sensor published farm/sensor01/moisture: 45%
Terminal probe subscribed to farm/+/moisture: SUBACK accepted
Dashboard subscribed to farm//moisture: no topic match
A probe SUBACK does not prove dashboard receipt.
iotclass.org

Major section

Worked Example: Debugging "Messages Not Received" Issue (continued)

An empty topic level prevents this dashboard match.

  • The sensor publishes under sensor01.
  • The terminal probe uses a plus-level filter.
  • The dashboard filter contains an empty level.
The dashboard says it connected, yet the sensor reading never appears.
The terminal probe subscribed to farm/+/moisture; that SUBACK confirms only the probe.
The dashboard filter farm//moisture has an empty level and does not match sensor01.
iotclass.org

Deck summary

Key takeaways

A Python MQTT program does not run only as a straight script after it connects.

  • A short demo can look healthy even when the network loop, subscription, or repeated delivery state is wrong.
  • QoS is its short name.
  • This section provides practical MQTT patterns for IoT applications using the paho-mqtt library.
  • Python paho-mqtt provides two loop modes. Loop_forever() runs the network loop in the calling thread, while loop_start() runs it in a background thread.
iotclass.org

Retrieval practice

Recall check 1 of 4

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

Q1A Python MQTT client connects but never handles incoming messages. Which setup should the reviewer check first?

ACall the callback by hand once instead of installing a message handler.
BInvoke a startup callback but never register it for later broker sends.
CRegister on_message, subscribe in on_connect, and run the network loop.
DRemove the callback and inspect topic spelling only, without receiving.
Show answer

Answer: C A callback, matching subscription, and running loop are needed to receive publications.

iotclass.org

Retrieval practice

Recall check 2 of 4

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

Q2A Python sensor app must read hardware while MQTT traffic arrives. Which network-loop choice fits?

ARun the MQTT loop only before making the connection to broker.
BRun loop_start() so MQTT traffic uses a background thread.
CRun loop_forever() in the sensor thread and expect sensor reads to run.
DNever run a network loop and assume callbacks still receive traffic.
Show answer

Answer: B The calling thread stays free for sensor work.

iotclass.org

Retrieval practice

Recall check 3 of 4

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

Q3A developer prototypes a smart lock system on the unauthenticated port 1883 listener at test.mosquitto.org and publishes lock/unlock commands to the topic smartlock/device123/command. They plan to ship this to customers. Which statement best explains why this is a critical security risk?

Atest.mosquitto.org has a low bandwidth limit that would cause command delays in production
BAn unauthenticated user can read lock commands with +/# and publish a fake command.
CMQTT cannot secure smart-lock commands because the protocol leaves broker access exposed under any configuration.
DPort 1883 is blocked by most enterprise firewalls, so the devices cannot connect reliably
Show answer

Answer: B The unauthenticated port 1883 listener blocks only a literal # subscription.

iotclass.org

Retrieval practice

Recall check 4 of 4

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

Q4A private broker uses TLS and accepts a device identity. What still limits the device to its own topics?

AA topic ACL bound to device identity, restricting own-topic access.
BTLS alone, which protects transit but grants no per-topic permission.
CA shared password with no topic-specific publishing policy.
DTopic spelling alone, which does not enforce broker authorization.
Show answer

Answer: A TLS protects the link and authentication names the client; an ACL limits its topic actions.

iotclass.org

Print reference

Answers

Answer key.

  1. C · A callback, matching subscription, and running loop are needed to receive publications.
  2. B · The calling thread stays free for sensor work.
  3. B · The unauthenticated port 1883 listener blocks only a literal # subscription.
  4. A · TLS protects the link and authentication names the client; an ACL limits its topic actions.
iotclass.org
A matching subscription, callback, and running loop receive messages. Background looping frees the sensor thread. A public test broker cannot protect production commands. An ACL restricts authenticated devices' topics. Test allowed and denied actions.