大衍物联网使用说明书

大衍物联使用说明书

产品资料地址 

码云资料

功能列表

1. 展示设备网络状态，设备上线离线实时更新状态（目前只支持TCP协议）

1. 前端可与设备的每条用户指令交互，可用于现场测试产品

1. 增加设备指令时无需重启程序，在WEB端配置即可

1. 增加厂家协议时无需重启程序，但需要写厂家协议的解释器

1. 增加支持多通信端口接入设备，每一个通信端口，代表一批设备的通道，关闭端口，关闭通信服务。正常的设备通信端口保持不动，新增产品的时候，新增通信端口，如有异常，及时断开，不影响之前产品的使用。

1. 增加项目设备指定的HTTP上报接口，每一个项目的设备，可能有具体的业务展开，将数据上传到指定的HTTP接口，由第三方具体处理。

1. 提供给第三方平台调用的统一格式的设备指令交互接口，统一的调用地址，无论多少设备，交互服务的地址都是一致的，不会一种产品一个服务地址，增加维护成本。接口的数据模型，键值一致，具体的Value从WEB端查询。

1. 提供项目管理功能，展示项目状态，以及项目所使用的设备。

1. 支持docker-compose 一键部署

用户接入参数

场景描述：施工部在溧水和凤施工需要使用土壤温度水分变送器 485型，并将土壤温度水分变松器的设备地址设为1，问我怎么样接入到平台?我说要使用DTU，并且DTU要设置设备编号为0000000001 因为服务器识别的帧数据较多，所以给设备编号加了标志信息，固定长度为7，帧头为FF，帧尾为FF，DTU设置注册帧，则是FF0000000001FF。DTU的连接地址为192.168.2.125 通信端口为10001。已知设备DTU使用的通信为TCP-MODBUS，格式为:

0000     0000    0007       01       03      04      0292FF9B

事务标识    协议标识   设备帧长度    设备地址     功能码     数据帧长度       数据

其实在TCP-MODBUS协议帧里用户感知到的只有”数据”。而其他的一些协议组成部分，都是由程序生成。那我们需要把用户感知到的数据部分，通过前端（小程序，H5，APP）提供给用户使用。而其他非用户感知的数据，我们需要在平台中自己分析处理。

上述字体标红部分，均为平台所需参数。我们需要将这些参数写入到平台中。

项目参数：溧水和凤

产品参数：土壤温度水分变送器 485型，192.168.2.125，10001。

协议参数：注册帧：FF0000000001FF，TCP-MODBUS：设备地址设为1

设备编号：0000000001

施工部得到的信息：DTU编号为0000000001，设置注册帧为FF0000000001FF,通讯协议为TCP-MODBUS。连接的远程通讯地址为192.168.2.125:10001，安装地址在溧水和凤。

这里施工部只负责安装，获取到传输参数即可。但是用户需要了解传感器的具体功能，怎样获取到具体的环境数据？

土壤温度水分变送器，如何获取土壤温度，土壤水分？如果用户有这种使用需求，通常开发们会额外写一个程序供用户使用。但是如果过了几个月，用户又采购空气温湿度传感器，还要获取空气温度，空气湿度。又过了几个月，用户又采用氮磷钾传感器！

那这种开发成本和维护成本以及开发节奏，公司如何决策呢？

有没有一种办法，不需要代码的修改，仅需要增添产品的交互指令，就实现这些功能呢？

答案是有，我们这样思考，土壤温度水分变送器只会获取土壤温度，土壤水分。空气温湿度传感器，只会获取空气温度，空气湿度。氮磷钾传感器也只会获取氮磷钾。这些属性是固定不变的，我们把这些属性抽取出来，组成设备属性包。我们只要组装设备属性包的属性，完成指令的拼装。

指令只是设备属性的组装关系，只要设备属性有限，那么设备的指令就有限，只要指令有限，那我们的前端就可以加载展示它。例如，氮磷钾传感器，抽取出设备属性，如下：

