物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载导读related device attributes关联设备属性是 ThingsBoard 规则引擎中的一类富集Enrichment节点它负责根据消息来源设备与目标设备之间的关系查询从关联设备上拉取属性或最新遥测数据并注入到当前消息中供后续节点使用。本文以 ThingsBoard 官方帮助文档 related_device_attributes_node_fields_templatization.md 为核心围绕字段模板化Fields Templatization展开你将学会利用${metadataKey}、${messageKey}模板语法让节点配置在运行时动态化并掌握一个完整的智能灌溉场景实战案例——当土壤湿度跌破阈值时动态获取灌溉控制器的lastIrrigationTime属性当风速过高时获取lastIrrigationPauseTime属性。什么是字段模板化Fields Templatization在 ThingsBoard 规则引擎中部分节点尤其是富集类节点如 originator attributes、tenant attributes、customer attributes、related device attributes 等的输入字段支持模板化。所谓模板化是指在节点配置中不是写死某个固定的属性键名而是通过${...}占位符引用消息运行时携带的动态数据${messageKey}引用当前消息msg中的字段值${metadataKey}引用当前消息metadata中的字段值。当消息流经该节点时ThingsBoard 会先在运行时完成字符串替换再用替换后的结果作为真实的属性键、设备名或查询条件去执行数据拉取。这一机制让同一个节点配置可以被成千上万条携带不同上下文的消息复用而无需为每种情况单独搭建一条规则链。在官方帮助体系中这一通用能力被封装为common_node_fields_templatization片段并被上述多个富集节点的帮助文档共同引用说明模板化是 ThingsBoard 富集节点的一等公民能力。节点工作原理从源码看实现要理解字段模板化的底层支撑可以先定位该节点的核心实现。在仓库的规则引擎组件中该节点对应类为 TbGetDeviceAttrNode.java节点类型为ENRICHMENT富集名称related device attributes其职责是 Add originators related device attributes and/or latest telemetry values into message or message metadata——把与消息发起者存在关联关系的设备的属性/最新遥测写入消息或元数据关键逻辑通过EntitiesRelatedDeviceIdAsyncLoader.findDeviceAsync(ctx, msg.getOriginator(), config.getDeviceRelationsQuery())异步查找关联设备若按配置的关系查询找不到关联设备则抛出Failed to find related device to message originator using relation query specified in the configuration!并走Failure分支实现见 EntitiesRelatedDeviceIdAsyncLoader.java节点声明中明确若查找到多个关联设备仅取第一个用于消息富集其余设备被丢弃节点提供Success与Failure两个输出连接。节点配置类为 TbGetDeviceAttrNodeConfiguration.java其核心字段包括deviceRelationsQuery设备关系查询定义方向Direction、最大层级Max relation level、关系类型Relation type以及设备 Profile 过滤继承自 TbGetAttributesNodeConfiguration.java 的属性获取配置clientAttributeNames/sharedAttributeNames/serverAttributeNames客户端、共享、服务端属性键列表latestTsKeyNames最新遥测键列表tellFailureIfAbsent目标属性缺失时是否返回失败getLatestValueWithTs是否连同时间戳一起获取最新值fetchTo拉取结果写入DATA消息还是METADATA元数据默认METADATA。这些配置字段正是 UI 配置面板中各个输入框的落点也是模板化语法生效的载体——serverAttributeNames这类列表字段中的每一项都可以写成一个${...}模板。实战场景智能灌溉控制器的条件化数据获取官方帮助文档给出了一个非常具体的端到端示例假设我们有一台水分计设备消息发起者 originator它上报的遥测消息包含以下读数soilMoisture土壤湿度windSpeed风速windDirection风向temperature温度humidity空气湿度根据不同的环境条件我们需要从关联的灌溉控制器设备上获取不同的服务端属性条件一干旱临界当土壤湿度读数跌破 30% 阈值时被视为对作物健康和生长有直接影响的关键状态此时需要获取lastIrrigationTime属性以了解田地最近一次浇灌时间从而决定是否触发灌溉系统条件二大风暂停当土壤湿度高于 30%但风速超过 8 m/s 时需要获取lastIrrigationPauseTime属性以了解灌溉系统上次因大风而暂停的时间结合当前与历史气象条件做出更合理的灌溉决策。为此我们先编写一个脚本节点根据上述条件向消息元数据metadata中追加一个键keyToFetch其取值为lastIrrigationTimelastIrrigationPauseTime随后在related device attributes节点的Server attributes输入框中写入模板${keyToFetch}节点就会在运行时把metadata.keyToFetch的实际值替换进去从而动态决定拉取哪个服务端属性。节点配置面板解读官方文档配图 related-device-attributes-ft.png 展示了该场景下完整的节点配置界面关键配置项如下Name自定义节点名示例为fetch irrigation controller dataDevice relations query设备关系查询Direction方向示例选To即关系指向当前设备Max relation level最大关系层级设为1只取直接关联的一层设备Relation type关系类型配置为Manages管理关系Device profiles设备 Profile选择IrrigationController限定只关联该类型的设备Related device attributes关联设备属性Client attributes客户端属性示例中留空Shared attributes共享属性示例中留空Server attributes服务端属性配置模板${keyToFetch}Latest telemetry最新遥测示例中留空Add selected attributes to结果存放位置选中Metadata元数据Tell failure if any of the attributes are missing任一属性缺失即报失败已开启对应源码中的tellFailureIfAbsent字段保证拉不到属性时走Failure分支便于下游告警或重试。界面中的提示文本与源码字段一一对应例如所有输入字段支持模板化可通过${messageKey}提取消息值、${metadataKey}提取元数据正是对本文所述模板化机制的官方注解。场景一的完整消息流脚本节点处理后匹配条件一soilMoisture 28.9 30%脚本节点在消息元数据中写入keyToFetch lastIrrigationTime后进入related device attributes节点的消息定义如下{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationTime } }富集后输出的消息节点按关系查询找到关联的灌溉控制器设备将${keyToFetch}替换为lastIrrigationTime从该设备拉取服务端属性值并写入消息元数据。由于配置了Add selected attributes to: Metadata且服务端属性会以ss_前缀标识输出消息变为{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationTime, ss_lastIrrigationTime: 1685369440000 } }新增的ss_lastIrrigationTime元数据键携带了灌溉控制器上lastIrrigationTime属性的值时间戳形式后续的决策节点如脚本、switch 或 actuator 类节点即可直接读取该元数据判断是否启动灌溉。场景二的完整消息流脚本节点处理后匹配条件二soilMoisture 32.5 ≥ 30%且windSpeed 10.4 8 m/s{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationPauseTime } }富集后输出的消息这次节点拉取的是lastIrrigationPauseTime输出消息变为{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationPauseTime, ss_lastIrrigationPauseTime: 1685359440000 } }两个场景的对比可以清楚看到节点配置完全一致Server attributes 一栏始终是${keyToFetch}变化的只是消息元数据中的keyToFetch值。这正是字段模板化的价值——动态配置基于元数据字段的替换而生效。模板化输出键的前缀规则从上述两个输出示例可以总结出 ThingsBoard 富集属性节点的元数据键命名约定服务端属性server attributes写入元数据时使用ss_前缀如ss_lastIrrigationTime、ss_lastIrrigationPauseTime相应的客户端属性通常使用cs_前缀共享属性使用shared_前缀而最新遥测数据写入时按配置可能带时间戳信息。这些约定与TbGetAttributesNodeConfiguration中clientAttributeNames、sharedAttributeNames、serverAttributeNames、latestTsKeyNames的分类一一对应是下游节点解析富集结果时需要知晓的关键约定。与同类富集节点的横向对照字段模板化并非该节点独有仓库中同一批帮助文档还覆盖了同族节点均可对照学习originator_attributes_node_fields_templatization.md从消息发起者自身获取属性无需关系查询tenant_attributes_node_fields_templatization.md从租户实体获取属性customer_attributes_node_fields_templatization.md从客户实体获取属性related_entity_data_node_fields_templatization.md从关联实体获取属性和/或最新遥测originator_telemetry_node_fields_templatization.md从消息发起者获取最新遥测。区别在于数据来源不同related device attributes 通过deviceRelationsQuery先做关系解析方向、层级、关系类型、设备 Profile 过滤再把目标设备视作数据源而 originator/tenant/customer 系列直接以固定实体为数据源。选择哪个节点取决于数据在谁身上以及是否依赖设备间关系。使用建议与注意事项结合官方文档示例与源码实现在实际搭建规则链时可参考以下要点先由脚本或 switch 节点计算条件再写入keyToFetch等路由键把取哪个属性的决策前移让富集节点保持配置一致是模板化的典型用法关系查询务必精准Device relations query是必填项方向、层级、关系类型、设备 Profile 四项组合应能唯一定位目标设备。源码明确多个关联设备仅取第一个若存在歧义可能拉错设备属性缺失即失败的开关按需开启tellFailureIfAbsent开启后拉取不到配置的属性会走Failure分支适合需要严格保证数据完整性的告警/联动场景若业务允许缺省值可关闭该选项并将Failure分支接入兜底处理善用fetchTo选择存放位置示例均写入Metadata便于用metadata.ss_xxx在后续脚本中引用若需要直接改写消息体msg可选择Message通过 Debug 模式验证替换结果配置面板提供Debug mode开关可在调试视图中确认${keyToFetch}是否按预期替换为真实属性键快速定位模板拼写错误或元数据键不存在的问题。以上建议均可在 TbGetDeviceAttrNode.java 及其配置类、以及官方帮助文档 related_device_attributes_node_fields_templatization.md 与配图 related-device-attributes-ft.png 中对照验证动手配置时建议在 ThingsBoard 沙箱环境中逐节点调试。赞分享物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载相关推荐ThingsBoard 规则引擎字段模板化实战originator attributes 节点动态属性查询ThingsBoard 规则引擎字段模板化实战originator attributes 节点动态属性查询 导读 本文围绕 ThingsBoard 规则引擎中物联网后端数据可视化消息队列ThingsBoard 规则引擎 customer attributes 节点字段模板化Fields Templatization实战指南ThingsBoard 规则引擎 customer attributes 节点字段模板化Fields Templatization实战指南 customer物联网后端数据可视化消息队列ThingsBoard 规则引擎 Change Originator 节点字段模板化实战按消息元数据动态切换消息发起方ThingsBoard 规则引擎 Change Originator 节点字段模板化实战按消息元数据动态切换消息发起方 本指南围绕 ThingsBoard 规物联网后端数据可视化消息队列上一篇Inconsolata 字体程序员必备的终极等宽字体解决方案下一篇如何用3个步骤免费实现笔记迁移Obsidian Importer终极转换指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ThingsBoard 规则引擎 related device attributes 节点字段模板化实战：基于元数据动态获取关联设备属性
物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载导读related device attributes关联设备属性是 ThingsBoard 规则引擎中的一类富集Enrichment节点它负责根据消息来源设备与目标设备之间的关系查询从关联设备上拉取属性或最新遥测数据并注入到当前消息中供后续节点使用。本文以 ThingsBoard 官方帮助文档 related_device_attributes_node_fields_templatization.md 为核心围绕字段模板化Fields Templatization展开你将学会利用${metadataKey}、${messageKey}模板语法让节点配置在运行时动态化并掌握一个完整的智能灌溉场景实战案例——当土壤湿度跌破阈值时动态获取灌溉控制器的lastIrrigationTime属性当风速过高时获取lastIrrigationPauseTime属性。什么是字段模板化Fields Templatization在 ThingsBoard 规则引擎中部分节点尤其是富集类节点如 originator attributes、tenant attributes、customer attributes、related device attributes 等的输入字段支持模板化。所谓模板化是指在节点配置中不是写死某个固定的属性键名而是通过${...}占位符引用消息运行时携带的动态数据${messageKey}引用当前消息msg中的字段值${metadataKey}引用当前消息metadata中的字段值。当消息流经该节点时ThingsBoard 会先在运行时完成字符串替换再用替换后的结果作为真实的属性键、设备名或查询条件去执行数据拉取。这一机制让同一个节点配置可以被成千上万条携带不同上下文的消息复用而无需为每种情况单独搭建一条规则链。在官方帮助体系中这一通用能力被封装为common_node_fields_templatization片段并被上述多个富集节点的帮助文档共同引用说明模板化是 ThingsBoard 富集节点的一等公民能力。节点工作原理从源码看实现要理解字段模板化的底层支撑可以先定位该节点的核心实现。在仓库的规则引擎组件中该节点对应类为 TbGetDeviceAttrNode.java节点类型为ENRICHMENT富集名称related device attributes其职责是 Add originators related device attributes and/or latest telemetry values into message or message metadata——把与消息发起者存在关联关系的设备的属性/最新遥测写入消息或元数据关键逻辑通过EntitiesRelatedDeviceIdAsyncLoader.findDeviceAsync(ctx, msg.getOriginator(), config.getDeviceRelationsQuery())异步查找关联设备若按配置的关系查询找不到关联设备则抛出Failed to find related device to message originator using relation query specified in the configuration!并走Failure分支实现见 EntitiesRelatedDeviceIdAsyncLoader.java节点声明中明确若查找到多个关联设备仅取第一个用于消息富集其余设备被丢弃节点提供Success与Failure两个输出连接。节点配置类为 TbGetDeviceAttrNodeConfiguration.java其核心字段包括deviceRelationsQuery设备关系查询定义方向Direction、最大层级Max relation level、关系类型Relation type以及设备 Profile 过滤继承自 TbGetAttributesNodeConfiguration.java 的属性获取配置clientAttributeNames/sharedAttributeNames/serverAttributeNames客户端、共享、服务端属性键列表latestTsKeyNames最新遥测键列表tellFailureIfAbsent目标属性缺失时是否返回失败getLatestValueWithTs是否连同时间戳一起获取最新值fetchTo拉取结果写入DATA消息还是METADATA元数据默认METADATA。这些配置字段正是 UI 配置面板中各个输入框的落点也是模板化语法生效的载体——serverAttributeNames这类列表字段中的每一项都可以写成一个${...}模板。实战场景智能灌溉控制器的条件化数据获取官方帮助文档给出了一个非常具体的端到端示例假设我们有一台水分计设备消息发起者 originator它上报的遥测消息包含以下读数soilMoisture土壤湿度windSpeed风速windDirection风向temperature温度humidity空气湿度根据不同的环境条件我们需要从关联的灌溉控制器设备上获取不同的服务端属性条件一干旱临界当土壤湿度读数跌破 30% 阈值时被视为对作物健康和生长有直接影响的关键状态此时需要获取lastIrrigationTime属性以了解田地最近一次浇灌时间从而决定是否触发灌溉系统条件二大风暂停当土壤湿度高于 30%但风速超过 8 m/s 时需要获取lastIrrigationPauseTime属性以了解灌溉系统上次因大风而暂停的时间结合当前与历史气象条件做出更合理的灌溉决策。为此我们先编写一个脚本节点根据上述条件向消息元数据metadata中追加一个键keyToFetch其取值为lastIrrigationTimelastIrrigationPauseTime随后在related device attributes节点的Server attributes输入框中写入模板${keyToFetch}节点就会在运行时把metadata.keyToFetch的实际值替换进去从而动态决定拉取哪个服务端属性。节点配置面板解读官方文档配图 related-device-attributes-ft.png 展示了该场景下完整的节点配置界面关键配置项如下Name自定义节点名示例为fetch irrigation controller dataDevice relations query设备关系查询Direction方向示例选To即关系指向当前设备Max relation level最大关系层级设为1只取直接关联的一层设备Relation type关系类型配置为Manages管理关系Device profiles设备 Profile选择IrrigationController限定只关联该类型的设备Related device attributes关联设备属性Client attributes客户端属性示例中留空Shared attributes共享属性示例中留空Server attributes服务端属性配置模板${keyToFetch}Latest telemetry最新遥测示例中留空Add selected attributes to结果存放位置选中Metadata元数据Tell failure if any of the attributes are missing任一属性缺失即报失败已开启对应源码中的tellFailureIfAbsent字段保证拉不到属性时走Failure分支便于下游告警或重试。界面中的提示文本与源码字段一一对应例如所有输入字段支持模板化可通过${messageKey}提取消息值、${metadataKey}提取元数据正是对本文所述模板化机制的官方注解。场景一的完整消息流脚本节点处理后匹配条件一soilMoisture 28.9 30%脚本节点在消息元数据中写入keyToFetch lastIrrigationTime后进入related device attributes节点的消息定义如下{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationTime } }富集后输出的消息节点按关系查询找到关联的灌溉控制器设备将${keyToFetch}替换为lastIrrigationTime从该设备拉取服务端属性值并写入消息元数据。由于配置了Add selected attributes to: Metadata且服务端属性会以ss_前缀标识输出消息变为{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationTime, ss_lastIrrigationTime: 1685369440000 } }新增的ss_lastIrrigationTime元数据键携带了灌溉控制器上lastIrrigationTime属性的值时间戳形式后续的决策节点如脚本、switch 或 actuator 类节点即可直接读取该元数据判断是否启动灌溉。场景二的完整消息流脚本节点处理后匹配条件二soilMoisture 32.5 ≥ 30%且windSpeed 10.4 8 m/s{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationPauseTime } }富集后输出的消息这次节点拉取的是lastIrrigationPauseTime输出消息变为{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastIrrigationPauseTime, ss_lastIrrigationPauseTime: 1685359440000 } }两个场景的对比可以清楚看到节点配置完全一致Server attributes 一栏始终是${keyToFetch}变化的只是消息元数据中的keyToFetch值。这正是字段模板化的价值——动态配置基于元数据字段的替换而生效。模板化输出键的前缀规则从上述两个输出示例可以总结出 ThingsBoard 富集属性节点的元数据键命名约定服务端属性server attributes写入元数据时使用ss_前缀如ss_lastIrrigationTime、ss_lastIrrigationPauseTime相应的客户端属性通常使用cs_前缀共享属性使用shared_前缀而最新遥测数据写入时按配置可能带时间戳信息。这些约定与TbGetAttributesNodeConfiguration中clientAttributeNames、sharedAttributeNames、serverAttributeNames、latestTsKeyNames的分类一一对应是下游节点解析富集结果时需要知晓的关键约定。与同类富集节点的横向对照字段模板化并非该节点独有仓库中同一批帮助文档还覆盖了同族节点均可对照学习originator_attributes_node_fields_templatization.md从消息发起者自身获取属性无需关系查询tenant_attributes_node_fields_templatization.md从租户实体获取属性customer_attributes_node_fields_templatization.md从客户实体获取属性related_entity_data_node_fields_templatization.md从关联实体获取属性和/或最新遥测originator_telemetry_node_fields_templatization.md从消息发起者获取最新遥测。区别在于数据来源不同related device attributes 通过deviceRelationsQuery先做关系解析方向、层级、关系类型、设备 Profile 过滤再把目标设备视作数据源而 originator/tenant/customer 系列直接以固定实体为数据源。选择哪个节点取决于数据在谁身上以及是否依赖设备间关系。使用建议与注意事项结合官方文档示例与源码实现在实际搭建规则链时可参考以下要点先由脚本或 switch 节点计算条件再写入keyToFetch等路由键把取哪个属性的决策前移让富集节点保持配置一致是模板化的典型用法关系查询务必精准Device relations query是必填项方向、层级、关系类型、设备 Profile 四项组合应能唯一定位目标设备。源码明确多个关联设备仅取第一个若存在歧义可能拉错设备属性缺失即失败的开关按需开启tellFailureIfAbsent开启后拉取不到配置的属性会走Failure分支适合需要严格保证数据完整性的告警/联动场景若业务允许缺省值可关闭该选项并将Failure分支接入兜底处理善用fetchTo选择存放位置示例均写入Metadata便于用metadata.ss_xxx在后续脚本中引用若需要直接改写消息体msg可选择Message通过 Debug 模式验证替换结果配置面板提供Debug mode开关可在调试视图中确认${keyToFetch}是否按预期替换为真实属性键快速定位模板拼写错误或元数据键不存在的问题。以上建议均可在 TbGetDeviceAttrNode.java 及其配置类、以及官方帮助文档 related_device_attributes_node_fields_templatization.md 与配图 related-device-attributes-ft.png 中对照验证动手配置时建议在 ThingsBoard 沙箱环境中逐节点调试。赞分享物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载相关推荐ThingsBoard 规则引擎字段模板化实战originator attributes 节点动态属性查询ThingsBoard 规则引擎字段模板化实战originator attributes 节点动态属性查询 导读 本文围绕 ThingsBoard 规则引擎中物联网后端数据可视化消息队列ThingsBoard 规则引擎 customer attributes 节点字段模板化Fields Templatization实战指南ThingsBoard 规则引擎 customer attributes 节点字段模板化Fields Templatization实战指南 customer物联网后端数据可视化消息队列ThingsBoard 规则引擎 Change Originator 节点字段模板化实战按消息元数据动态切换消息发起方ThingsBoard 规则引擎 Change Originator 节点字段模板化实战按消息元数据动态切换消息发起方 本指南围绕 ThingsBoard 规物联网后端数据可视化消息队列上一篇Inconsolata 字体程序员必备的终极等宽字体解决方案下一篇如何用3个步骤免费实现笔记迁移Obsidian Importer终极转换指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
