4.4 KiB
4.4 KiB
命令下发结构
1. 服务器端和边缘主机采用websocket协议通讯
2. 下发的数据格式如下
<<T:1byte, Body:任意长度(先json序列化,然后aes加密)>>, 其中
"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": "描述信息"
}
```