Topic design patterns for IoT in IOT Protocols - Step-by-Step Execution

Process Flow - Topic design patterns for IoT

Device publishes data

↓

Broker receives message

↓

Broker applies topic pattern

↓

Subscribers receive messages based on topic

↓

Data processed or acted upon

This flow shows how IoT devices send data to a broker, which uses topic design patterns to route messages to subscribers.

Execution Sample

IOT Protocols

Device publishes to topic: home/kitchen/temperature
Subscriber subscribes to: home/+/temperature
Broker routes message to subscriber

A device sends temperature data from the kitchen. The subscriber listens to all rooms' temperature using a wildcard in the topic.

Process Table

Step	Action	Topic Published	Subscriber Topic Filter	Match Result	Message Delivered
1	Device publishes data	home/kitchen/temperature	home/+/temperature	Match	Yes
2	Device publishes data	home/livingroom/humidity	home/+/temperature	No Match	No
3	Device publishes data	home/kitchen/humidity	home/+/humidity	Match	Yes
4	Device publishes data	office/kitchen/temperature	home/+/temperature	No Match	No
5	Device publishes data	home/kitchen/temperature	home/#	Match	Yes

💡 All published messages processed; routing based on topic pattern matching completed.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5
Topic Published		home/kitchen/temperature	home/livingroom/humidity	home/kitchen/humidity	office/kitchen/temperature	home/kitchen/temperature
Subscriber Topic Filter	home/+/temperature	home/+/temperature	home/+/temperature	home/+/humidity	home/+/temperature	home/#
Match Result		Match	No Match	Match	No Match	Match
Message Delivered		Yes	No	Yes	No	Yes

Key Moments - 3 Insights

Why does 'home/livingroom/humidity' not match 'home/+/temperature'?

Because the subscriber's topic filter expects 'temperature' as the last part, but the published topic ends with 'humidity' (see execution_table row 2).

What does the '+' wildcard represent in topic filters?

It matches exactly one level in the topic hierarchy, so 'home/+/temperature' matches any single word between 'home' and 'temperature' (see execution_table rows 1 and 2).

How does the '#' wildcard differ from '+' in topic filters?

'#' matches any number of levels including zero, so 'home/#' matches all topics starting with 'home' regardless of depth (see execution_table row 5).

Visual Quiz - 3 Questions

Look at the execution table, which published topic matches the subscriber filter 'home/+/humidity'?

A office/kitchen/temperature

B home/livingroom/humidity

C home/kitchen/humidity

D home/kitchen/temperature

💡 Hint

Check the 'Subscriber Topic Filter' and 'Match Result' columns in execution_table row 3.

At which step does the message get delivered despite the topic having multiple levels after 'home'?

A Step 5

B Step 2

C Step 4

D Step 3

💡 Hint

Look at the '#' wildcard usage in the subscriber filter in execution_table row 5.

If the subscriber filter changes from 'home/+/temperature' to 'home/kitchen/temperature', which published topics will match?

A All topics with 'temperature' at the end

B Only 'home/kitchen/temperature'

C All topics starting with 'home'

D No topics will match

💡 Hint

Exact topic filters match only identical topics, unlike wildcards (see variable_tracker Subscriber Topic Filter changes).

Concept Snapshot

IoT topic design patterns use hierarchical strings separated by '/' to organize messages.
Wildcards '+' matches one level; '#' matches multiple levels.
Devices publish to topics; subscribers receive messages matching their topic filters.
This pattern enables flexible, scalable message routing in IoT systems.

Full Transcript

In IoT systems, devices send messages to a broker using topics structured like paths with levels separated by slashes. Subscribers listen to topics using filters that can include wildcards: '+' for one level and '#' for multiple levels. The broker matches published topics to subscriber filters and delivers messages accordingly. For example, a device publishing to 'home/kitchen/temperature' matches a subscriber filter 'home/+/temperature' because '+' matches 'kitchen'. However, 'home/livingroom/humidity' does not match 'home/+/temperature' because the last level differs. The '#' wildcard matches all subtopics under a prefix, such as 'home/#' matching any topic starting with 'home'. This design pattern helps organize and route IoT messages efficiently.

Practice

1. What is the main purpose of using topic design patterns in IoT communication?

easy

A. To increase the battery life of sensors

B. To encrypt messages for security

C. To reduce the size of IoT devices

D. To organize messages clearly and make communication scalable

Solution

