插件模块

以后所说的插件仅指设施类插件，插件为SA提供额定的设施发现和管制性能；
插件通过实现定义的grpc接口，以grpc服务的模式运行，提供接口给SA调用
插件同时须要http服务提供h5页面及动态文件

1. SA中插件的工作流程

1.1 插件部署流程

插件开发者将开发好的插件服务编译成docker镜像提供给SA
SA依据插件的镜像地址判断本地是否曾经拉取或更新
用户装置插件后，SA依据镜像运行起容器，插件往注册核心注册服务
SA通过服务发现发现新的插件服务

1.2 插件应用流程

用户在界面上发现设施时对所有插件服务调用Discover接口，插件依据实现的接口返回所发现的设施
用户增加设施并标记设施对应的插件
用户申请设施的H5地址，进去插件自定义页面
通过交互发动自定义指令给SA，SA将指令转发给对应的插件服务

2. 接口

文件http服务 sdk提供了不便的办法进行动态文件挂载和自定义api接口实现

grpc服务， 通过实现protobuf定义的grpc接口来实现插件服务：

注：grpc接口是通用的定义，SDK对接口实现了封装，开发者应用SDK时不须要关怀，仅须要实现设施类型即可。

3. sdk

为了不便开发者疾速开发插件以及对立接口，咱们提供sdk标准了接口以及预约义了设施模型，以下为sdk实现性能：

  • 插件服务注册
  • http服务
  • grpc服务以及接口封装（包含设施属性获取、属性设置、音讯告诉等）
  • 预约义模型

4. 设施模型设计

云对云接入时，须要对第三方云的命令进行解析，并通过SA对插件发动命令。

这就要求插件实现的命令必须要有对立的标准和规范，这样第三方就能够通过这个规范来管制SA的所有反对的设施。

同时也能不便SA更好的通过对立的接口以及命令来治理设施。

4.1 模型设计

SDK预约义设施类型以及属性，开发者通过引入设施类型实现相干性能。

SDK通过反射获取设施的所有属性，将属性与命令做好对应关系，这样能够使得无论设施是什么状态，都能有对立的接口以及命令进行管制。

4.1.1 插件模型定义

字段解释

  • instance 实例
  • attribute 属性
  • val_type 值类型
  • val 值

val_type

对于int型，属性可设置最小和最大值

模型

  • light_bulb 灯

    | brightness |亮度 | int |false | color_temp |色温 | int |false
  • switch 开关
  • outlet 插座
  • info 设施详情

4.2 模型示例

操作某个属性时，依据属性的tag对命令中的值进行解析和校验 模型例子如下：

5. 示例我的项目

  • demo-plugin