Topics and topic hierarchy in IOT Protocols - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding MQTT Topic Hierarchy

In MQTT, topics are structured in a hierarchy separated by slashes. Which of the following represents a valid topic hierarchy for a smart home system?

A home.livingroom.temperature

B home/livingroom/temperature

C home\livingroom\temperature

D home-livingroom-temperature

💡 Hint

Think about how MQTT topics use slashes to separate levels.

MQTT topics use forward slashes '/' to separate levels in the hierarchy. Backslashes, dots, or dashes are not valid separators.

💻 Command Output

intermediate

MQTT Topic Subscription Wildcards Output

What topics will a client receive if it subscribes to home/+/temperature?

A home/livingroom/temperature and home/kitchen/temperature

B home/livingroom/temperature only

C home/livingroom/humidity and home/kitchen/temperature

D home/livingroom/temperature and home/livingroom/humidity

💡 Hint

The '+' wildcard matches exactly one level in the topic hierarchy.

The '+' wildcard matches exactly one level, so home/+/temperature matches topics like home/livingroom/temperature and home/kitchen/temperature, but not home/livingroom/humidity.

❓ Configuration

advanced

Configuring MQTT Broker Topic Access Control

You want to restrict clients so they can only publish to topics under devices/ and subscribe to topics under sensors/. Which configuration snippet correctly enforces this in a typical MQTT broker ACL file?

A

user client
publish devices/
subscribe sensors/

B

user client
publish sensors/#
subscribe devices/#

C

user client
publish #
subscribe #

D

user client
publish devices/#
subscribe sensors/#

💡 Hint

Remember that '#' matches all subtopics and the ACL syntax requires specifying publish and subscribe permissions.

The ACL line publish devices/# allows publishing to all topics starting with devices/. Similarly, subscribe sensors/# allows subscribing to all topics under sensors/. Other options either reverse permissions or use incorrect syntax.

❓ Troubleshoot

advanced

Troubleshooting MQTT Topic Subscription Failure

A client subscribes to home/+/temperature but does not receive messages published to home/livingroom/humidity. What is the most likely cause?

A The client is publishing to <code>home/livingroom/humidity</code> instead of <code>home/livingroom/temperature</code>

B The MQTT broker does not support the '+' wildcard

C The client subscribed to <code>home/#</code> instead of <code>home/+/temperature</code>

D The client subscribed with QoS 0 but messages are published with QoS 2

💡 Hint

Check if the published topic matches the subscribed topic pattern exactly.

The subscription home/+/temperature matches topics with exactly three levels where the last is 'temperature'. Publishing to home/livingroom/humidity will not match and thus no messages are received.

🔀 Workflow

expert

Designing a Topic Hierarchy for Scalable IoT Deployment

You are designing an MQTT topic hierarchy for a city-wide sensor network with multiple sensor types in many locations. Which topic hierarchy design best supports easy filtering by location and sensor type?

A sensor_type/city/location/sensor_id

B city/sensor_type/location/sensor_id

C city/location/sensor_type/sensor_id

D sensor_id/city/location/sensor_type

💡 Hint

Consider which topic levels you want to filter on first when subscribing.

Placing location before sensor_type allows subscribers to filter all sensors in a location easily, or filter by sensor type within a location. This is more intuitive for city-wide deployments.