大衍物联网使用说明书
大衍物联使用说明书
产品资料地址
码云资料
功能列表
- 展示设备网络状态，设备上线离线实时更新状态（目前只支持TCP协议）
- 前端可与设备的每条用户指令交互，可用于现场测试产品
- 增加设备指令时无需重启程序，在WEB端配置即可
- 增加厂家协议时无需重启程序，但需要写厂家协议的解释器
- 增加支持多通信端口接入设备，每一个通信端口，代表一批设备的通道，关闭端口，关闭通信服务。正常的设备通信端口保持不动，新增产品的时候，新增通信端口，如有异常，及时断开，不影响之前产品的使用。
- 增加项目设备指定的HTTP上报接口，每一个项目的设备，可能有具体的业务展开，将数据上传到指定的HTTP接口，由第三方具体处理。
- 提供给第三方平台调用的统一格式的设备指令交互接口，统一的调用地址，无论多少设备，交互服务的地址都是一致的，不会一种产品一个服务地址，增加维护成本。接口的数据模型，键值一致，具体的Value从WEB端查询。
- 提供项目管理功能，展示项目状态，以及项目所使用的设备。
- 支持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
设备属性
- 地址码： 占用一个字节的属性
- 功能码： 占用一个字节的属性
- 起始地址： 占用两个字节的属性
- 数据长度： 占用两个字节的属性
- 返回字节数： 占用一个字节的属性
- 水分值： 占用两个字节的属性
- 温度值： 占用两个字节的属性
你看，实际上就两个属性的编解码，一个是占用一个字节的属性，一个是占用两个字节的属性。
Web端配置
- 项目信息
配置项目信息
- 属性包信息
-
- 属性信息
- 指令信息
发起方代表指令的发起者，指令类型标识有无回复。
仁大建科 -- 土壤温度水分变送器 485型 有两条指令
- 指令配置
配置发送指令：
配置回复指令：
指令配置后，生成的指令数据:
指令Id 88，报文属性，是由第三方平台调大衍物联平台接口数据
指令Id 89，报文属性，是大衍物联平台返回的数据，第三方平台根据格式解析
- 协议信息
用到两种协议，一种是注册帧协议，一种是TCP-MODBUS协议
注册帧：
数据帧：
产品信息：
- 添加产品支持的协议帧
- 设备信息
前端展示：
前端所有的展示数据，都是由后端添加生成。例如刚才我们添加了设备参数，前端展示如下：
设备信息：
指令信息：
厂家协议插件
上诉所有效果，所依赖的后端程序服务如下：
APP展示效果，也是后端数据增加后变动。这些模块，当设备属性所需的空间集合没由变化时，就无需变动了。
后端服务封装了，iot设备的指令变动，但是具体的厂家协议千变万化，在程序中无法封装，所以我们这一块的变化，做成插件，大衍物联每扩增一个厂家协议，我们就需要对应的一个厂家协议插件开发。这个开发，满足“数据”帧的“解包”，“封包”即可。
厂家协议
厂家协议id是4
插件开发
配置文件格式
Tcp-modbus配置文件
流程展示
设备建立链接
设备发送注册帧，标识通道
APP发送指令，厂家协议插件接收
厂家协议插件化优势是便于程序员与硬件设备调试，并且正在运行的服务无需停止。
设备接收的数据，即把平台的数据封包成TCP-MODBUS格式数据
设备返回指令
厂家协议插件，解包
平台接收的数据信息
APP前端展示
