tthingsboard规则链（基于社区版本）

一、筛选器（Filter）：

1、alarm status filter

将入站负载解析为ThingsBoard告警，按ID获取最新告警，并将其当前状态与配置的状态集合比对。 若获取的状态匹配，消息经True路由；否则经False路由。解析错误、缺少告警ID或不存在的告警会导致Failure。

专门对告警消息按当前告警状态做过滤，决定是否继续往下发（通知、脚本、转发等）T
适用场景：
只在新告警 / 未确认告警时发邮件 / 短信
已确认告警不再重复通知
告警清除时触发恢复逻辑
只统计活跃告警、不处理已清除告警

每条告警有这 4 种状态

节点配置（最简）
在规则链里添加：Alarm Status Filter
配置里勾选要放行的状态，例如：
只通知新告警：勾选 Active Unacknowledged
处理所有活跃告警：勾选 Active Unacknowledged + Active Acknowledged
处理恢复：勾选 Cleared Unacknowledged / Acknowledged

输出连线：
True：状态匹配，往下走（发邮件 / 脚本）
False：不匹配，丢弃
Failure：告警不存在 / 解析错误ThingsBoard

2、Asset Profile Switch

Asset Profile Switch（资产配置分发） 节点的核心作用是：根据消息来源资产（Asset）绑定的「资产配置文件（Asset Profile）」，自动将消息路由到不同的规则链分支。
它本质上是一个资产类型的分流器，专门针对资产数据做逻辑分发，和设备用的 Device Profile Switch 是一对，分别处理资产和设备的分流需求。

消息处理逻辑

1. 检查入站消息的来源实体类型是否为ASSET。

   1. 若不是ASSET，则以Failure结束处理。

2. 从数据库获取该资产的配置以得到配置名称。

   1. 若未找到配置（例如消息处理时来源实体已不存在），则以Failure结束处理。

3. 使用标签与获取的配置名称完全匹配的连接将入站消息路由至下游节点。

输出连接

• 资产配置名称：

  • 当入站消息的来源实体类型为ASSET且已找到该资产的配置时。

• Failure：

  • 当入站消息的来源实体类型不是ASSET时。

  • 当未找到入站消息来源实体的配置时。

  • 消息处理过程中发生其他意外错误时。

3、check fields presence

Check Fields Presence 是 ThingsBoard 社区版（CE）中一个非常实用的过滤器节点，核心作用是检查消息中是否存在指定字段，并根据结果分流。

一、核心作用
检查消息中是否包含你配置的所有字段
字段全部存在 → 走 Success 分支
任意一个字段缺失 → 走 Failure 分支
仅检查字段是否存在，不校验字段值是否合法（如是否为空、是否为数字）
二、配置与使用步骤
添加节点：在规则链中搜索并添加 Check Fields Presence
配置字段列表：在节点配置界面，点击 + 添加需要校验的字段名（如 temperature、humidity）
支持添加多个字段，节点会同时校验所有字段
字段名大小写敏感，必须和消息体中的字段名完全一致
设置输出分支：
Success：连接后续处理节点（如 Save Telemetry、告警节点）
Failure：连接丢弃或日志节点，过滤无效数据

4、check relation presence

根据配置的方向和关系类型，检查入站消息来源实体与另一实体（任意实体或指定实体）之间是否存在关系。

这个节点是干嘛的？（一句话）
Check Relation Presence = 检查当前设备 / 资产 是否 与另一个实体（设备 / 资产 / 用户）存在指定关系
存在关系 → 走 True
不存在关系 → 走 False
它不创建关系、不删除关系，只检查关系有没有。
适用场景（你一定会用到）
只有设备属于某个资产时，才执行告警
只有设备关联了网关时，才转发数据
只有设备绑定了用户时，才发邮件
数据权限校验：根据关系判断是否继续处理
一句话：按实体关系来分流消息

5、device profile switch

