Build a live MQTT sensor dashboard

Steps

Screens captured against Python 3 in your browser (JupyterLite) Python 3.12.7 / Pyodide 0.27.6 in JupyterLite 0.6.4; Chromium 148.0.7778.96; captured against a local Mosquitto-compatible WebSocket broker because the capture host cannot reach the public broker; the notebook targets test.mosquitto.org; captureSource playwright:jupyterlite on 2026-09-10; the tool may have moved on — the text steps are the contract.

1. 1 Step 1

   Do

   In the JupyterLite notebook, run the Step 1 cell to connect a subscriber to the one-level sensor wildcard on a unique topic tree.

   You will see

   The terminal names test.mosquitto.org:1883, the run-specific publish root, the /+ subscription, and the rule that + matches exactly one sensor name.

   Why it matters

   A bounded wildcard lets one dashboard consume several sensors without accidentally subscribing to the whole public broker.

2. 2 Step 2

   Do

   In the JupyterLite notebook, run the Step 2 cell to publish seven fictional readings and inspect them in the subscriber callback.

   You will see

   A seven-row table shows sensor, sequence, temperature, QoS, and observation time, followed by Every row above came back through the public broker callback.

   Why it matters

   The received callback rows prove a broker round trip; printing only the publisher's inputs would not prove subscription behavior.

3. 3 Step 3

   Do

   In the JupyterLite notebook, run the Step 3 cell to compare valid JSON readings with one deliberately malformed payload.

   You will see

   The validation ledger reports seven accepted messages and one rejected freezer-b payload, not-json, beside the required numeric-field rule.

   Why it matters

   Transport receipt and application acceptance are separate decisions; invalid payloads must not enter the dashboard history.

4. 4 Step 4

   Do

   In the JupyterLite notebook, run the Step 4 cell to render the latest accepted value for every sensor.

   You will see

   The dashboard table shows three sensors with latest temperature, sequence, timestamp, and state, followed by the total valid-message count.

   Why it matters

   Keeping ingestion history separate from presentation makes the callback small and lets the view be rebuilt from accepted state.

5. 5 Step 5

   Do

   In the JupyterLite notebook, run the Step 5 cell to display each sensor's last three accepted readings.

   You will see

   Three compact history rows show seq:value, while the explanation identifies a three-value FIFO window and the next eviction direction.

   Why it matters

   A fixed-length deque bounds memory while preserving enough recent context to see movement rather than one isolated number.

6. 6 Step 6

   Do

   In the JupyterLite notebook, run the Step 6 cell to evaluate role-specific alert thresholds against the latest values.

   You will see

   The table places each latest value beside either the freezer rule value > -17.0 or the packing rule value > 22.0; all three decisions are ALERT.

   Why it matters

   A temperature number has meaning only with its sensor role and rule, so one universal threshold would be misleading.

7. 7 Step 7

   Do

   In the JupyterLite notebook, run the Step 7 cell to reconcile callback, QoS, validation, and shutdown counts.

   You will see

   The summary accounts for eight callbacks, their QoS levels, seven valid rows, one malformed row, and a clean disconnect, then warns that receipt does not approve a public broker for production commands.

   Why it matters

   Count reconciliation detects silent gaps, while the scope warning keeps a successful teaching round trip separate from production security approval.