Good way to design mqtt topic?

Question

I am very new with mqtt design.

As I see from some tutorials in the internet, common mqtt topic has this format: /home/room/device_type/device_id

I could not see the benefit to do that. And have no idea how to use this kind of design.

From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this:

• pub: clients/dev/devid/stat
• sub: clients/dev/devid/ctrl

In this way, it seems sub,pub logic is very simple for both clients and devices

Could someone please tell me some good way to design mqtt topic ?

(!) Please do not start topic with '/' (This one has been recommended by HiveMQ Team)

EDIT:

I just figured out that for whatever kind of design, the model must serve-able at least:

1. Individual control: send control command to a particular device.
2. Group control: send control command to a group of devices: type, defined group
3. Able to recieve the status of device.

Thank you very much

Answer 1

I found that the following topic split scheme works very well in multiple applications

protocol_prefix / src_id / dest_id / message_id / extra_properties

• protocol_prefix is used to differentiate between different protocols / application that can be used at the same time
• src_id is the ID of the mqtt client that publishes the message. It is expected to be the same as "client ID" used to connect to MQTT broker. It allows quick ACL control to check whether the client is allowed to publish specific topic.
• dest_id is client ID of the "destination" unit, i.e. to whom the message is intended. Also allows quick ACL control on the broker of whether client is allowed to subscribe to a particular topic. There can be reserved "destination" strings to specify that the message is broadcasted to anyone who is interested. For example all.
• message_id is actual ID of the message within used protocol. I usually use numeric value (as string of course), because the IOT or other embedded system that is connected to MQTT broker can have other I/O links and I would like to use the same protocol (but with different transport framing) to control the device using these other I/O links. I usually use numeric message IDs in such communication links.
• extra_properties is an optional subtopic which can be used to communicate other MQTT specific extra information (comma separated key=value pairs for example). Good example would be reporting timestamp of the message when it was actually sent by the client. In case of "retained" messages it can help to identify the relevance of the received message. With MQTTv5 protocol that is expected to arrive soon, the need for this subtopic may disappear because there will be other way to communicate extra properties.

Hope it helps.