边缘端MQTT Broker提供给开发者使用的Topic列表如下:
功能描述 | Topic | 类型 | 说明 |
---|---|---|---|
订阅所有子设备数据上报消息 | $sys/+/+/thing/property/post | Subscribe | 使用通配符进行订阅,实际接收到的报文里topic会包含具体的pid和devkey |
推送子设备数据 | $sys/{pid}/{devkey}/thing/property/post | Publish | pid和devkey分别为具体某个子设备的产品ID和设备ID |
订阅所有子设备命令下发消息 | 写命令:$sys/+/+/thing/property/set 读命令:$sys/+/+/thing/property/get |
Subscribe | 使用通配符进行订阅,实际接收到的报文里topic会包含具体的pid和devkey |
给指定子设备下发命令 | 写命令:$sys/{pid}/{devkey}/thing/property/set 读命令:$sys/{pid}/{devkey}/thing/property/get |
Publish | pid和devkey分别为具体某个子设备的产品ID和设备ID |
订阅所有子设备命令响应消息 | 写命令:$sys/+/+/thing/property/set_reply 读命令:$sys/+/+/thing/property/get_reply |
Subscribe | 使用通配符进行订阅,实际接收到的报文里topic会包含具体的pid和devkey |
推送子设备命令响应 | 写命令:$sys/{pid}/{devkey}/thing/property/set_reply 读命令:$sys/{pid}/{devkey}/thing/property/get_reply |
Publish | pid和devkey分别为具体某个子设备的产品ID和设备ID |
订阅所有子设备上下线状态消息 | gateway/report/status/pid/+/devkey/+ | Subscribe | 实际报文topic中通配符对应的两个值分配为边缘节点的产品ID和设备ID,注意和其他topic区分 |
模拟子设备上下线 | gateway/report/status/pid/{pid}/devkey/{devkey} | Publish | pid和devkey分别为边缘节点的产品ID和设备ID,注意和其他topic区分 |
订阅校验通过后的结构化设备数据 | inner/data/parse/pid/+/devkey/+ | Subscribe | 所有的子设备数据都会经过物模型校验,校验通过的原始数据会转换为结构化数据并推送至该topic |
该topic可以让开发者订阅当前边缘节点所有子设备上报的数据点,也可以模拟一个子设备去上报数据点。订阅的时候使用通配符即可订阅所有的设备数据,也可以指定子设备产品ID和设备ID订阅具体某一个子设备的数据。推送数据则必须要指定子设备的产品ID和设备ID,因为边缘节点服务需要根据topic里的这两个字段来判断是哪个设备推送的数据。其他topic的通配符规则和该topic一致,下文就不一一赘述。
sub $sys/+/+/thing/property/post
pub $sys/{pid}/{devkey}/thing/property/post
设备上报数据格式需要严格按照平台定义的规范,详细的数据格式可以参考MQTT设备开发指南中的协议规范。
该Topic可以让开发者订阅当前所有发向子设备的命令,也可以主动向一个子设备发送一条命令。
sub $sys/+/+/thing/property/set
sub $sys/+/+/thing/property/get
pub $sys/{pid}/{devkey}/thing/property/set
pub $sys/{pid}/{devkey}/thing/property/get
命令下发的数据格式需要严格按照平台定义的规范,详细的数据格式可以参考MQTT设备开发指南中的协议规范。
该Topic可以让开发者订阅当前所有子设备命令响应的消息,也可以主动推一条数据响应某个命令。
sub $sys/+/+/thing/property/set_reply
sub $sys/+/+/thing/property/get_reply
pub $sys/{pid}/{devkey}/thing/property/set_reply
pub $sys/{pid}/{devkey}/thing/property/get_reply
命令响应的数据格式需要严格按照平台定义的规范,详细的数据格式可以参考MQTT设备开发指南中的协议规范。
如果开发者需要开发一个应用来模拟子设备,使用管理员账号连接MQTT Broker并不会让该子设备上线,子设备不上线也就无法使用平台的命令下发等功能,可以通过向该topic推送相应的状态变更消息来实现子设备的上下线操作。同样,也可以通过该topic订阅当前所有子设备上下线消息。
注:Topic里{pid}和{devkey}分别对应边缘节点的产品ID和节点ID,而不是子设备的,需要和其他topic区分。
sub gateway/report/status/pid/+/devkey/+
pub gateway/report/status/pid/{pid}/devkey/{devkey}
MQTT payload为Event结构对应json串的字节数组。
Event:
{
"eventType": int8, // 事件类型:1-上线,2-下线,3-保活
"deviceIds": []string, // 子设备ID数组
"deviceInfos": []DeviceInfo // 子设备详细信息
}
DeviceInfo:
{
"deviceId": string, // 子设备ID
"productId": string // 子设备产品ID
}
示例
设备ID为10011347的子设备保活消息格式:
{
"eventType":3,
"deviceIds":[
"10011347"
],
"deviceInfos":[
{
"deviceId":"10011347",
"productId":"100129"
}
]
}
注:平台有MQTT子设备的保活机制,如果一个边缘节点在默认2分钟内没有上报子设备的在线状态,则子设备会被平台标志为离线,因此,应用需要实现定时上报状态的逻辑。
设备上报的原始数据会由边缘节点内置的模块进行解析、物模型校验,过滤掉不合法的数据,最终将合法的数据转换成统一的结构化数据格式,通过该topic推送出去。对于大部分的应用开发者来说,并不需要订阅上文提到的子设备数据上报topic且自己去解析原始数据,只需要接收该topic的数据,然后编写自己的计算处理逻辑即可。
sub inner/data/parse/pid/+/devkey/+
MQTT payload为DataEvent数组([]DataEvent)结构对应json串的字节数组。
DataEvent:
{
"eventId": string, // 事件ID,唯一UUID
"deviceId": string, // 子设备ID
"productId": string, // 子设备产品ID
"name": string, // 属性名
"value": interface, // 属性值
"type": int, // 属性类型
"created": int64 // 事件生成时间戳,单位ms
}
示例
设备ID为10011347的子设备推送的temperature和switch属性:
[
{
"eventId":"223197a5-e0c6-4c6c-8f33-9d85c2e7f207",
"deviceId":"10011347",
"productId":"100129",
"name":"temperature",
"value":22.4,
"type": 5,
"created":1588065644340
},
{
"eventId":"223197a5-e0c6-4c6c-8f33-9d85c2e7f207",
"deviceId":"10011347",
"productId":"100129",
"name":"switch",
"value":1,
"type": 3,
"created":1588065644340
}
]