物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载导读本文围绕 ThingsBoard 规则引擎中originator attributes源属性节点与字段模板化Fields templatization特性的配合使用展开。字段模板化允许在规则节点配置字段中写入${messageKey}、${metadataKey}形式的模板节点运行时将模板替换为消息数据或消息元数据中的实际值从而实现一条规则配置动态适配多种输入场景。读者读完本文后将掌握模板语法规则、originator attributes 节点的配置方式、fetchTo/tellFailureIfAbsent等关键参数的作用并通过一个完整的智能灌溉土壤湿度监测实例学会用脚本节点动态决定要查询哪个属性、再由 originator attributes 节点完成动态取值的完整实战方案。本主题对应的原始文档位于 originator_attributes_node_fields_templatization.md其中引用的通用模板说明见 common_node_fields_templatization.md节点后端实现位于 TbGetAttributesNode.java。一、什么是字段模板化字段模板化Fields templatization是 ThingsBoard 规则引擎的一项通用能力它允许你在处理传入消息时用动态配置处理消息——即将配置字段中指定的模板替换为消息message或消息元数据message metadata中的实际值。这套机制适用于所有在配置中声明了模板化支持的规则节点originator attributes 节点只是其中之一。仓库中同一目录下还有 originator telemetry、related device attributes、tenant/customer attributes、change originator 等节点的模板化示例文档它们共用同一套模板语法。模板语法模板写法含义${messageKey}从**消息体msg**中取值messageKey可以是多级 JSON 路径如${msg.temperature}${metadataKey}从**消息元数据metadata**中取值${[*]}替换为整个消息体JSON 字符串从源码实现看模板解析由 TbNodeUtils.java 的processPattern/processPatterns完成其中DATA_PATTERN正则(\$\[)(.*?)(])匹配消息体取值模板ALL_DATA_TEMPLATE即$[*]表示整个消息体。对于属性名列表这类配置originator attributes 节点在运行时正是通过TbNodeUtils.processPatterns(config.getClientAttributeNames(), msg)、processPatterns(config.getServerAttributeNames(), msg)等调用将模板列表逐一替换为实际键名后再发起属性查询。使用前提模板中引用的键必须存在于当前消息或元数据中否则替换结果为空可能导致查询不到任何属性模板化主要面向配置中的属性键名属性类型客户端/共享/服务端、查询结果写入位置Message/Metadata等节点级选项仍是静态配置替换发生在节点执行时onMsg阶段因此完全由每条消息的实时内容驱动天然适合一条配置、多态取键的场景。二、originator attributes 节点从源实体读取属性并注入消息originator attributes 节点的后端实现是 TbGetAttributesNode.java它继承自 TbAbstractGetAttributesNode.java。节点声明为ENRICHMENT富化类型官方描述为为消息源originator的属性/最新遥测数据添加到消息或消息元数据。它在富化阶段从消息源实体读取属性并按配置写入后续消息处理流程典型的应用场景是消息本身未包含某些属性但后续过滤/转换/告警节点需要这些属性值例如按属性中的阈值过滤消息。可查询的数据类型与注入前缀节点支持从源实体读取以下四类数据读取后写入消息fetchTo Message或元数据fetchTo Metadata配置字段数据来源写入目标键前缀clientAttributeNames客户端属性Client attributes由设备上报cs_sharedAttributeNames共享属性Shared attributesshared_serverAttributeNames服务端属性Server attributes由平台侧设置ss_latestTsKeyNames最新遥测值Latest telemetrykey 对应的最新一条时序数据无前缀原键名前缀规则在 TbAbstractGetAttributesNode.java 的getPrefix(String scope)方法中定义与DataConstants.CLIENT_SCOPE、SHARED_SCOPE、SERVER_SCOPE三个常量对应。例如服务端属性lastIrrigationTime被写入元数据后键名为ss_lastIrrigationTime这与下文示例输出完全一致。关键配置项说明Attributes/Timeseries keys要读取的键名列表支持输入多个键支持模板化即本文主题。前端配置组件 originator-attributes-config.component.html 中的属性选择器提示所有输入字段支持模板化语法${messageKey}提取消息内值、${metadataKey}提取元数据内值。配置表单要求四类数据中至少填写一类否则无法保存对应atLeastOneRequired校验。Add originator attributes tofetchTo结果写入位置可选Message消息体或Metadata元数据默认值为Metadata。该默认值定义在 TbGetAttributesNodeConfiguration.java。Tell failure if any of the attributes are missingtellFailureIfAbsent开关默认开启。开启后若所请求的属性/遥测键在数据库中不存在节点会走Failure分支并报错关闭后缺失的键会被静默跳过。实现细节见safePutAttributes与getLatestTelemetry中的isTellFailureIfAbsent判定逻辑缺失键会汇总进failuresPairSet并最终通过reportFailures抛出The following attribute/telemetry keys is not present in the DB异常。Get latest value with tsgetLatestValueWithTs仅对最新遥测查询生效开启后每个遥测键返回{ts: ..., value: ...}结构的 JSON 对象否则直接返回值。默认关闭详见 TbGetAttributesNodeConfiguration.java。节点工作流程源码视角onMsg接收消息先确定fetchTo目标Data 时需先将消息体转为 ObjectNode 以便后续合并findEntityIdAsync返回消息源实体 IDmsg.getOriginator()对四类数据源并行发起异步查询Futures.allAsList键名列表均先经processPatterns做模板替换查询结果按各自前缀写入消息体或元数据副本全部成功后tellSuccess走Success分支存在缺失键且tellFailureIfAbsent开启时走Failure分支。节点仅有两个输出连接Success与Failure这在节点描述中已明确声明。三、完整实战示例根据土壤湿度/风速动态获取服务端属性以下示例完整继承自 originator_attributes_node_fields_templatization.md并通过源码佐证加以说明。3.1 业务场景假设有一台土壤湿度计moisture meter设备它是消息源message originator持续上报包含以下读数的遥测消息soilMoisture土壤湿度windSpeed风速windDirection风向temperature温度humidity湿度根据不同条件我们需要从该设备上额外获取不同的服务端属性当soilMoisture读数低于阈值30%时对作物健康与生长构成直接影响视为关键情况需要获取lastIrrigationTime上次灌溉时间据此判断田地上次浇水时间并采取行动例如启动灌溉系统当土壤湿度高于临界阈值时则检查另一个条件若windSpeed超过8 m/s需要获取lastWindSpeedAlarmTime上次大风告警时间据此了解上一次显著大风事件的发生时刻判断是否有风暴或破坏性大风临近。3.2 脚本节点动态决定要查询的键我们在规则链中先放置一个script 节点它按上述条件逻辑为消息元数据添加一个键keyToFetch其值取二者之一lastIrrigationTimelastWindSpeedAlarmTime3.3 消息定义脚本节点处理后的输入满足第一个条件soilMoisture 30%的消息经脚本节点处理后如下{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: SN-001, ts: 1685379440000, keyToFetch: lastIrrigationTime } }满足第二个条件soilMoisture≥ 30% 且windSpeed 8 m/s的消息如下{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: SN-001, ts: 1685379440000, keyToFetch: lastWindSpeedAlarmTime } }3.4 originator attributes 节点配置模板化取键在规则链中紧随脚本节点之后放置originator attributes节点配置如下节点名称fetch lastIrrigationTime or lastWindSpeedAlarmTime服务端属性Server attributes键名填写模板${keyToFetch}客户端属性 / 共享属性 / 最新遥测留空Add originator attributes to选择MetadataTell failure if any of the attributes are missing开启保证查询不到属性时能显式失败便于排查。这条配置的精髓在于服务端属性键名被模板化为${keyToFetch}节点运行时由TbNodeUtils.processPatterns将模板替换为当前消息元数据中keyToFetch的实际值从而同一节点配置无需修改即可按消息内容动态决定查询lastIrrigationTime还是lastWindSpeedAlarmTime。3.5 处理后的输出消息第一条消息条件一经节点处理后服务端属性lastIrrigationTime被读取并以ss_前缀写入元数据{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 28.9, windSpeed: 8.2, windDirection: NNE }, metadata: { deviceType: default, deviceName: SN-001, ts: 1685379440000, keyToFetch: lastIrrigationTime, ss_lastIrrigationTime: 1685369440000 } }第二条消息条件二经节点处理后元数据中新增ss_lastWindSpeedAlarmTime{ msg: { temperature: 26.5, humidity: 75.2, soilMoisture: 32.5, windSpeed: 10.4, windDirection: NNE }, metadata: { deviceType: default, deviceName: MM-001, ts: 1685379440000, keyToFetch: lastWindSpeedAlarmTime, ss_lastWindSpeedAlarmTime: 1685359440000 } }注意属性被写入元数据而非消息体因此消息体msg保持不变后续节点可通过${ss_lastIrrigationTime}、${ss_lastWindSpeedAlarmTime}等模板引用这些值继续处理如判断时间戳距今是否超过某阈值以触发告警。3.6 示例总结该示例完整展示了originator attributes 节点基于元数据字段替换实现动态配置的核心用法用脚本节点把取哪个属性的决策下沉到消息元数据在 originator attributes 节点的服务端属性键名中使用${keyToFetch}模板节点运行时自动完成模板替换、异步查询、按前缀ss_注入元数据三个步骤。这种配置模板化 数据驱动取键的组合避免为每个属性单独创建规则节点显著降低规则链复杂度尤其适合属性键随业务条件动态变化的场景。四、进阶要点与注意事项模板替换失败时及时暴露模板引用的键不存在时替换结果为空若此时tellFailureIfAbsent为开启状态节点会走 Failure 分支并在日志中列出The following attribute/telemetry keys is not present in the DB及缺失的键按 scope 归类可据此快速定位配置或数据问题。前缀冲突风险客户端/共享/服务端属性写入时分别带cs_、shared_、ss_前缀。若某键名本身以cs_开头同时又将客户端属性与该键同名会出现键名冲突后写入值覆盖先写入值。规划键名时应避开保留前缀。多级 JSON 路径消息体取值模板支持点号路径如${msg.temperature}可从嵌套 JSON 消息中提取值而元数据取值通常为单层键。具体能力受TbNodeUtils.processPattern的正则与解析逻辑约束。查询范围限定为消息源实体originator attributes 只查询**当前消息的源实体originator**的属性如需查询其他相关设备的属性应使用related device attributes节点其模板化示例见 related_device_attributes_node_fields_templatization.md。版本兼容节点配置结构经历过一次升级——旧的fetchToData布尔属性被替换为fetchTo枚举Message/Metadata升级逻辑位于 TbGetAttributesNode.java 的upgrade方法中旧版本规则链会自动迁移无需手动干预。五、小结字段模板化是 ThingsBoard 规则引擎实现数据驱动动态配置的关键机制而 originator attributes 节点是它的典型载体之一。通过${messageKey}/${metadataKey}模板规则节点配置从写死的一组键名进化为由每条消息内容实时决定的一组键名配合脚本节点可以构建出高度灵活、可复用的规则链。本文以土壤湿度计场景完整演示了从消息条件判断、动态写入keyToFetch到 originator attributes 节点模板化查询并注入ss_前缀属性的全流程。在此基础上同一套模板语法还可扩展到最新遥测查询见 originator_telemetry_node_fields_templatization.md、租户/客户属性见 tenant_attributes_node_fields_templatization.md、customer_attributes_node_fields_templatization.md以及改变消息源身份等更多场景是构建复杂物联网自动化规则的通用利器。赞分享物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载相关推荐OneUptime 事件Incident设置与自动化模板、自定义字段与规则引擎实战指南OneUptime 事件Incident设置与自动化模板、自定义字段与规则引擎实战指南 本文聚焦 OneUptime 开源可观测平台中 Incidents可观测性后端运维前端云原生微服务AI AgentANTLR4 动作与属性Actions Attributes完全指南$label、规则属性与动态作用域实战ANTLR4 动作与属性Actions Attributes完全指南$label、规则属性与动态作用域实战 Actions动作是嵌入在 ANTLR开发工具编程语言编译器MyBatis-Plus 动态字段查询优化实践MyBatis Plus 动态字段查询优化实践 在实际业务开发中我们经常会遇到需要根据条件动态控制大字段查询的场景。例如某些大文本字段或二进制字段在特定业务后端ORM代码生成上一篇三步搞定微信聊天永久保存WeChatMsg零基础实战指南下一篇PaddleSeg × FastDeploy语义分割模型从导出到服务化部署的完整工程实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考