设备通讯协议Word格式.docx

设备通讯协议Word格式.docx

《设备通讯协议Word格式.docx》由会员分享，可在线阅读，更多相关《设备通讯协议Word格式.docx（29页珍藏版）》请在冰豆网上搜索。

本协议是针对与设备的数据通信，目前通信节点包括：

设备、云端和APP终端三方。

WIFI上的协议采用MQTT协议框架，串口上的通信采用包含包头和校验的二进制协议，通信包采用二进制格式传输，高位在前低位在后。

此协议定义的MQTTTopic类型有以下2种：

1单播，unicast

/u/{TargetType}/{TargetID}

2广播，broadcast

/b/{SourceType}/{SourceID}

注释：

TargetType：

目标设备类型，TargetID：

目标设备编码

SourceType：

源设备类型，SourceID：

源设备编码

3.2.2通讯命令格式

设备与云端、APP的通讯命令分为4种：

请求与回应、通知命令、广播命令，具体的命令以及格式在后面章节介绍。

3.2.2连接流程

设备连接云端的步骤如下图：

3.3数据包格式定义

数据包的格式根据通讯双方的不同、数据链路的差异会有不同的包格式，本协议为尽量保证数据包格式的统一，做了几点规划：

1.数据包格式中核心的部分包括CMDID和CMDPayload，这两部分格式所有的包中保持一致，CMDID1个字节，CMDPayload紧跟CMDID长度N字节。

2.设备间通讯，包括内部命令、外部转发命令等的数据包格式虽然可能不一样，但是都可以通过包头中的Option字节进行区分，可以公用相同的解析函数

3.外部串口通讯的命令格式与设备间通讯格式保持一致。

3.3.1设备间通讯数据格式

3.3.1.1Fixheader

固定帧头，格式如下表：

HeadOption

2Byte

1Byte

1~2Byte

同步头：

0x5CFE

HeadOption：

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

预留

CheckSum校验

广播类型链路

CRC校验

加密选项

typedefenum

{

OPTIONAL_ENCRYPT_BIT=（1<

<

0）,

OPTIONAL_CRC_BIT=（1<

1）,

OPTIONAL_BROADCAST_DATALINK_BIT=（1<

2）,

OPTIONAL_CHECKSUM_BIT=（1<

3）,

}OptionalBitsT;

包长度：

长度包括本字节之后的所有数据的长度

长度是1~2个字节

字节数

取值

长度范围

1

0x0~0x7F

0~127

2

0x0180~0x7FFF

128~16383

长度的编码方式参考MQTT：

如长度是321=（65+2*128），那么会被编码为两个字节，低字节为65+128=193.高字节为2。

3.3.1.2可变包格式

可变包格式需要通过HeadOption来解析，格式如下表：

OptionBit0

OptionBit2

OptionBit1

OptionBit3

加密随机数

设备类型

设备编码

消息体......

CheckSum

3Byte

......

异或随机数：

如HeadOption中的加密选项为0，那么加密随机数这个字节不存在，同时数据不会进行加密

源设备信息：

用于广播类型的数据链路，需要标识数据的来源。

CRC校验：

采用16bit的CRC算法，CRC算法参照附录。

CheckSum:

采用8Bit的和校验，用于对数据长度比较敏感，但是又需要进行数据校验的场景

设备编码和设备类型：

Payload中可能需要用到的内部设备Type和ID的定义：

内部设备Type和设备ID在设备配对时由主设备分配给从设备，

其中Type由主设备获取到从设备的DeviceType之后映射一个数值，并分配给从设备，建立映射关系。

ID的3字节构成为：

Byte3

Byte2

Byte1

随机数，避免不同子网的ID冲突

ID序号，由主设备维护

3.3.1.3命令消息体

结构如下表

CMDkey

NByte

CMDKey：

命令标识，主要作用是标识命令的类型以及编号，由主设备生成，发送给从设备，从设备将key返回给主设备，另外在还标识命令的类型

