Step 2: Test Pub/Sub from Terminal

Before building the Python simulator, let’s test MQTT manually. This helps you understand how publish/subscribe works.

Install Mosquitto Clients (if needed)

If you don’t have mosquitto_pub and mosquitto_sub, install them:

macOS:

brew install mosquitto

Linux (Ubuntu/Debian):

sudo apt-get install mosquitto-clients

Or use Docker:

docker run -it --rm --network host eclipse-mosquitto:2.0 sh

Test 1: Subscribe to a Topic

Open a terminal and subscribe to a test topic:

mosquitto_sub -h localhost -p 1883 -t test/hello

This command:

• -h localhost: Connect to broker on localhost
• -p 1883: Use port 1883 (standard MQTT)
• -t test/hello: Subscribe to topic test/hello

The terminal will wait for messages. Leave it running.

Test 2: Publish a Message

Open a second terminal and publish a message:

mosquitto_pub -h localhost -p 1883 -t test/hello -m "Hello from terminal!"

You should see Hello from terminal! appear in the first terminal (the subscriber).

Test 3: Multiple Subscribers

Open a third terminal and subscribe to the same topic:

mosquitto_sub -h localhost -p 1883 -t test/hello

Now publish again from the second terminal:

mosquitto_pub -h localhost -p 1883 -t test/hello -m "Broadcast message"

Both subscribers should receive the message. This demonstrates the pub/sub pattern: one publisher, multiple subscribers.

Test 4: Topic Wildcards

MQTT supports wildcards for subscribing to multiple topics:

Single-level wildcard (+):

# Subscribe to all topics under "sensors"
mosquitto_sub -h localhost -p 1883 -t sensors/+/temperature

This matches:

• sensors/room1/temperature ✅
• sensors/room2/temperature ✅
• sensors/room1/humidity ❌ (different last level)

Multi-level wildcard (#):

# Subscribe to everything under "sensors"
mosquitto_sub -h localhost -p 1883 -t sensors/#

This matches:

• sensors/room1/temperature ✅
• sensors/room1/humidity ✅
• sensors/building1/room2/temperature ✅

Test 5: Retained Messages

Publish a message with the -r (retained) flag:

mosquitto_pub -h localhost -p 1883 -t test/retained -m "Last known value" -r

Now subscribe to the topic:

mosquitto_sub -h localhost -p 1883 -t test/retained

You’ll immediately receive Last known value even though it was published before you subscribed. This is useful for device state.

Test 6: JSON Payload

Publish a JSON message (like we’ll do in the simulator):

mosquitto_pub -h localhost -p 1883 -t test/json -m '{"deviceId":"sensor-01","temperature":23.5,"timestamp":"2025-12-16T10:00:00Z"}'

Subscribe to see it:

mosquitto_sub -h localhost -p 1883 -t test/json

Visualizing the Flow

Here’s what happens when you publish and subscribe:

Key Takeaways

1. Topics are strings

• Hierarchical structure with / separators
• Case-sensitive
• No wildcards in topic names (only in subscriptions)

2. One publish, many subscribers

• Publisher doesn’t know who’s listening
• Broker routes to all subscribers
• Perfect for IoT where multiple systems need the same data

3. Retained messages

• Last message stored on topic
• New subscribers get it immediately
• Useful for device state

4. Wildcards

• + matches one level
• # matches multiple levels
• Only in subscriptions, not in publishes

Checkpoint ✅

You should be able to:

• ✅ Subscribe to a topic and see messages
• ✅ Publish messages from another terminal
• ✅ See multiple subscribers receive the same message
• ✅ Understand topic wildcards
• ✅ Use retained messages

What’s Next?

In the next page, you’ll design a message schema for your IoT telemetry. This ensures all your messages have a consistent structure that’s easy to process.