Device Profile Switch 是社区版（CE）原生自带的核心分流节点，和你之前了解的 Asset Profile Switch 是一对，专门用于按设备配置文件（Device Profile）分流消息，是设备类数据路由的基础节点。
一、核心作用（一句话）
根据消息来源设备绑定的「设备配置文件（Device Profile）」，自动将消息分发到不同的规则链分支。
它本质是设备版的 “类型分流器”，替代了旧版 “设备类型” 的分流逻辑
仅对 ** 设备（Device）** 消息生效，资产（Asset）消息会直接走 Failure 分支
社区版功能完整，无企业版限制
二、关键配置与使用步骤
1. 前置准备（必须先完成）
进入 Profiles → Device Profiles，创建设备配置文件（例如 Temperature_Sensor、Energy_Meter）
给对应的设备绑定目标 Device Profile（设备详情页 → 编辑 → 配置文件）
2. 节点核心配置
这个节点本身无额外参数需要配置，逻辑完全通过输出连线标签实现：
在规则链中添加 Device Profile Switch 节点
从节点拖出多条输出连线，将连线的标签修改为设备配置文件的完整名称（大小写敏感）
不同连线对应不同的 Device Profile，消息会自动路由到匹配的分支
不匹配的消息、非设备消息会自动进入 Failure 分支
三、典型应用场景
按设备类型走不同业务逻辑
温度传感器：走高 / 低温告警、温湿度统计规则链
电表设备：走能耗增量计算、用电异常告警规则链
网关设备：走子设备数据转发、在线状态监控规则链
数据分类存储 / 转发
关键设备数据写入高优先级存储，普通设备数据仅本地缓存
特定 Profile 的设备数据转发到第三方平台，其他设备不转发
复杂规则链拆分
在根规则链中用该节点做一级分流，将不同 Profile 的设备数据转发到独立的子规则链，避免主链逻辑臃肿，便于维护和调试

四、和 Asset Profile Switch 的区别（别搞混）

6、entity type filter

将入站消息的来源实体类型与配置的实体类型集合进行比对。若类型在集合中，消息经 True 路由；否则经 False 路由。

一、核心用途
判断消息是谁发的：**Device（设备）/Asset（资产）/User（用户）/Customer（客户）** 等ThingsBoard
只让指定类型实体的消息通过
与 Entity Type Switch 区别：
Filter：布尔型（True/False）
Switch：直接按类型分多支路（Device/Asset/...）ThingsBoard
二、配置（超简单）
添加节点 → 打开配置
Select entity types：勾选要放行的实体类型（至少选一个）
常用：Device、Asset

三、输出三条线
True：消息来源类型在勾选列表里 → 放行
False：不在列表里 → 拦截
Failure：出错（实体不存在、配置错误）
四、典型场景
1. 只处理设备上报，忽略资产 / 用户消息
勾选：Device
设备数据 → True → 继续（存库、告警）
资产 / 用户数据 → False → 丢弃
2. 同时处理设备 + 资产数据
勾选：Device + Asset
设备 / 资产 → True → 统一处理
用户 / 客户 → False → 拦截
3. 与 Device Profile Switch 组合

五、与相似节点对比

7、entity type switch

根据来源实体类型路由入站消息。消息经其标签与实体类型规范名称完全匹配的输出连接转发。

一、核心作用（大白话）
Entity Type Switch = 按消息来源「实体类型」自动多路分流
自动识别这条消息是谁发来的：
设备 Device
资产 Asset
客户 Customer
用户 User
不同实体类型自动走各自独立分支，不用写脚本，纯可视化分流。
✅ 社区版 CE 原生自带，完全可用。
二、和 Entity Type Filter 区别（必记）
Entity Type Filter：只做二选一 True / False
Entity Type Switch：做多路分支，Device 走一条、Asset 走一条、其他走 Failure
三、节点自带输出分支
不用自己定义，拖线直接选：
DEVICE
ASSET
CUSTOMER
USER
FAILURE（都不是、解析异常）
消息是什么实体，自动跑进对应分支。

8、gps geofencing filter

提取消息里的经纬度，判断设备 / 资产是否在指定圆形 / 多边形围栏内，输出 True/False/Failure 三路。

一、核心原理
从消息 data 或 metadata 取出经纬度（默认字段：latitude/longitude）ThingsBoard
按配置的 ** 圆形（Circle）或多边形（Polygon）** 围栏做点 - in - 区域判断ThingsBoard
在围栏内 → True；不在 → False；解析失败 / 缺坐标 → Failure
二、配置详解（界面 + 参数）
1. 基础坐标配置
Latitude field name：纬度字段名（默认 latitude）
Longitude field name：经度字段名（默认 longitude）
查找顺序：先 message.data → 无则 message.metadataThingsBoard

ss_perimeter字段格式要求

metadata.ss_perimeter必须是一个 JSON 格式的多边形坐标数组，格式如下：

json

[ [31.2304, 121.4737], [31.2314, 121.4747], [31.2324, 121.4737], [31.2304, 121.4737] ]

2. 围栏类型（Perimeter Type）
🔵 Circle（圆形，简单常用）
关闭「Fetch perimeter from metadata」时静态配置：
Center Lat/Lon：圆心经纬度
Range：半径（如 500）
Range units：单位（Meter/Kilometer 等）

当 Perimeter type 为 Circle 时，metadata.ss_perimeter 必须是一个 JSON 对象，格式如下：
json
{
"centerLatitude": 31.2304,
"centerLongitude": 121.4737,
"range": 500,
"rangeUnit": "METER"
}
centerLatitude：圆心纬度
centerLongitude：圆心经度
range：半径数值
rangeUnit：单位，支持 METER / KILOMETER / FOOT / MILE