描述

备注

设备内部消息（组网、透传模式的内部消息）

这些命令没有重发机制，不能保障一定到达

Notify类消息

3

Broadcast类消息

4~31

预留reserved

32~255

动态分配的key，用于数据的转发、透传

此范围的命令如果没有回复会重发，重发一定次数后丢弃，所以此消息可能会多次到达

CMDID:

命令码，1个字节

命令码

配对请求

配对请求回应

设备启动通知

4

设备启动回应

5

WiFi就绪通知

6

WiFi断开通知

7

云就绪通知

8

云断开通知

9

WiFi上电通知

10

WiFi模块配置完成通知

11

退出WiFi模块配置

12

退出WiFi模块配置回应

13

重新配置WiFi模块

14

重新配置WiFi模块回应

15

设置WiFi模块串口波特率

16

设置WiFi模块串口波特率回应

17

查询WiFi模块串口波特率

18

查询WiFi模块串口波特率回应

WiFi模块消息起始

32

设备上线通知

33

WiFi配置完成通知

34

获取设备WiFi模块监控信息

35

获取设备WiFi模块监控信息回应

36

设置路由器信息

37

设置路由器信息的回应

38

删除子设备

39

删除子设备回应

40

获取在线设备列表

41

获取在线设备列表回应

42

设置设备拥有者

43

设置设备拥有者回应

44

设置配对模式

45

设置配对模式回应

46

在线设备列表变更通知

47~63

WiFi模块预留

所有设备公共命令起始

64

主MCUOTA传输文件

65

主MCUOTA传输文件回应

66

设置出厂参数

67

设置出厂参数回应

68

DebugLog输出控制

69

DebugLog输出控制回应

70

DebugLog信息输出

71

从MCUOTA传输文件

72

从MCUOTA传输文件回应

73

云端推送通知信息

76

OTA完成通知上报

77~95

设备公共命令预留

设备业务命令起始

96~127

设备自定义设备内部消息

128~255

设备自定义设备与云端/APP通讯消息

Payload：

命令数据,N字节

5.4实例

一个所有Option都打开的包结构如下：

3.3.1.4数据组包实例

以下是使用CRC校验，并且加密的数据包的组包过程：

假设命令包是1234,4个字节，现在要组包

1：

CRC

第一步计算这4个字节的crc值，假设算出来是5、6

第一步CRC之后的数据包就变成了1、2、3、4、5、6,6个字节

2：

加密

加密第一步：

加入一个随机数，假设这个随机数是0，现在包就是7个字节了，0、1、2、3、4、5、6

加密第二步：

异或，将除加密随机数外的其他数据都和加密随机数进行异或，得到得数据应该是0、1、2、3、4、5、6

机密第三步：

查表加密，假设表中0对应的是6、1对应的是5依次类推，那么查表之后的数据变为了6、5、4、3、2、1、0

加密结束,payload最终就是6、5、4、3、2、1、0了

3：

加入包头

Payload是7个字节，optional是CRC和加密，那么包头为FE5C0307

最终包数据为：

FE5C030706050403020100

解包的过程与组包相反

3.3.2设备与云、APP通讯数据格式

命令数据格式：

源设备类型

源设备ID

5Byte

12Byte

3.3.2Pad串口通讯数据格式

下行数据格式，PAD->

设备

源设备GUID

目标设备GUID

34字节

上行数据格式，设备->

PAD

4.公共命令定义

下表是公共命令码以及命令数据的定义，此表仅涉及到上文提到的CMDID和命令信息码（或回复码），命令中的其他部分数据请参考上文中的数据包定义。

命令描述

通信方

命令组成

设备内部命令起始

请求配对

从设备->

主设备

CMDKey[1Byte],0x01

CMDID[1Byte]

业务设备类型[5Byte]

当前的内部设备类型[1Byte]

当前的内部设备编码[3Byte]，全0表示未配置过，非全0表示之前配置过

设备业务编码长度[1Byte]

