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?
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.