9、message type filter

核心作用是：根据消息的 msgType（消息类型）进行过滤，匹配则放行，不匹配则拦截。
一、核心作用与适用场景
核心作用
判断当前消息的类型是否匹配你配置的列表，输出三路结果：
True：消息类型在配置列表中 → 放行
False：消息类型不在配置列表中 → 拦截
Failure：解析错误 / 消息无类型 → 异常分支
典型场景
数据清洗分流：只处理设备遥测上报（POST_TELEMETRY），过滤掉属性更新、RPC 请求等其他类型消息
告警前置校验：仅对设备属性变更（POST_ATTRIBUTES）触发特定告警逻辑
规则链瘦身：在根链入口快速过滤无效消息，避免后续节点资源浪费

二、社区版配置与使用步骤
1. 节点配置界面
配置项只有一个核心选项：Message types（要放行的消息类型列表）
点击 + 添加需要放行的消息类型，支持多选

10、message type switch

一、一句话作用

Message Type Switch = 按消息类型自动多路分流它会自动识别消息是什么类型，然后自动走不同的分支。

这是规则链最最常用的第一层分流节点！

二、它会自动分出哪些固定分支？

不用配置，拖出来就自带 5 个输出口：

1. POST_TELEMETRY→ 设备上报遥测（温度、湿度、GPS…）

2. POST_ATTRIBUTES→ 设备上报属性

3. RPC_REQUEST→ 设备 / 平台 RPC 指令

4. TIMESERIES_UPDATED→ 时序数据更新后

5. FAILURE→ 其他类型 / 异常

消息是什么类型，就自动进哪条线。

日常做规则链只需要记这几个高频
Post telemetry：设备温湿度 / GPS / 能耗上报
Post attributes：设备上报自身属性
RPC Request from Device：设备主动请求平台
RPC Request to Device：平台下发控制设备
Connect / Disconnect：上下线监控
Activity / Inactivity Event：心跳离线告警
ATTRIBUTES_UPDATED：服务端属性变更触发逻辑
ALARM_ACK / ALARM_CLEAR：告警确认、清除联动
其他都是后台系统事件，常规物联网项目基本用不到。

11、script

一、TB 里 Script 分两种
TBEL（推荐，TB 自研表达式语言，性能高、安全、社区版首选）
JavaScript（灵活但性能差、有沙箱限制，不推荐乱用）
常用三个带脚本的节点：
Script Filter：脚本判断 → 返回 true/false 做过滤分流
Script Transformation：脚本修改 msg 结构体、计算字段
Check Fields + 逻辑判断 复杂校验都能用脚本代替
二、脚本内置固定变量（必记）
plaintext
msg // 消息体 JSON 对象
metadata // 元数据
msgType // 消息类型字符串
三、Script Filter 常用示例（过滤用）
1. 温度范围过滤
js
// TBEL / JS 通用
return msg.temperature != null
&& msg.temperature >= -40
&& msg.temperature <= 80;
2. 字段必须存在
js
return msg.temperature !== undefined && msg.humidity !== undefined;
3. 只允许设备，过滤资产
js
return metadata.entityType === 'DEVICE';

12、switch

一、节点核心作用
它本质上是一个可编程的多路分支节点，你可以通过脚本定义任意分流条件，然后为每个分支设置独立的连线标签。
你可以用它实现和 Message Type Switch、Device Profile Switch 相同的效果，也可以实现更复杂的自定义分流逻辑。

二、工作原理与配置
1. 核心逻辑
你需要编写一段脚本，返回一个字符串（分支名称）。
节点根据返回的字符串，将消息路由到标签与该字符串完全匹配的输出连线。
如果没有匹配的连线，或脚本执行出错，消息会走 Failure 分支。
2. 配置步骤
双击节点，进入配置界面。
在脚本编辑器中，编写分流逻辑。
从节点拖出多条输出连线，并将每条连线的标签设置为你脚本中可能返回的分支名称。

三、脚本示例
示例 1：模拟 Message Type Switch 功能
javascript
运行
// 根据消息类型分流
switch (msgType) {
case 'POST_TELEMETRY_REQUEST':
return 'telemetry';
case 'POST_ATTRIBUTES_REQUEST':
return 'attributes';
default:
return 'other';
}

关键注意事项
脚本返回值必须是字符串，且必须和连线标签完全一致（大小写敏感）。
脚本执行错误或返回值为空，消息会直接进入 Failure 分支。
虽然功能强大，但对于简单场景，优先使用专用的 Switch 节点，性能更高、配置更简单。