MQTT Pub/Sub Animation

Interactive Visualization of Publish-Subscribe Messaging

animation
mqtt
protocols
In 60 Seconds

MQTT’s publish-subscribe pattern decouples message senders (publishers) from receivers (subscribers) through a central broker. Publishers send messages to named topics, and the broker delivers those messages to all clients subscribed to matching topics, supporting wildcards like + (single level) and # (multi-level) for flexible topic filtering.

MQTT Publish-Subscribe Flow

This interactive animation demonstrates how MQTT’s publish-subscribe pattern works. Watch messages flow from publishers through the broker to subscribers based on topic matching.

Animation Overview

This animation shows the core MQTT concepts:

  • Publishers (left): Sensors that send data to topics
  • Broker (center): Routes messages based on topic patterns
  • Subscribers (right): Apps that receive messages matching their subscriptions
  • Topic Wildcards: # matches all levels, + matches one level
How to Use This Animation
  1. Click “Publish Message” buttons on the left to send messages
  2. Watch the message travel through the broker
  3. See which subscribers receive it based on their topic subscriptions
  4. Try different message types to understand topic routing

Topic Subscription Reference

The animation above demonstrates topic-based routing. Here’s what each subscriber receives:

Subscriber Subscribed Topics Receives From
📱 Phone App home/# ALL sensors (wildcard # matches everything)
🌡️ Thermostat home/+/temperature Temperature sensor only (+ matches single level)
🔒 Security Hub home/garage/motion, home/frontdoor/status Motion + Door sensors (exact match)
📊 Data Logger home/livingroom/# Temperature sensor only (living room subtree)
MQTT Wildcard Patterns
  • # (Multi-level): Matches zero or more topic levels. home/# matches home/kitchen/temperature, home/garage/motion/sensor1, etc.
  • + (Single-level): Matches exactly one topic level. home/+/temperature matches home/kitchen/temperature but NOT home/kitchen/sensor/temperature

What This Animation Demonstrates

  1. Decoupling: Publishers don’t know (or care) who receives their messages
  2. Topic Routing: The broker routes messages based on topic patterns
  3. Wildcard Subscriptions: # and + wildcards enable flexible subscriptions
  4. Fan-out: One message can reach multiple subscribers simultaneously
  5. Selective Delivery: Subscribers only receive messages matching their topics

Technical Implementation Notes

This animation uses:

  • Observable JavaScript (OJS): Native to Quarto, reactive programming model
  • D3.js: SVG manipulation and smooth transitions
  • CSS-in-JS: Inline styles for portability
  • IEEE Color Palette: Consistent with book styling (#2C3E50, #16A085, #E67E22)

The animation is self-contained—no external dependencies beyond D3.js (included with Quarto).

Try These Scenarios
  1. Click Temperature Sensor → Watch the Phone App AND Thermostat AND Data Logger all light up
  2. Click Motion Sensor → Only Phone App and Security Hub receive it
  3. Click Door Sensor → Only Phone App and Security Hub receive it

Notice how the Phone App always receives messages (it subscribed to home/#), while other subscribers are more selective.

What’s Next

Common Pitfalls

Pitfall 1: Using Wildcards in PUBLISH Operations Wildcards (# and +) are only valid in SUBSCRIBE operations. Publishing to home/+/temperature does not work - you must publish to a specific topic like home/livingroom/temperature. The broker will reject wildcard characters in publish topic names.

Pitfall 2: Creating Overly Deep or Flat Topic Hierarchies Topics like a/b/c/d/e/f/g/h/sensor/temp waste bandwidth and are hard to manage. Conversely, flat topics like sensor1_temp_livingroom prevent wildcard subscriptions. Aim for 3-5 levels that balance structure with practicality: building/zone/device/metric.

Pitfall 3: Starting Topics with / (Leading Slash) A topic like /home/temp is valid but creates an empty first level. This means home/# will NOT match /home/temp because they have different structures. Either always use leading slashes or never use them - be consistent.

Pitfall 4: Forgetting That Subscription is Stateful Once subscribed, a client continues receiving messages until it unsubscribes or disconnects. Subscribing multiple times to the same topic (e.g., in a reconnection loop without checking) can cause duplicate message delivery or exceed broker subscription limits.

Key Takeaways
  • Publishers and subscribers are fully decoupled: Sensors publish to topics without knowing who receives messages, and apps subscribe without knowing which devices exist - the broker handles all routing.
  • Topic wildcards enable flexible subscriptions: Use # to match any number of levels (e.g., home/# receives all home messages) or + to match exactly one level (e.g., home/+/temperature).
  • One publish can reach many subscribers: The broker duplicates messages to all matching subscriptions, enabling efficient fan-out from a single sensor to multiple applications.
  • Topic hierarchy design is critical: A well-structured topic tree (e.g., building/floor/room/sensor/type) enables both fine-grained and broad subscriptions while keeping the namespace organized.

This animation is implemented in approximately 300 lines of Observable JavaScript. Key techniques:

  1. SVG-based graphics: Scalable, accessible, print-friendly
  2. D3 transitions: Smooth easing with d3.easeQuadInOut
  3. Reactive state: OJS mutable variables for message queue
  4. Topic matching: JavaScript implementation of MQTT wildcard patterns

To reuse this pattern for other protocols (CoAP, AMQP, etc.), the core animation engine can be abstracted into a reusable component.