一、筛选器（Filter）：

1、alarm status filter

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

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

每条告警有这 4 种状态

状态	英文	含义
活跃未确认	ACTIVE_UNACK	刚触发、没人处理（最需要通知）
活跃已确认	ACTIVE_ACK	已有人确认，但问题还在
已清除未确认	CLEARED_UNACK	问题恢复，但没人确认恢复
已清除已确认	CLEARED_ACK	问题恢复且已确认（闭环）	ThingsBoard

节点配置（最简）
在规则链里添加：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 的区别（别搞混）

节点	分流依据	生效对象	适用场景
Device Profile Switch	设备配置文件（Device Profile）	设备（Device）	传感器、电表、网关等设备数据分流
Asset Profile Switch	资产配置文件（Asset Profile）	资产（Asset）	工厂、办公楼、仓库等资产数据分流

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 组合

五、与相似节点对比

节点	过滤依据	输出	用途
Entity Type Filter	实体类型（Device/Asset）	True/False	布尔过滤，拦截非法类型
Entity Type Switch	实体类型	多支路（Device/Asset/...）	直接分流，各类型走各分支
Device Profile Switch	设备配置文件	多支路（按 Profile 名）	只对设备，按型号 / 类型分流

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（要放行的消息类型列表）
点击 + 添加需要放行的消息类型，支持多选

消息类型	含义
POST_TELEMETRY	设备上报遥测数据
POST_ATTRIBUTES	设备上报属性数据
RPC_REQUEST	设备 / 服务器 RPC 请求
ALARM	告警相关消息
ENTITY_CREATED	实体创建事件
ENTITY_UPDATED	实体更新事件

节点	输出逻辑	适用场景
Message Type Filter	布尔型：True/False 两路	只放行特定类型，其他全部拦截
Message Type Switch	多路分支：每个类型对应一条独立连线	按不同消息类型分别处理（遥测存库、属性更新触发告警）

10、message type switch

一、一句话作用

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

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

---

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

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

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

2. POST_ATTRIBUTES → 设备上报属性

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

4. TIMESERIES_UPDATED → 时序数据更新后

5. FAILURE → 其他类型 / 异常

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

消息类型 Message type	连线标签 Connection label	业务含义
POST_ATTRIBUTES_REQUEST	Post attributes	设备上报客户端属性
POST_TELEMETRY_REQUEST	Post telemetry	设备上报遥测数据（最常用）
TO_SERVER_RPC_REQUEST	RPC Request from Device	设备主动发 RPC 请求到平台
ACTIVITY_EVENT	Activity Event	设备在线活跃事件
INACTIVITY_EVENT	Inactivity Event	设备离线不活跃事件
CONNECT_EVENT	Connect Event	设备连接成功事件
DISCONNECT_EVENT	Disconnect Event	设备断开连接事件
ENTITY_CREATED	Entity Created	创建设备 / 资产 / 客户等实体
ENTITY_UPDATED	Entity Updated	实体信息更新
ENTITY_DELETED	Entity Deleted	实体被删除
ENTITY_ASSIGNED	Entity Assigned	实体被分配给客户 / 用户
ENTITY_UNASSIGNED	Entity Unassigned	实体解除分配
ATTRIBUTES_UPDATED	Attributes Updated	任何属性更新（服务端 / 共享 / 客户端）
ATTRIBUTES_DELETED	Attributes Deleted	属性被删除
ALARM_ACK	Alarm Acknowledged	告警被确认
ALARM_CLEAR	Alarm Cleared	告警被清除
ALARM_ASSIGNED	Alarm Assigned	告警被指派给处理人
ALARM_UNASSIGNED	Alarm Unassigned	告警取消指派
COMMENT_CREATED	Comment Created	新增备注
COMMENT_UPDATED	Comment Updated	备注修改
RPC_CALL_FROM_SERVER_TO_DEVICE	RPC Request to Device	平台下发 RPC 控制指令给设备
ENTITY_ASSIGNED_FROM_TENANT	Entity Assigned From Tenant	跨租户实体转入
ENTITY_ASSIGNED_TO_TENANT	Entity Assigned To Tenant	跨租户实体转出
TIMESERIES_UPDATED	Timeseries Updated	遥测时序数据更新
TIMESERIES_DELETED	Timeseries Deleted	遥测时序数据删除
RPC_QUEUED	RPC Queued	RPC 指令已入队列
RPC_SENT	RPC Sent	RPC 已下发
RPC_DELIVERED	RPC Delivered	RPC 已送达设备
RPC_SUCCESSFUL	RPC Successful	RPC 设备执行成功
RPC_TIMEOUT	RPC Timeout	RPC 超时
RPC_EXPIRED	RPC Expired	RPC 过期
RPC_FAILED	RPC Failed	RPC 执行失败
RPC_DELETED	RPC Deleted	RPC 指令被删除
RELATIONS_DELETED	All Relations Deleted	实体所有关系被清空
RELATION_ADD_OR_UPDATE	Relation Added or Updated	实体关系新增 / 修改
RELATION_DELETED	Relation Deleted	单条实体关系删除
REST_API_REQUEST	REST API request	外部调用 TB RESTAPI 事件
OWNER_CHANGED	Owner changed	实体所属所有者变更
ADDED_TO_ENTITY_GROUP	Added to Group	实体加入分组
REMOVED_FROM_ENTITY_GROUP	Removed from Group	实体移出分组
generateReport	Generate Report	生成报表事件

日常做规则链只需要记这几个高频
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 节点，性能更高、配置更简单。