平台-设备【MQTT协议】

说明：为了统一前端/平台/设备端数据格式｜交互协议，统一使用该文档进行统一维护。

由于设备端使用mqtt协议，因此这里只做交互协议展示，不做具体接口调用！！！

由于MQTT协议是个传输层的协议，在应用层没有定义格式，需要用户自己定义。

设备接入平台

设备接入平台有两种方式：

设备直接进行平台连接

用户在平台预先进行配置和注册，等设备连接后进行管理

设备发送CONNECT报文

在mqtt协议中，设备向平台侧发送CONNECT类型的报文，这时平台侧仅处理该设备是否有权限接入平台，以及存储设备的ClientID。

在当前版本中，暂定所有的设备都放通接入。

因此设备端肯定都能收到平台侧响应的CONNACK报文，如果设备侧没有接收到CONNACK报文，那么设备侧需要一直尝试发送CONNECT报文，发送间隔暂定2.5*KeepAlive.

设备发送PUBLISH报文

在设备连接入平台后，设备需要立即发送PUBLISH报文，上报设备本身的基础信息，以便平台识别该设备，如果没有上报，此时存在场景，需要依次讨论：

设备是全新上线的，那么平台侧只有ClientID，没有其他信息，无法进行其他业务处理

设备之前上报过信息，那么平台侧使用相同ClientID的设备来处理和响应后续的处理

当前默认只发送QoS=0的报文信息，每隔5分钟循环上报一次

QoS=0的PUBLISH报文，平台侧无须响应

设备上报其他消息也适用PUBLISH报文

如果使用QoS=1/2的PUBLISH报文，那么服务端需要额外处理，设备侧也需要额外处理重试的报文，这里增加了复杂度，暂定为只用QoS=0的报文

设备发送SUBSCRIBE报文

设备订阅主题名称为设备sn/+的主题，平台侧通过查找设备sn的主题，发送消息给设备侧

设备发送PINGREQ报文

设备侧可以不用循环发送PINGREQ报文，因为会循环主动报上设备信息。

设备发送DISCONNECT报文

设备侧主动下线，需要主动发送DISCONNECT报文，以便平台侧能够实时感知到

配置管理的问题

平台侧存储两套配置，一套是平台侧配置的（平台页面修改），一套是设备端实时运行的（由设备端上报）。这里的差异来源于平台下发的异常和客户在设备端页面修改

平台侧的配置仅来源于平台侧模版和平台页面修改

设备端的运行配置仅来源于设备端上报

这里需要解决配置不一致的问题。

如果是客户在页面修改，那么不需要处理，有差异平台侧直接存储就行了。

如果是平台下发异常，那么需要重新下发配置。

设备上报的时候，需要增加一个字段用来识别当前的配置是否是客户修改过的。这时，如果平台识别到配置差异是用户的修改，那么不下发配置了。如果没识别到是客户修改的，那么差异就是平台侧下发异常的，这里需要重新下发。

那么这里需要识别配置是否有差异？

如果是是计算hash的话，那么平台侧只能知道有差异，无法知道差异来源，因此配置只能全部下发

主题管理

主题管理有两套方案：

（方案1）主题=sn，然后业务数据使用method=xxx来识别

（方案2）主题=sn/$method, 然后直接传输数据

例如：
设备上报状态信息：

（方案1）topic=sn1, body={"method":"status", "content":{"cpu":"x"}}

（方案2）topic=sn1/status, body={"cpu": "xxx"}

设备接收配置信息

（方案1）topic=sn1, body={"method":"config", "content":{"vlan":{...}, "wan":{...}}}

（方案2）topic=sn1/config, body={"vlan":{...}, "wan":{...}}

设备接收重启信息

（方案1）topic=sn1, body={"method":"reboot", "content":{}}

（方案2）topic=sn1/reboot, body={}

平台-设备MQTT协议

说明：为了统一前端/平台/设备端数据格式｜交互协议，统一使用该文档进行统一维护。#

设备接入平台#

设备发送CONNECT报文#

设备发送PUBLISH报文#

设备发送SUBSCRIBE报文#

设备发送PINGREQ报文#

设备发送DISCONNECT报文#

配置管理的问题#

这里需要解决配置不一致的问题。#

主题管理#