问题描述
我对 mqtt 设计很陌生.
I am very new with mqtt design.
我从网上的一些教程中看到，常见的 mqtt 主题格式如下:/home/room/device_type/device_id
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.
在我看来，设备 (dev) 可能订阅 (sub) 以控制主题并发布 (pub) 到状态主题.像这样:
From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this:
- 发布:clients/dev/devid/stat
- 子:clients/dev/devid/ctrl
这样看来，sub,pub 逻辑对于客户端和设备来说都非常简单
In this way, it seems sub,pub logic is very simple for both clients and devices
有人可以告诉我一些设计 mqtt 主题的好方法吗?
Could someone please tell me some good way to design mqtt topic ?
(!) 请不要以/"开头(HiveMQ 团队推荐了这个)
(!) Please do not start topic with '/' (This one has been recommended by HiveMQ Team)
我刚刚发现，对于任何类型的设计，模型必须至少可以服务:
I just figured out that for whatever kind of design, the model must serve-able at least:
- 单独控制:向特定设备发送控制命令.
- 组控制:向一组设备发送控制命令:类型，定义组
- 能够接收设备的状态.
非常感谢
推荐答案
我发现以下主题拆分方案在多个应用程序中效果很好
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 用于区分可以同时使用的不同协议/应用程序
- src_id 是发布消息的 mqtt 客户端的 ID.它应该与用于连接到 MQTT 代理的客户端 ID"相同.它允许快速 ACL 控制以检查是否允许客户端发布特定主题.
- dest_id 是目标"单元的客户端 ID，即消息的目的地.还允许对代理进行快速 ACL 控制，以确定是否允许客户端订阅特定主题.可以保留目的地"字符串，以指定将消息广播给任何感兴趣的人.例如所有.
- message_id 是所用协议中消息的实际 ID.我通常使用数值(当然是字符串)，因为连接到 MQTT 代理的 IOT 或其他嵌入式系统可以有其他 I/O 链接，我想使用相同的协议(但具有不同的传输帧)来控制使用这些其他 I/O 链接的设备.我通常在此类通信链接中使用数字消息 ID.
- extra_properties 是一个可选的子主题，可用于传达其他 MQTT 特定的额外信息(例如，逗号分隔的 key=value 对).一个很好的例子是在客户端实际发送消息时报告消息的时间戳.在保留"消息的情况下，它可以帮助识别接收到的消息的相关性.随着 MQTTv5 协议有望很快到来，对这个子主题的需求可能会消失，因为会有其他方式来传达额外的属性.
- 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.
希望有帮助.
这篇关于设计mqtt主题的好方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！