An MQTT topic is a named channel that acts as a message’s routing address. A publisher sends a message to a topic without knowing its recipients; a subscriber receives messages from topics it has selected without knowing their publishers. The broker handles that routing, so sensors and consumers need not connect to each other directly. section 3.3.4
Design topic names as a hierarchy that reflects what is being sensed and where. In a home digital twin, names such as `home/environment/bedroom1/temp_sensor_1` distinguish sensor streams. A useful hierarchy supports selective subscriptions with MQTT wildcards and leaves room for more sensors. The topic identifies the stream; it does not decode the message payload. section 3.3.4 section 3.5.2
home/electricity/electricitymeter/power_meter_1 home/electricity/washingmachine/power_meter_2 home/electricity/refrigerator/power_meter_3 home/water/washingmachine/power_meter_4 home/water/washingmachine/flow_meter_1 home/water/garden/flow_meter_2 home/environment/bedroom1/temp_sensor_1 home/environment/bedroom2/temp_sensor_2 home/environment/outdoors/temp_sensor_3 home/environment/indoors/moisture_temp_sensor_1
The example names group streams under home, then by measurement area, asset or location, and sensor. Compare the electricity and water meters on the washing machine: their names keep the two streams distinct. section 3.3.4
Route first, decode second
A bedroom temperature sensor publishes a Base64-encoded payload on `home/environment/bedroom1/temp_sensor_1`. A decoder subscribed to sensor topics receives the message, then interprets its bytes as measurements. Subscription selects which messages arrive; decoding determines what their payloads mean. section 3.5.2