• 设备地址
• 功能码
• 氮
• 磷
• 钾

因为tcp-modbus支持一个DTU连接多个设备，所以需要设备地址区分具体传感器，所以把设备地址也当作设备属性。

而功能码，03代表读，06代表写，也作为一个设备属性抽离出来。

这五个属性，可以组装成任意的与氮磷钾传感器交互的指令。将这些属性暴露给厂家，由他们组装成指令，再将指令暴露给用户，用户通过指令获取传感器数据。平台只需要实现这些属性的编解码即可。而属性的编解码很简单，如果按属性所占的计算机空间来算，那就可以分类为：占用一个字节的属性，占用两个字节的属性，占用三个字节的属性，占用四个字节的属性。氮磷钾虽然名称不同，但是他们占用的字节相同，只不过命名不一样，他们编解码的规则一模一样。其他传感器也类似，他们上报的环境数据可能不同，但是他们的编解码规则都是高度的相似和重复。我们抓住这一点，将基本的编解码规则完成，其他的只是这种规则的别名，这种规则的组合关系，通过WEB暴露给用户操作即可！

所以我把这个平台命名为大衍物联网。理解这个平台，主要就是抓住这句话：

属性的编解码很简单，按属性所占的计算机空间来算，那就可以分类为：占用一个字节的属性，占用两个字节的属性，占用三个字节的属性，占用四个字节的属性。

设备接入操作

设备参数

项目参数：溧水和凤

产品参数：土壤温度水分变送器 485型，192.168.2.125，10001。

协议参数：注册帧：FF0000000001FF，TCP-MODBUS：设备地址设为1

设备编号：0000000001

设备属性

1. 地址码：     占用一个字节的属性
2. 功能码：     占用一个字节的属性
3. 起始地址：   占用两个字节的属性
4. 数据长度：   占用两个字节的属性
5. 返回字节数： 占用一个字节的属性
6. 水分值：     占用两个字节的属性
7. 温度值：     占用两个字节的属性

你看，实际上就两个属性的编解码，一个是占用一个字节的属性，一个是占用两个字节的属性。

Web端配置

• 项目信息
• 

配置项目信息 

• 属性包信息
•  
• 

• 属性信息

• 指令信息

 发起方代表指令的发起者，指令类型标识有无回复。

仁大建科 -- 土壤温度水分变送器 485型 有两条指令

• 指令配置

配置发送指令：

配置回复指令：

 

 指令配置后，生成的指令数据:

指令Id 88，报文属性，是由第三方平台调大衍物联平台接口数据

指令Id 89，报文属性，是大衍物联平台返回的数据，第三方平台根据格式解析

• 协议信息

用到两种协议，一种是注册帧协议，一种是TCP-MODBUS协议

 注册帧：

数据帧：

产品信息：

 

 

• 添加产品支持的协议帧

• 设备信息

前端展示：

前端所有的展示数据，都是由后端添加生成。例如刚才我们添加了设备参数，前端展示如下：

设备信息：

指令信息： 

 厂家协议插件

上诉所有效果，所依赖的后端程序服务如下：

APP展示效果，也是后端数据增加后变动。这些模块，当设备属性所需的空间集合没由变化时，就无需变动了。

后端服务封装了，iot设备的指令变动，但是具体的厂家协议千变万化，在程序中无法封装，所以我们这一块的变化，做成插件，大衍物联每扩增一个厂家协议，我们就需要对应的一个厂家协议插件开发。这个开发，满足“数据”帧的“解包”，“封包”即可。

 厂家协议

 厂家协议id是4

插件开发

配置文件格式

 Tcp-modbus配置文件

 流程展示

设备建立链接

 设备发送注册帧，标识通道

 APP发送指令，厂家协议插件接收

 厂家协议插件化优势是便于程序员与硬件设备调试，并且正在运行的服务无需停止。

 设备接收的数据，即把平台的数据封包成TCP-MODBUS格式数据

 设备返回指令

厂家协议插件，解包

 平台接收的数据信息

 APP前端展示