设备业务编码[NByte]

5个字节的业务设备类型，需要向乐君申请，并且保存在从设备中

设备业务编码是用从设备自行定义的设备ID字符串，不超过32字节

请求配对回应

主设备->

从设备

CMDKey,0x01

RC[1Byte],参考RC表

分配的设备类型[1Byte]

分配的设备ID[3Byte]

MCU/从设备->

CMDKey[1Byte],0x01

版本号[1Byte]

子设备类型[1Byte],参考5.3章节：

子设备类型表

内部设备类型[1Byte]

内部设备编码[3Byte]

设备启动通知的回应

MCU/从设备

RC[1Byte],参考RC表

WiFi模块上电通知

WiFi模块->

MCU

WiFi模块上电后定时发送上电通知给MCU，直至MCU上报上线通知给WiFi模块（适用于用于透传模式）

RC[1Byte],0成功，3超时，4退出

MCU->

WiFi模块

RC[1Byte],0成功，1失败

Baudrate[4Byte]

Baudrate取值：

9600

19200

38400

57600

115200

其他值返回fail

默认值是9600

返回值以新设置的波特率发送

WiFi模块命令起始

设备信息上报

Cloud/APP

Num［1Byte］，设备个数

设备拥有者的小智ID[string,10字节]

WiFi模块Mac地址[ASCII,12字节]

GUID[ASCII,17字节]、设备业务编码长度[1Byte]、设备业务编码[NByte]、固件版本［1BYTE］、设备硬件架构类型[1BYTE]、设置是否在线[1Byte]，若干

MQTT主题：

第一个设备是主设备

设备硬件架构类型参考

“设备硬件架构类型编码表”

设备是否在线，0不在线，1在线

APP

设备GUID[ASCII,17字节]

用户的小智ID[string,10字节]

获取WiFi模块监控数据

Cloud/APP->

获取WiFi模块监控数据回应

Cloud/APP

WiFi模块连接信号强度[1Byte]，有符号的1个字节，一般范围在-100Dbm~0Dbm

WiFi模块型号[16byte],小于16字节的字符串

设置WiFi配置信息

APP/Cloud/串口控制端->

是否设置拥有者ID[1Byte]，0不设置，1设置

是否设置路由器信息[1Byte],0不设置，1设置

SSIDLen，用户名长度[1BYTE]，用户名长度小于等于32字节

PWDLen，密码长度[1BYTE]，密码小于等于64字节

SSID

PWD

设置WiFi配置信息回应

设备->

APP/Cloud/串口控制端

RC（参考命令回应编码表：

0成功，1失败

GUID[ASCII,17字节]

APP/Cloud/串口控制端

获取设备列表

主设备

获取设备列表回应

设置设备进入配对模式

App/Cloud/串口控制端->

设置设备进入配对模式回应

App/Cloud/串口控制端

0成功，1失败）[BYTE]

47

设置设备退出配对模式

48

设置设备退出配对模式回应

49

请求同步时间

Cloud

50

请求同步时间回应

Cloud->

RTC时间[67Byte]，格式是{秒-分-时-日-月-年-星期几}，各一个字节

星期几的范围从1~7,1表示星期一

51

扫描AP列表

控制端->

52

扫描AP列表回应

设备到控制端

APNumber[1Byte]，扫描到的AP数量

AP信息{

[32Byte]，SSID

[1Byte]，RSSI信号强度

}若干

SSID为字符串，最大32字节，返回数据中固定32字节位置存放SSID。

信号强度取值范围0~100

总包数[2Byte]

当前包号[2Byte]

包内容[NBYTE,最大长度1024]

0成功，1失败，32包号错误，33数据校验错误）[1BYTE]

设置出厂信息

App/Cloud->

设备ID[12Byte]

设备业务ID长度[1Byte]

设备业务ID[NByte]

设备业务ID长度为0表示不需要设备业务ID

暂时只需要工厂测试程序支持

设置出厂信息回应

App/Clo