Skip to content

属性与配置 Attribute & Config

属性(Attribute)是驱动声明"接入一台设备需要填哪些配置项"的定义,配置(Config)是某台设备 给这些配置项填的具体值。 一个回答"有哪些格子要填",一个回答"这台设备的格子里填了什么"。

设备能不能被采集,往往不取决于"温度位号叫什么",而取决于一些很具体的协议细节:Modbus 要读哪个寄存器地址、HTTP 要请求哪个 URL、MQTT 要订阅哪个 Topic。这些细节因协议而异、因设备而异,写死在代码里行不通。IoT DC3 把它拆成两层来管:驱动声明需要哪些配置项(Attribute)设备实例填这些配置项的值(Config)

理解它的关键,是先分清这里其实有三摊互不相同的东西:

归属回答的问题谁来填
Param 业务参数模板 Profile指令/事件携带哪些业务字段建模者,在模板里定义
Attribute 属性定义驱动 Driver接这种协议需要哪些配置项驱动开发者,启动时注册
Config 配置值设备 Device这台设备这些配置项填什么集成者,在设备编辑页填

Param 是"业务语义"(温度、模式、故障码),属于模板,和具体协议无关;Attribute / Config 是"协议映射" (寄存器地址、Topic、报文模板),属于驱动和设备。本页只讲后两层,Param 见指令事件

经典例子:一句话讲清 Attribute vs Config

Modbus 驱动声明"读一个位号,需要一个寄存器地址"——这是 Attribute(驱动注册的"有这么个配置项")。 给 3 号设备的温度位号填上"地址 = 40001"——这是 Config(这台设备这个配置项的具体值)。

同一个 PointAttribute(registerAddress),1 号设备可能填 40001,3 号设备填 40003;换 MQTT 驱动,声明的就不再是寄存器地址,而是 topic。属性是"模具",配置是"浇出来的件"。

Attribute 定义从哪来

属性不是在数据库里手建的,是驱动启动时注册的

驱动在自己的 application.yml 里声明支持哪些属性,启动时上报给 Manager,Manager 以 tenant_id + driver_id + attribute_code 为唯一键落库。不同协议需要的属性不同,所以属性的"权威来源"是驱动,而不是页面手填。

yaml
dc3:
  driver:
    driver-attribute:        # 连接级配置项:连这台设备网关需要什么
      - attribute-name: Host
        attribute-code: host
        attribute-type-flag: STRING
        default-value: localhost
    point-attribute:         # 位号级配置项:采每个位号需要什么
      - attribute-name: Register Address
        attribute-code: registerAddress
        attribute-type-flag: INT
        default-value: ''

DriverAttributePointAttribute 的区别只在作用范围:前者一台设备填一份(连接信息),后者每个位号 各填一份(采集映射)。

关键字段

属性定义 DriverAttributeBO / PointAttributeBO(两者字段完全一致,结构同源):