1. Step 1: Understand the role of topics in IoT

   Topics help organize messages by categorizing them into levels separated by slashes.

2. Step 2: Identify the benefit of good topic design

   Good topic design makes communication clear and scalable, allowing easy message filtering and management.

3. Final Answer:

   To organize messages clearly and make communication scalable -> Option D

4. Quick Check:

   Topic design = Clear, scalable communication [OK]

Hint: Topics organize messages for clarity and scale [OK]

Common Mistakes:

• Confusing topic design with security features
• Thinking topic design affects device hardware
• Assuming topic design saves battery life

2. Which of the following is the correct syntax for a multi-level wildcard subscription in MQTT topics?

easy

A. home/#/temperature/+

B. home/temperature/+/+

C. home/+/temperature/#

D. home/temperature/#/+

Solution

1. Step 1: Recall MQTT wildcard rules

   The plus sign (+) matches one topic level, and the hash (#) matches multiple levels at the end.

2. Step 2: Check syntax correctness

   home/+/temperature/# uses + for one level and # at the end for multiple levels, which is valid syntax.

3. Final Answer:

   home/+/temperature/# -> Option C

4. Quick Check:

   Multi-level wildcard ends with # [OK]

Hint: Use + for single level, # only at end [OK]

Common Mistakes:

• Placing # in the middle of the topic
• Using + to match multiple levels
• Mixing order of + and # incorrectly

3. Given the subscription topic building/+/floor1/#, which published topic will NOT be received by the subscriber?

medium

A. building/roomC/floor2/temperature

B. building/roomB/floor1/humidity

C. building/room/floor1/temperature

D. building/roomA/floor1/temperature

Solution

1. Step 1: Analyze the subscription pattern

   The + matches exactly one level after 'building', and # matches any levels after 'floor1'.

2. Step 2: Test each published topic

   Options A, B, and C match 'building/roomX/floor1/...' correctly. building/roomC/floor2/temperature has 'floor2' instead of 'floor1', so it does not match.

3. Final Answer:

   building/roomC/floor2/temperature -> Option A

4. Quick Check:

   Subscription requires floor1 level [OK]

Hint: Check each topic level matches + and # rules [OK]

Common Mistakes:

• Ignoring the exact match required by + wildcard
• Assuming # matches levels before floor1
• Confusing floor1 and floor2 levels

4. Identify the error in this MQTT subscription topic: home/+/+/temperature/#/humidity

medium

A. The # wildcard is not allowed in the middle of the topic

B. Using multiple + wildcards consecutively is invalid

C. The topic must start with a slash

D. Wildcards cannot be combined with normal topic levels

Solution

1. Step 1: Review MQTT wildcard placement rules

   The # wildcard must be the last character in the topic filter and can only appear once.

2. Step 2: Check the given topic

   The # wildcard appears in the middle before /humidity, which is invalid syntax.

3. Final Answer:

   The # wildcard is not allowed in the middle of the topic -> Option A

4. Quick Check:

   # only at end of topic [OK]

Hint: # wildcard only at topic end [OK]

Common Mistakes:

• Thinking multiple + wildcards are invalid
• Believing topics must start with slash
• Assuming wildcards can't mix with normal levels

5. You want to design MQTT topics to monitor sensors in multiple buildings, floors, and rooms. Which topic pattern best supports scalable subscription to all temperature sensors on floor 2 across all buildings?

hard

A. building/+/+/floor2/temperature

B. building/+/floor2/+/temperature

C. building/#/floor2/temperature

D. building/+/floor2/temperature/#

Solution

1. Step 1: Understand the hierarchy needed

   Topics should include building, floor, room, and sensor type levels.

2. Step 2: Analyze each option for scalability and correctness

   building/+/floor2/+/temperature uses + to match any building and any room on floor2, then temperature sensor, which is clear and scalable. building/#/floor2/temperature misplaces # wildcard. building/+/+/floor2/temperature has extra + before floor2, which breaks hierarchy. building/+/floor2/temperature/# places # after temperature, which is unnecessary and less clear.

3. Final Answer:

   building/+/floor2/+/temperature -> Option B

4. Quick Check:

   Use + for flexible levels, keep clear order [OK]

Hint: Use + for each flexible level, keep order clear [OK]

Common Mistakes:

• Misplacing # wildcard inside topic
• Adding extra + levels breaking hierarchy
• Using # after sensor type unnecessarily