Review MQTT patterns in event time

Publish an out-of-order equipment trace and accept, reject, or hold CEP results using event time, source keys, watermarks, sessions, and explicit uncertainty.

Data Dora: I want you to defend each match with event time, one source key, visible uncertainty, and a bounded output., your practice guide

Data Dora: I want you to defend each match with event time, one source key, visible uncertainty, and a bounded output.
Predict the reading, then compare it with the measurement.

Python 3 in your browser (JupyterLite)

Python · no install

Publish an out-of-order equipment trace and accept, reject, or hold CEP results using event time, source keys, watermarks, sessions, and explicit uncertainty.

Tier 2 · Web · paste-in setup · No account

Version tested: 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. Date: 2026-09-09.

Open the notebook in your browser and run each Python cell; no install or account is needed.

Three ways to run: use JupyterLite here with no install; run main.py locally from the downloadable lab folder; or open the same notebook in Google Colab.

Open in your browser (new tab)

Steps

Screens captured against JupyterLite Python 3.12.7 / Pyodide 0.27.6; Chromium 148.0.7778.96 on 2026-09-10; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    Run `python3 main.py --step 1` and read the event contract before correlating the trace.
    You will see
    The `CEP event contract` table shows `key equipment ID`, `event_second source event time`, and the three accepted event kinds.
    Why it matters
    The visible contract establishes the correlation key, clock, and vocabulary before the learner interprets any sequence.

  2. Step 2

    Do
    Run `python3 main.py --step 2` online to publish the fictional trace to the random public-broker topic.
    You will see
    Three `topic payload` lines arrive as e2, e1, e3, followed by `Notice: e2 arrived before the earlier event-time record e1.`
    Why it matters
    The broker-delivered JSON makes arrival order directly observable and exposes why event-time reordering is required.

  3. Step 3

    Do
    Run `python3 main.py --step 3` to reorder the same trace by event time and evaluate the three-event pattern.
    You will see
    The event-time table shows e1 at 10, e2 at 20, and e3 at 28, then prints `Window: [10, 40]; observed gap is 18 seconds.`
    Why it matters
    The ordered rows, explicit 30-second rule, and window let the learner reproduce the MATCH decision from the inputs.

  4. Step 4

    Do
    Run `python3 main.py --step 4` to replace the completion event with an otherwise identical event from conveyor-8.
    You will see
    The trace places the e1/e2 partial state on conveyor-7 beside `completion: e3@conveyor-8` and says `Decision: reject e3`.
    Why it matters
    Showing both keys beside the same-key rule explains why completion is rejected while the original partial state remains isolated.

  5. Step 5

    Do
    Run `python3 main.py --step 5` to compare event e1 at 10 seconds with a 25-second watermark and 20 seconds of allowed lateness.
    You will see
    The decision table shows watermark 25, e1 at 10, lateness 15, and allowed lateness 20 before the final `decision=REORDER`.
    Why it matters
    Laying out the subtraction and bound makes the latency-versus-completeness policy checkable rather than implicit.

  6. Step 6

    Do
    Run `python3 main.py --step 6` to group event times 0, 5, 12, and 40 seconds with a 15-second inactivity gap.
    You will see
    The output lists `session 1: 0, 5, 12` and `session 2: 40`, then computes `First session closes at 12 + 15 = 27 seconds.`
    Why it matters
    The grouped members and closure arithmetic expose how the 15-second inactivity rule creates two sessions.

  7. Step 7

    Do
    Run `python3 main.py --step 7` to compare an anomaly score of 4.2 with the review threshold.
    You will see
    The metric table places score 4.2 over threshold 3.0, then says the score requests review but does not prove cause.
    Why it matters
    Showing the value, threshold, interpretation rule, and bounded inspection action prevents anomaly evidence from becoming an unsupported causal claim.

  8. Step 8

    Do
    Run `python3 main.py --step 8` to evaluate a gate with true vibration and current conditions but an unknown stop condition.
    You will see
    The condition table shows vibration TRUE, current TRUE, and stop UNKNOWN before `Rule: PASS only when all three conditions are TRUE.`
    Why it matters
    The three rows make the missing state explicit and justify HOLD without silently converting uncertainty into pass or failure.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A sensor event has a valid source identity but an unknown schema version. What is the strongest first pipeline response?

    Return to the chapter’s knowledge check

  2. After a processor restart, replayed events produce duplicate alerts for the same equipment event. Which part of the pipeline review should be investigated first?

    Return to the chapter’s knowledge check

  3. A dashboard value is published as final, then changes after older event-time records arrive. What is the strongest first review response?

    Return to the chapter’s knowledge check

Return to Building IoT Streaming Pipelines · Browse Labs