字段类型含义
attributeNameString属性名称(页面展示用)
attributeCodeString属性编码,配置按它匹配(如 hostregisterAddress
attributeTypeFlagAttributeTypeEnum值类型,见下
defaultValueString默认值,设备未填时兜底
driverIdLong归属的驱动
attributeExtDriverAttributeExt / PointAttributeExt扩展信息(如 UI 控件、校验规则)
enableFlagEnableFlagEnum启停状态
tenantIdLong归属租户

配置值 DriverAttributeConfigBO / PointAttributeConfigBO

字段类型含义
attributeIdLong指向哪条属性定义
configValueString实际填的值(如 40001
deviceIdLong归属哪台设备
pointIdLongPointAttributeConfig,指向哪个位号
configExtJsonExt配置扩展信息
enableFlagEnableFlagEnum启停状态
tenantIdLong归属租户

DriverConfig 按设备、PointConfig 按位号

DriverAttributeConfig 只有 deviceId,因为连接信息一台设备一份;PointAttributeConfig 多一个 pointId ,因为每个位号都要单独填采集映射。这正是两层作用范围不同的直接体现。

值类型 AttributeTypeEnum

attributeTypeFlag位号共用同一套类型系统:

STRINGBYTESHORTINTLONGFLOATDOUBLEBOOLEAN

与其它概念的关系

driverId · 一驱动多设备1N注册 · 连接级声明注册 · 位号级声明attributeId · 一台设备一份attributeId · 每位号一份deviceIddeviceId + pointId同构驱动 DRIVER · dc3_driveridPKdriverName · driverCodeserviceName · driverTypeFlagenableFlag · tenantId设备 DEVICE · dc3_deviceid · deviceName · deviceCodedriverId(选择驱动)FKenableFlag · tenantId驱动属性 DRIVER_ATTRIBUTE · 连接级idPKattributeName · attributeCodeUKattributeTypeFlag(8 种类型)defaultValuedriverIdFK位号属性 POINT_ATTRIBUTE · 位号级idPKattributeName · attributeCodeUKattributeTypeFlag(8 种类型)defaultValuedriverIdFK驱动属性配置 DRIVER_ATTRIBUTE_CONFIGattributeIdFKdeviceIdFKconfigValue(如 192.168.1.10)configExt · enableFlag位号属性配置 POINT_ATTRIBUTE_CONFIGattributeIdFKdeviceId · pointIdFKconfigValue(如 40001)configExt · enableFlag同构扩展(指令 / 事件)CommandAttribute(Config) — 指令协议映射· 仅 execute() 自定义指令消费EventAttribute(Config) — 事件解析路径· 常见于监听型驱动作用范围差异连接级:一台设备填一份(host/port)位号级:每个位号各填一份(寄存器地址)PKPK 主键FKFK 外键UKUK 唯一键1:N 一对多设备侧引用(虚线)同构扩展(虚线)

属性挂在驱动下、被设备配置引用;位号配置还额外绑定到具体位号。建模时定义模板 (含位号、指令、事件),接入时由驱动声明属性、设备填配置,两条线在设备处汇合。

注册与配置流程

阶段 A · 声明期(驱动启动时)阶段 B · 配置期(集成者)阶段 C · 运行期(采集执行)解析声明上报注册页面按属性渲染表单逐项填写保存 Config运行时读取生效采集① 读 application.ymldriver-attribute: host · port …point-attribute: registerAddress …② 随注册上报 ManagerRegisterBO 携带属性集DriverInitRunner 触发 · 失败退避重试③ 属性定义落库唯一键 tenant_id + driver_id+ attribute_code · 写入或更新④ 设备编辑页加载属性列按当前 driverId 列出配置项按类型与默认值渲染表单⑤ 集成者逐项填值host = 192.168.1.10 · port = 502registerAddress = 40001⑥ 配置值落库DriverAttributeConfig 一台设备一份PointAttributeConfig 每位号一份⑦ 驱动拉取配置按配置连接设备网关组装协议报文要素⑧ 采集 / 执行读寄存器 / 订阅 Topic → 位号值自定义指令 execute() 渲染报文DriverAttribute / PointAttribute声明(模具 · 权威来源是驱动)DriverAttributeConfig / PointAttributeConfig实例值(浇出来的件)缺采集 → 多半 Config 填错(页面改值即可)缺能力 → Attribute 未声明(改 yml 重启)位号读写走位号属性配置指令属性仅 execute() 自定义指令消费阶段(区域)驱动侧集成侧执行侧落库产出
  1. 驱动从 application.yml 读取 driver-attribute / point-attribute,启动时上报。
  2. Manager 按唯一键写入或更新属性定义。
  3. 设备编辑页按当前 driverId 加载属性列,集成者逐项填值。
  4. 配置值落到 Config 表,运行时驱动拉取并组装成实际协议报文。

Attribute / Config 能解决什么、不能解决什么

Attribute + Config 解决的是协议映射:把"这台设备的这个位号/连接"翻译成驱动能执行的具体地址、Topic、模板。它不能 单独表达"位号本身是什么""指令要传哪些业务参数"——那是模板与 Param 的职责。

能解决不能单独解决(需要其它模型)
连这台设备网关用什么 Host / 端口这类设备有哪些位号、指令、事件 → 模板 Profile
采这个位号读哪个寄存器 / 路径指令携带哪些业务入参出参 → 指令 Command 的 Param
同一模板在不同驱动下填不同映射值事件上报哪些业务字段 → 事件 Event 的 Param

一句话定位

缺采集?多半是 Config 没填或填错(地址/Topic 写错)。缺能力?那是 Attribute 没声明(驱动根本没注册这个配置项)——后者要改驱动 application.yml 重启,前者在页面改值即可、无需重启。

示例

3 号温度传感器,绑定 Modbus 驱动:

  • 驱动注册的属性(示意):DriverAttribute(host)PointAttribute(registerAddress)——键名以各驱动 application.yml 为准(如 Modbus TCP 实际用 slaveId/functionCode/offset)。
  • 设备填的配置:DriverAttributeConfig{ deviceId: 3, configValue: "192.168.1.10" }(连接到这台网关);温度位号填 PointAttributeConfig{ deviceId: 3, pointId: 温度位号, configValue: "40001" }

运行时驱动据此连接 192.168.1.10、读寄存器 40001,把读数封装成该位号的位号值上报。换成 1 号设备, configValue 改成另一个地址即可,属性定义完全复用。

指令属性与事件属性

除了驱动/设备层(DriverAttribute)与位号层(PointAttribute),平台还有两层同构的属性声明,服务于指令与事件:

属性实体配置实体谁来读
指令CommandAttributeCommandAttributeConfig驱动的 execute()——设备级"自定义指令"的协议映射(如 Modbus 功能码模板)
事件EventAttributeEventAttributeConfig驱动的事件上报路径——外部事件如何解析为平台事件

两点注意:

  • 位号读写不走指令属性:位号级读写命令的取值来源是位号属性PointAttributeConfig,如 Modbus 的 slaveId/functionCode/offset)。部分驱动在 yml 里也注册了 command-attribute,但仅当该驱动实现了 execute()(设备级自定义指令)时才被消费——以各驱动页的"写命令属性"节为准。
  • 事件属性常见于监听型驱动(如 listening-virtual 从报文解析事件),键名见各驱动的 event-attribute 配置。

延伸阅读

基于 AGPL-3.0 协议发布