MQTT · Study deck
MQTT Python: Reconnect and Backoff Timing
A broker passes MQTT messages from senders to listeners.
Broker Bex is your guide for this deck.
Route overview
Learning objectives
Calculate capped delays, then test what reconnect actually restores.
- Compute an exponential wait and apply a cap.
- Explain why jitter needs independent client waits.
- The ESP32 callback, loop, and subscription form the receive path.
- Save evidence from failure through received message.
Worked example
A reconnect storm starts with one failure
Synchronized retries can add load while a broker is recovering.
- One lost link triggers a device retry.
- Devices running the same schedule can retry together.
- Record the failure, chosen wait, next attempt, and result.
Worked example
Calculate a capped retry schedule
Apply the cap after exponential growth and before the wait.
- Attempt 1: raw 2 seconds; wait 2 seconds.
- Attempt 2: raw 4 seconds; wait 4 seconds.
- Attempt 3: raw 8 seconds; wait 5 seconds.
- Cap: 5 seconds; first three waits total 11 seconds.
Concept
Jitter spreads the next attempt
A deterministic example is not evidence of fleet-wide randomness.
- Exponential delay → cap → illustrative variation.
- The chapter visualizer follows a fixed calculation.
- A fleet test must choose and log independent client waits, then measure their spread.
Worked example
ESP32 callback and network loop
The sample attempts a publish even after reconnect attempts fail.
setCallbackruns beforeloop.client.loop()processes input and dispatches callbacks.- The teaching code attempts status publish every roughly 5 seconds without checking connection.
- Verify broker receipt separately.
Worked example
Reconnect after Wi-Fi or broker loss
This sample retries in groups; five failures do not end retries.
- One reconnect call makes five attempts.
- Failed waits are 2, 4, 8, 16, and 32 seconds.
- A later main-loop pass may start another call.
- No cap or jitter; subscription follows successful connection.
Concept
Protect the broker connection
Transport, identity, and topic permission answer separate questions.
- TLS protects the network connection.
- Authentication identifies the client.
- Topic access rules restrict publish and subscribe actions.
- Measure handshake time on the target device.
Worked example
Debug the message route
Use the existing architecture figure as a route map, then inspect each boundary.
Publisher reached broker?
Topic matched filter?
Broker forwarded the message?
Subscriber callback ran?
Check connection: Serial Monitor shows Wi-Fi and MQTT connection status
Verify message flow: MQTT Explorer shows all broker traffic
Validate topics: mosquitto_sub confirms messages reach the broker
Test payloads: Ensure JSON is valid and decodable
Concept
Capacity and battery are separate budgets
Broker connection work and device energy require different measurements.
- Broker: connections, memory, queued state, and retry load.
- Device: wake-ups, radio use, and measured energy.
- A loop API choice alone does not establish power savings.
Common misconception
Delivery evidence is not action evidence
An acknowledgement proves only its named protocol exchange.
- MQTT acknowledgement → named protocol hop only.
- Application receipt → logged processing.
- Device state report → claimed outcome to verify against the request.
Quick check · choose before the reveal
Recall check: third retry delay
The retry schedule doubles from two seconds and caps each wait at five. What is the third delay before jitter?
Reveal answer
Answer: C. The raw third delay is eight seconds; the cap makes the actual wait five seconds before jitter.
Recap
Key takeaways and test record
A retry schedule stays theoretical until tested with a device and broker.
- Record failure reason, wait, attempt, and broker acceptance.
- Confirm restored subscription and one received publication.
- For commands, record device state feedback separately.
Quick check · choose before the reveal
Recall check: what should the callback do?
A disconnected client has a callback, a network loop, and a retry policy. Which part should decide the next wait?
Reveal answer
Answer: B. Keep the callback short; the reconnect policy should record the reason and schedule the next attempt.