# 命令下发结构 ## 1. 服务器端和边缘主机采用websocket协议通讯 ## 2. 下发的数据格式如下 <>, 其中 "t": 1|2|3|4|5, Body: ```json { // 针对不同的命令类型,这个字段里的`to`和`m`数据有所不同,具体在下面的小节描述 // 任务id,服务端在下发数据的时候,需要生成一个唯一的uuid, // 用于标识一个任务 "t_id": "任务id", // 表示发给哪个微服务,这里是服务的标识,即服务名称 "to": "", // 命令执行的超时时间,单位为秒 "t": 10, // 实际内容 "m": "$bytes", } ``` ## 3. 加密前的消息结构如下: 消息类型,目前支持四种消息类型: * 1代表参数下发,就是向该设备端的微服务发送消息,该消息会辗转发送给微服务进行处理,比如,设置modbus微服务的波特率等消息 * 2代表采集向下发,比如,设置某个设备短上的modbus微服务采集某个地址的数据 * 3代表下发微服务文件。 * 4代表下发场景,这个指令用于设置设备端上各个微服务之间的逐句流转。 * 5代表删除场景 ### 3.1 参数下发的结构 对于参数下发,下发内容中的m为一个`map[string]interface{}`结构,用于向某个微服务发送参数,具体参数内容由微服务的参数配置提供。 ### 3.2 微服务的启动和停止 微服务的启动和停止由内置服务`service-monitor`管理,所以,实际启动和停止,只需要给该服务发送参数就行,其他流程(返回的step和result等)保持一致。实际下发的结构为: ```json { // 针对不同的命令类型,这个字段里的`to`和`m`数据有所不同,具体在下面的小节描述 // 任务id,服务端在下发数据的时候,需要生成一个唯一的uuid, // 用于标识一个任务 "t_id": "任务id", // 表示发给哪个微服务,启动和停止,都是发给内置服务service-monitor "to": "service-monitor", // 命令执行的超时时间,单位为秒 "t": 10, // 实际内容 "m": { "service_name": "需要启动或者停止的服务名, ${name}${copy}-${version}的格式", "action": "start|stop", "command": "如果是start,则需要传递启动命令,启动命令由config.yaml配置文件的boot字段指定" } } ``` ### 3.3 采集项下发的结构 采集项下发时,下发内容中的m为一个`[]map[string]interface{}`结构的列表,每一个条目是一个采集项内容,具体采集向内容由微服务的采集项配置提供。 ### 3.4 场景下发的结构 在场景下发中,`to`字段会被忽略,可以填写空字符串,而m字段为json化之后的数据,json化之前结构如下: ```json { "scene_id": “场景的uuid”, "scene_name": "场景名称", // 节点列表 "v": [{ ”id“: "节点id", "service_name": "服务名,$name-version的形式", "real_service": "实际服务,$name$copy-$version的形式", "url": "服务下载url", "md5": "服务的md5值", "props": "props", "display_name": "涂上展示的信息" }] // 连线列表 ”e“: [{ "from": 出节点的id, "to": 入节点的id, }] } ``` ### 3.5 删除场景 在场景删除中,`to`字段会被忽略,可以填写空字符串,而m字段为json化之后的数据,json化之前结构如下: ```json { "scene_id": "scene_id" } ``` ```ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss ## 设备状态轮询 ## 2. 下发的数据格式如下 <<17:8, Body:任意长度(先json序列化,然后aes加密)>>, 其中 Body: ```json { "device_uuid": "设备的uuid", // 命令执行的超时时间,单位为秒 "t": 10, "command": "query_status" } ``` 返回值: ```json { "edge_status": int, "message": "描述信息" } ```