Question

我对mqtt设计很新。

正如我在互联网上的一些教程中看到的，常见的mqtt主题具有以下格式：/ home / room / device_type / device_id

我无法看到这样做的好处。并且不知道如何使用这种设计。

从我的角度来看，设备（dev）可能订阅（sub）来控制主题并发布（pub）到status主题。像这样：

pub：clients / dev / devid / stat
sub：clients / dev / devid / ctrl

通过这种方式，它似乎是sub，pub逻辑对于客户端和设备都非常简单

有人可以告诉我一些设计mqtt主题的好方法吗？

（！）请不要以'/'开头话题（这个是HiveMQ团队推荐的）

编辑：

我只是想到，对于任何类型的设计，模型必须至少可以服务：

单独控制：将控制命令发送到特定设备。
组控制：将控制命令发送到一组设备：type，defined group
能够接收设备的状态。

非常感谢

Answer 1

我发现以下主题拆分方案在多个应用程序中运行良好

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特定的额外信息（例如逗号分隔的键=值对）。好的例子是在客户端实际发送消息时报告消息的时间戳。在“保留”消息的情况下，它可以帮助识别所接收消息的相关性。使用预计很快到达的MQTTv5协议，对这个子主题的需求可能会消失，因为还有其他方式可以传达额外的属性。

希望它有所帮助。

Answer 2

我认为，如果要反映现实世界的话题，我们应该看一下信号K。

编辑：该规范也仍在完善中，但它包括服务器/经纪人的“自我”之类的概念，以及一棵可以从当前船只/房屋开始但可以轻松向上延伸到其他船只/飞机/事物的树。

我的两分钱

所有主题均为只读，除非它们以“ / set”结尾
理想情况下，主题经过合理规范化和细化。我可以理解将值分组为一个分组主题。恕我直言，这种决定应针对特定应用。
有效负载应为字符串，以避免字节顺序问题

这是一棵建议的树：

经纪人=该特定经纪人的信息
- 经纪人/客户
- 经纪人/客户/人数
- 经纪人/客户/ 0 /名称或经纪人/客户[0] /名称
- 经纪人/主题
home =当前位置（也可以是“此处”或其他内容）
- 家庭/厨房/温度“ 19℃”
- 家庭/厨房/温度/硬件/类型“ ESP8266”
- 家庭/车库/主门/设置为“关闭”
位置=所有已知位置的列表
- locations / 0 / uuid
- 位置/ 0 /名称
- 位置/ 0 /地址

Answer 3

我们已经在制造业领域（工业物联网，而不是物联网！）上做了一些工作。

在我们的场景中，有许多不同公司的服务器端应用程序通过MQTT进行通信。因此，我们需要一些整体结构。我们称其为“制造消息栈”。

最底层是MQTT，然后是“消息传递层”。它主要由

组成

基本主题规范
基本有效载荷规范

在消息传递层之上，是域消息传递层，其中覆盖了各种特定于域的主题，例如系统消息，警报，物理设备/数字孪生消息或其他与制造相关的消息。

主题

主题大致定义为<senderapp>/<app-id>/<message-name>/<args>，例如pacman/pacman-1/gameover（这是一个示例，仅供说明！）

发布MQTT消息的应用程序的开发人员根据有效内容的语义定义<message-name>和<args>。

<senderapp>和<app-id>指发送应用程序，并允许从定义的来源（发布者）中快速选择消息。我们将应用程序部署在使用Docker，Rancher-以及之后的Kubernetes构建的微服务环境中。

有效载荷

有效负载以JSON格式指定。每个中都有一个JSON模式参考URL 构建指向发布应用的API的URL，该URL包含已发送消息的更多信息（例如JSON模式）。因此，订户可以按需获取MQTT消息的元数据。静态元数据不与消息一起发送以减小有效负载大小。

有效负载示例：

{
    "$schema": "http://app/api/messages/message1.json",
    "score": 1234,
    "highscore": false
}

发布者的消息元数据

发布应用可保存可通过API发送的所有消息的索引，网址为 http://<app>/api/messages/index.json：

{
    "message1": "message1.json",
    ...
}

每条消息均以其JSON模式message1.json描述：

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "title": "Pacman end of game",
    "properties": {
        "score": {
            "description": "Players score at the end of game",
            "type": "integer"
        },
        ...
    }
}

很遗憾，我们尚未发布制造消息堆栈。计划在未来几个月内发布。欢迎提供反馈。

设计mqtt主题的好方法是什么？

3 个答案: