1.预定义消息类型
| 消息类型 | 显示名称 | 描述 | 消息元数据 | 消息的有效载荷 |
| POST_ATTRIBUTES _REQUEST | Post attributes | 设备请求发布客户端属性 | deviceName - 发起设备名称, deviceType - 发起设备类型 | key/value json:{ |
| POST_TELEMETRY _REQUEST | Post telemetry | 设备请求发布遥测数据 | deviceName - 发起设备名称, deviceType - 发起设备类型, ts - 时间戳(毫秒) | key/value json:{ |
| TO_SERVER_RPC _REQUEST | RPC Request from Device | 来自设备的RPC请求 | deviceName - 发起设备名称, deviceType - 发起设备类型, requestId - 客户端提供的 RPC 请求 ID | 包含方法和参数的json :{ |
| RPC_CALL_FROM _SERVER_TO_ DEVICE | RPC Request to Device | 从服务器到设备的RPC请求 | requestUUID - Sustem 使用的内部请求 ID,用于识别回复目标, expirationTime - 请求过期的时间, oneway - 指定请求类型:true - 无响应,false - 有响应 | 包含方法和参数的json :{ |
| ACTIVITY_EVENT | Activity Event | 指示设备变为活动的事件 | deviceName - 发起设备名称, deviceType - 发起设备类型 | 包含设备活动信息的json:{ |
| INACTIVITY_EVENT | Inactivity Event | 指示设备变为非活动状态的事件 | deviceName - 发起设备名称, deviceType - 发起设备类型 | 包含设备活动信息的 json |
| CONNECT_EVENT | Connect Event | 设备连接时产生的事件 | deviceName - 发起设备名称, deviceType - 发起设备类型 | 包含设备活动信息的 json |
| DISCONNECT_EVENT | Disconnect Event | 设备断开连接时产生的事件 | deviceName - 发起设备名称, deviceType - 发起设备类型 | 包含设备活动信息的 json |
| ENTITY_CREATED | Entity Created | 系统中创建新实体时产生的事件 | userName - 创建实体的用户的名称, userId - 用户 ID | 包含所创建实体详细信息的 json:{ |
| ENTITY_UPDATED | Entity Updated | 现有实体更新时产生的事件 | userName - 更新实体的用户的名称, userId - 用户 ID | json 包含更新后的实体详细信息 |
| ENTITY_DELETED | Entity Deleted | 删除现有实体时产生的事件 | userName - 删除实体的用户的名称, userId - 用户 ID | json 包含已删除实体的详细信息 |
| ENTITY_ASSIGNED | Entity Assigned | 将现有实体分配给客户时产生的事件 | userName - 执行分配操作的用户的名称, userId - 用户 ID, assignedCustomerName - 分配的客户名称, assignedCustomerId - 分配客户的 ID | json 包含分配的实体详细信息 |
| ENTITY_ UNASSIGNED | Entity Unassigned | 当现有实体从客户取消分配时产生的事件 | userName - 执行取消分配操作的用户的名称, userId - 用户 ID, unassignedCustomerName - 未分配的客户名称, unassignedCustomerId - 未分配客户的 ID | json 包含未分配实体的详细信息 |
| ADDED_TO_ ENTITY_GROUP | Added to Group | 当实体被添加到实体组时产生的事件。此消息类型特定于ThingsBoard PE。 | userName - 执行分配操作的用户的名称, userId - 用户 ID, addedToEntityGroupName - 实体组名称, addedToEntityGroupId - 实体组 ID | 空的 JSON 负载 |
| REMOVED_FROM _ENTITY_GROUP | Removed from Group | 当实体从实体组中删除时产生的事件。此消息类型特定于ThingsBoard PE。 | userName - 执行取消分配操作的用户的名称, userId - 用户 ID, removedFromEntityGroupName - 实体组名称, removedFromEntityGroupId - 实体组 ID | 空的 JSON 负载 |
| ATTRIBUTES_ UPDATED | Attributes Updated | 执行实体属性更新时产生的事件 | userName - 执行属性更新的用户的名称, userId - 用户 ID, scope - 更新的属性范围(可以是SERVER_SCOPE或SHARED_SCOPE) | 具有更新属性的键/值 json:{ |
| ATTRIBUTES_ DELETED | Attributes Deleted | 当某些实体属性被删除时产生的事件 | userName - 删除属性的用户的名称, userId - 用户 ID, scope - 删除的属性范围(可以是SERVER_SCOPE或SHARED_SCOPE) | |
| ALARM | Alarm event | 创建、更新或删除警报时产生的事件 | 原始消息元数据中的所有字段 isNewAlarm - 如果刚刚创建了新警报,则为 true isExistingAlarm - 如果警报已经存在,则为 true isClearedAlarm - 如果警报已被清除,则为 true | 包含已创建警报详细信息的 json:{ |
| ALARM_ASSIGNED | Alarm Assigned | 当警报被分配给某个用户时产生的事件 | 原始消息元数据中的所有字段 entityName - 警报名称 entityType - 警报 userEmail - 用户电子邮件 userFirstName - 用户名字 userId - 用户 ID userLastName - 用户姓氏 userName - 用户名 | 包含报警详细信息的json |
| ALARM_ UNASSIGNED | Alarm Unassigned | 当用户取消分配警报时产生的事件 | 原始消息元数据中的所有字段 entityName - 警报名称 entityType - 警报 userEmail - 用户电子邮件 userFirstName - 用户名字 userId - 用户 ID userLastName - 用户姓氏 userName - 用户名 | 包含报警详细信息的json |
| COMMENT_ CREATED | Comment Created | 创建警报注释时产生的事件 | 原始消息元数据中的所有字段 userId - 用户 ID userName - 用户名 userFirstName - 用户名字 userLastName - 用户姓氏 userEmail - 用户电子邮件 comment - 包含评论详情和评论文本的 json 对象 | 包含报警详细信息的json |
| COMMENT_UPDATED | Comment Updated | 警报注释更新时产生的事件 | 原始消息元数据中的所有字段 userId - 用户 ID userName - 用户名 userFirstName - 用户名字 userLastName - 用户姓氏 userEmail - 用户电子邮件 comment - 包含评论详情和评论文本的 json 对象 | 包含报警详细信息的json |
| REST_API_REQUEST | REST API Request to Rule Engine | 用户执行 REST API 调用时产生的事件 | requestUUID - 唯一请求 ID, expirationTime - 请求的过期时间 | 带有请求有效载荷的 json |
2.规则节点类型
1)过滤节点(用于消息过滤和路由)
1.asset profile switch(资产配置切换)
根据资产配置文件的名称路由传入消息。资产配置文件名称区分大小写。
注意:规则节点的输出连接与资产配置文件名称相对应。例如:“冷冻室”、“建筑物”等。
输出连接:
- “冷冻室”/“建筑物”/等:
- 如果消息成功路由,则关系类型与资产配置文件名称相对应。
- 失败:
- 如果消息发起者的实体不是资产。
- 如果消息发起者没有分配资产配置文件。
- 如果在消息处理过程中发生意外错误。
使用示例:
经验丰富的平台用户会利用资产配置文件,并为每个资产配置文件配置特定的规则链。这有助于自动路由平台生成的消息:实体已创建、实体已删除、属性已更新等。但大多数消息源自传感器数据。假设我们在房间资产中安装了温度传感器,其配置文件分别为“冷冻室”和“锅炉房”。我们还假设房间资产与类型为“包含”的温度设备之间存在关联。以下规则链会将消息的发起者从设备更改为相关资产,并将传入消息路由到“冷冻室”或“锅炉房”规则链。
2.device profile switch(设备配置文件转换)
根据设备配置文件的名称路由传入消息。设备配置文件名称区分大小写。
注意:规则节点的输出连接与设备配置文件名称相对应。例如:“温度传感器”、“湿度传感器”等。
输出连接:
- “温度传感器”/”湿度传感器”等:
- 如果消息成功路由,则关系类型与设备配置文件名称相对应。
- 失败:
- 如果消息发起者的实体不是设备。
- 如果消息发起者没有分配设备配置文件。
- 如果在消息处理过程中发生意外错误。
使用示例:
经验丰富的平台用户会利用,并为每个设备配置文件配置特定的规则链。这在大多数情况下都很有用,除非设备数据来自其他消息。例如,您可以使用 BLE 转 MQTT 网关和 BLE 信标。网关有效载荷通常包含信标的 MAC 地址和信标数据:
{"mac": "7085C2F13DCD", "rssi": -25, "payload": "AABBCC"}
假设您有不同的信标配置文件——室内空气质量“IAQ传感器”设备配置文件和泄漏传感器“泄漏传感器”设备配置文件。以下规则链会将消息的发起者从网关更改为设备,并将消息转发到相应的规则链:

3.alarm status filter(报警状态过滤器)
根据指定的警报状态过滤消息。
配置
- 警报状态- 控制要过滤的状态。可用状态:活动已确认、活动未确认、已清除已确认、已清除未确认。

输出连接
- True:
- 如果消息与任何选定的警报状态匹配。
- False:
- 如果消息与任何选定的警报状态不匹配。
- Failure:
- 如果在消息处理过程中发生意外错误。
使用示例
假设您需要处理当前处于活动状态的警报。您可以配置规则节点,以筛选“活动未确认”和“活动已确认”状态。此设置可确保仅进一步处理当前处于活动状态的警报(无论是否已确认)。
使用示例
假设您需要处理当前处于活动状态的警报。您可以配置规则节点,以筛选“活动未确认”和“活动已确认”状态。此设置可确保仅进一步处理当前处于活动状态的警报(无论是否已确认)。

4.check fields presence(检查字段是否存在)
检查消息和/或元数据中是否存在指定字段。消息和元数据通常都是 JSON 对象。
配置:
- 消息字段名称- 消息中应存在的字段名称列表。
- 元数据字段名称- 元数据中应存在的字段名称列表。
- 检查所有指定的字段是否存在- 如果启用,则检查所有字段是否存在,否则至少检查一个字段是否存在。

输出连接
- True:
- 如果启用检查所有指定字段是否存在切换时所有指定字段都存在。
- 如果在检查所有指定字段是否存在切换被禁用时至少存在一个指定字段。
- False:
- 如果在启用“检查所有指定字段是否存在”切换时缺少任何指定字段。
- 如果在禁用“检查所有指定字段是否存在”切换时不存在任何指定字段。
- Failure:
- 如果在消息处理过程中发生意外错误。
5.check relation presence(检查关系存在)
检查消息发起者与其他实体之间的关系是否存在。
配置
- 方向- 关系的方向。可以是“来自发起人(From originator)”或“至发起人(To originator)”。
注意:该值对应于从发起者到特定/任何实体或从特定/任何实体到发起者的关系方向。
- 关系类型- 关系的类型。默认关系类型为“包含”和“管理”,但您可以创建任何类型的关系。
- 检查与特定实体的关系- 如果启用,则检查与特定实体的关系是否存在,否则检查与符合方向和关系类型标准的实体的关系。
注意:仅当启用“检查与特定实体的关系”时,才会出现指定特定实体的配置。

输出连接
- True:
- 如果启用“检查与特定实体的关系”切换时存在与特定实体的指定关系。
- 如果在禁用“检查与特定实体的关系”切换时存在与任何实体的指定关系。
- False:
- 如果启用“检查与特定实体的关系”切换时不存在与特定实体的指定关系。
- 如果在禁用“检查与特定实体的关系”切换时不存在与任何实体的指定关系。
- Failure:
- 如果在消息处理过程中发生意外错误。
使用示例
假设您在办公室和仓库内都安装了温度传感器。在数据处理过程中,您可能需要确定传感器是位于办公室还是仓库。为此,您应该配置“OfficeToDevice”关系,将办公室资产与位于办公室的传感器设备关联起来。
6.entity type filter(实体类型过滤器)
按消息发起方实体的类型过滤传入消息。检查传入消息发起方的实体类型是否与过滤器中指定的某个值匹配。
配置
- 选择实体类型——用于过滤消息的实体类型列表:设备、资产、用户等。

输出连接
- True:
- 如果消息发起者类型与所选实体类型之一匹配。
- False:
- 如果消息发起者类型与任何选定的实体类型不匹配。
- Failure:
- 如果在消息处理过程中发生意外错误。
7.entity type switch(实体类型切换)
根据消息发起者的实体类型路由传入消息。
输出
注意:规则节点的输出连接与消息发起者的实体类型相对应。例如:“设备”、“资产”、“用户”等。
输出连接
- “设备”/“资产”等:
- 如果消息使用与实体类型对应的关系类型成功路由。
- 失败:
- 如果在消息处理过程中发生意外错误。
使用示例
假设您在一个规则链中处理来自不同实体的消息。您可能需要根据实体类型拆分消息流。如下所示:

8.message type filter(消息类型过滤器)
根据一个或多个预定义或自定义消息类型过滤传入消息。检查传入消息的消息类型是否与配置中指定的某个值匹配。
配置
- 选择消息类型- 消息类型列表。支持预定义和自定义消息类型。

输出连接
- True:
- 如果传入的消息类型与所选消息类型之一匹配。
- False:
- 如果传入的消息类型与任何选定的消息类型不匹配。
- Failure:
- 如果在消息处理过程中发生意外错误。
9.message type switch(消息类型切换)
根据消息类型值路由传入消息。如果传入消息具有已知的消息类型,则将其发送到相应的链,否则,消息将发送到其他链。
注意:规则节点的输出连接与消息类型相对应。例如:“Post Telemetry”、“Custom” 等。如果您使用自定义消息类型,则可以通过“其他”链路由这些消息。
输出连接
- “Post telemetry”/Other:
- 如果消息使用与消息类型值对应的关系类型成功路由。
- Failure:
- 如果在消息处理过程中发生意外错误。
使用示例
假设您在一个规则链中处理不同类型的消息。您可能需要根据消息类型拆分消息流。如下所示:

10.script(脚本)
使用传入消息计算布尔函数的值。该函数可以使用TBEL(推荐)或纯 JavaScript 编写。脚本函数应返回布尔值并接受三个参数。
配置
TBEL/JavaScript - 控制函数的编写语言。它接收 3 个输入参数:
msg- 是消息有效负载,通常是 JSON 对象或数组。(包含了设备上传的核心数据(如温度、湿度等,在脚本节点(如 Script Transformation Node)中,你可以通过 msg.temperature、msg.humidity 等字段访问这些数据,并可创建、转换新的 payload(例如设置msg:newPayload))metadata- 是消息元数据。以键值对的形式表示。键和值均为字符串。(用来携带与消息相关的额外信息,如 deviceName、deviceType、甚至 MQTT 的 topic 或 timestamp (ts) 等,示例场景:用于过滤节点(Filter Node)中判断设备类型或消息来源:metadata.deviceType === 'vehicle')msgType- 是一种消息类型,字符串。(用来标识消息的性质,比如设备上报遥测、属性、RPC 请求等。常见预定值有 POST_TELEMETRY_REQUEST(遥测上报)、POST_ATTRIBUTES_REQUEST(属性上报)、TO_SERVER_RPC_REQUEST、CONNECT_EVENT、ALARM … 等,在过滤节点或转换脚本中常用来判断消息类型:if (msgType === 'POST_TELEMETRY_REQUEST') { … })

输出连接
- True:
- 如果脚本评估返回
true。
- 如果脚本评估返回
- False:
- 如果脚本评估返回
false。
- 如果脚本评估返回
- Failure:
- 如果脚本评估失败。
使用示例
消息有效负载可以通过变量访问msg。例如,msg.temperature < 10;
消息元数据可以通过变量访问metadata。例如,metadata.deviceType === 'DHT11';
消息类型可以通过变量访问msgType。例如,msgType === 'POST_TELEMETRY_REQUEST'
完整脚本示例:
if(msgType === 'POST_TELEMETRY_REQUEST') {
if(metadata.deviceType === 'vehicle') {
return msg.humidity > 50;
} else if(metadata.deviceType === 'controller') {
return msg.temperature > 20 && msg.humidity > 60;
}
}
return false;
可以使用测试过滤功能来验证 TBEL/JavaScript 条件。
11.switch(转变)
将传入消息路由到一个或多个输出连接。Node 执行已配置的TBEL(推荐)或 JavaScript 函数,返回字符串数组(连接名称)。
配置
TBEL/JavaScript - 控制函数的编写语言。它接收 3 个输入参数:
msg- 是消息有效负载,通常是 JSON 对象或数组。metadata- 是消息元数据。以键值对的形式表示。键和值均为字符串。msgType- 是一种消息类型,字符串。
脚本应返回一个包含传入消息路由节点连接名称的数组。如果返回的数组为空,则消息将不会被路由到任何节点并被丢弃。

注意:规则节点的输出连接与脚本执行的结果相对应。例如:“低温遥测”、“常温遥测”、“空闲状态”等。
输出连接
- “低温遥测”/“空闲状态”等:
- 如果消息成功路由,则关系类型与脚本执行的结果相对应。
- 失败:
- 如果在消息处理过程中发生意外错误。
使用示例
消息有效负载可以通过变量访问msg。例如,msg.temperature < 10;
消息元数据可以通过变量访问metadata。例如,metadata.customerName === 'John';
消息类型可以通过变量访问msgType。例如,msgType === 'POST_TELEMETRY_REQUEST'
完整脚本示例:
if (msgType === 'POST_TELEMETRY_REQUEST') {
if (msg.temperature < 18) {
return ['Low Temperature Telemetry'];
} else {
return ['Normal Temperature Telemetry'];
}
} else if (msgType === 'POST_ATTRIBUTES_REQUEST') {
if (msg.currentState === 'IDLE') {
return ['Idle State', 'Update State Attribute'];
} else if (msg.currentState === 'RUNNING') {
return ['Running State', 'Update State Attribute'];
} else {
return ['Unknown State'];
}
}
return [];

可以使用测试过滤功能来验证 TBEL/JavaScript 条件。
12.GPS geofencing filter(GPS 地理围栏过滤器)
通过基于 GPS 的地理围栏过滤传入消息。从传入消息中提取经纬度参数,并根据配置的边界进行检查。
配置:地理围栏配置
- 周长类型-多边形或圆形。
- 从元数据中获取周边信息- 如果启用,规则节点将从消息元数据中获取周边信息。
注意:如果您的周长特定于实体(设备/资产/等)并且您将其存储为实体属性,则很有用。
- 周边密钥名称- 存储周边信息的元数据密钥。
- 对于多边形周长类型:
- 多边形定义- 包含以下格式的坐标数组的字符串:
[[lat1, lon1],[lat2, lon2],[lat3, lon3], ... , [latN, lonN]]。
- 多边形定义- 包含以下格式的坐标数组的字符串:
- 对于圆周长类型:
- 中心纬度——圆周中心的纬度;
- 中心经度——圆周中心的经度;
- Range——圆周长范围的值,双精度浮点值;
- 范围单位- 以下之一:米、公里、英尺、英里、海里。
- 对于多边形周长类型:
注意:如果启用了“从消息元数据中获取周长”且未配置周长键名,规则节点将使用默认元数据键名。多边形周长类型的默认元数据键名是“perimeter”。圆形周长的默认元数据键名是:“centerLatitude”、“centerLongitude”、“range”、“rangeUnit”。
圆周长定义的结构(例如,存储在服务器端属性中):
{"latitude": 48.198618758582384, "longitude": 24.65322245153503, "radius": 100.0, "radiusUnit": "METER"}
可用的半径单位:“METER”,“KILOMETER”,“FOOT”,“MILE”,“NAUTICAL_MILE”;
输出连接
- True:
- 如果坐标来自配置的地理围栏内的消息。
- False:
- 如果消息中的坐标位于配置的地理围栏之外。
- Failure:
- 如果传入消息在消息或消息元数据中没有配置纬度或经度键。
- 如果缺少周长定义。
- 如果在消息处理过程中发生意外错误。
使用示例:静态圆周长
假设您想检查设备位置是否在距离基辅市中心乌克兰独立纪念碑 100 米以内。纪念碑的坐标如下:
- 纬度:
50.4515652; - 经度:
0.5236963。
规则节点的配置相当简单:

使用示例:静态多边形周长
我们假设一个简单的牲畜位置监控用例。配置规则节点来监控羊是否在区域边界内:
我们将使用农田的静态多边形坐标:
[[48.19736726399899, 24.652353415807884], [48.19800374220741, 24.65060461551745], [48.19918370897885, 24.65317953619048], [48.19849718616351, 24.65420950445969]]
您可以测试在消息中提交以下坐标,规则节点是否返回True :
{"latitude": 48.198618758582384, "longitude": 24.65322245153503}

使用示例:动态圆/多边形周长
让我们回顾一个更复杂的牲畜位置监控案例,其中羊可能分布在不同的农场。假设我们创建了两个农场:“农场 A”和“农场 B”。每个牲畜追踪设备都与“农场 A”或“农场 B”资产关联。

我们将使用 JSON 值配置名为“perimeter”的服务器端属性:
[[48.19736726399899, 24.652353415807884], [48.19800374220741, 24.65060461551745], [48.19918370897885, 24.65317953619048], [48.19849718616351, 24.65420950445969]]

以下规则链将从相关资产“农场 A”中获取属性,并在地理围栏节点中使用它:
规则节点配置相当简单。请注意,周边键名称没有任何前缀:
2)属性节点(用于更新传入消息的元数据)
属性节点用于将有关消息发起者、与发起者相关的实体以及其他上下文数据的附加信息添加到传出消息中,以便规则链中的进一步处理步骤。您可以在下方找到可用节点的列表。
1.calculate delta(计算增量)

根据先前的时间序列读数和当前读数计算增量,并将其添加到消息中。增量计算在消息发起者的范围内进行,例如设备、资产或客户。
配置
- Input value key(输入值键)- 用于计算增量的键。
- Output value key(输出值键)- 存储传出消息中的增量值的键。
- Number of digits after floating point(浮点数后的位数)- 增量计算的精度。可选。如果提供,则将计算出的增量四舍五入到指定的位数。
- Tell Failure if delta is negative(如果 delta 为负数则告知失败)- 如果启用,则如果 delta 值为负数则消息处理失败。
- Add the time difference between “Input value key” readings(添加“输入值键”读数之间的时间差)- 如果启用,规则节点将计算当前和之前的遥测读数时间戳之间的时间差。
- Period value key(周期值键)- 用于存储发送消息中时间差的键。仅当启用“添加输入值键”读数之间的时间差时才需要。
- Exclude zero deltas from outbound message(从出站消息中排除零增量)- 如果启用,则仅当其值非零时,输出值键才会包含在传出消息中。
- Use caching(使用缓存)- 如果启用,输入值键值将被缓存在内存中以提高性能。
注意:如果输入值的键值在系统中的其他地方或其他规则节点被修改,则缓存将不会更新。规则节点将使用缓存的值来计算下一条消息到达时的增量。

输出连接
- True:
- 如果通过输入值键参数配置的键存在于传入消息中。
- Other:
- 如果传入消息类型不是POST_TELEMETRY_REQUEST。
- 如果通过输入值键参数配置的键不存在于传入消息中。
- Failure:
- 如果启用“如果 delta 为负则告知失败”,并且 delta 计算将返回负值。
- 如果在消息处理过程中发生意外错误。
用法示例:智能计量用例
设想这样一个场景:水计量装置每天报告一次脉冲计数器的绝对值。要确定每日用水量,需要将前一天的数值与当天的数值进行比较。
让我们使用上面屏幕截图中所示配置的示例来检查规则节点的行为。假设来自同一设备的以下消息按列出的顺序到达规则节点:
msg: {"pulseCounter": 42.6754}, metadata: {"ts": "1717772034000"}
msg: {"pulseCounter": 73.3456}, metadata: {"ts": "1717858434000"}
msg: {"temperature": 22.5}, metadata: {"ts": "1717944834000"}
msg: {"pulseCounter": 73.3456}, metadata: {"ts": "1718031234000"}
msg: {"pulseCounter": 53.1245}, metadata: {"ts": "1718117634000"}
输出如下:
msg: {"pulseCounter": 42.6754, "delta": 0, "periodInMs": 0}, metadata: {"ts": "1717772034000"}, "output connection": "Success" # first pulseCounter reading, so the "delta" and "periodInMs" both equals to 0.
msg: {"pulseCounter": 73.3456, "delta": 30.67, "periodInMs": 86400000}, metadata: {"ts": "1717858434000"}, "output connection": "Success" # both "delta" and "periodInMs" calculated relative to the previous msg.
msg: {"temperature": 22.5}, metadata: {"ts": "1717944834000"}, "output connection": "Other" # input value key is missing in the incoming msg
msg: {"pulseCounter": 73.3456}, metadata: {"ts": "1718031234000"}, "output connection": "Success" # zero delta excluded since the "pulseCounter" became unchanged since the previous msg.
msg: {"pulseCounter": 53.1245}, metadata: {"ts": "1718117634000"}, "output connection": "Failure" # force failure due to a negative result of the "delta" calculation.
2.customer attributes(客户属性)

识别消息发起者的客户,并使用客户的属性或最新的遥测数据丰富发出的消息。
配置
-
Customer’s attributes/latest telemetry mapping(客户的属性/最新遥测映射)- 控制是否向消息添加属性或最新遥测数据。
- Source attribute/telemetry key(源属性/遥测密钥)- 用于从客户获取属性或最新遥测值的密钥。
- Target key(目标键)- 将在传出消息中存储获取的值的键。
注意:所有输入字段都支持模板化。
-
Add mapped attributes/latest telemetry to(添加映射属性/最新遥测数据到)- 控制是否将映射Attributes/Latest telemetry (属性/最新遥测数据)添加到Message (消息)或Metadata(元数据)中。

注意:支持以下消息发起者的实体类型:客户,用户,资产,设备。
输出连接
- Success:
- 如果找到并成功获取客户的属性或最新遥测数据。
- 如果未找到客户的属性或最新遥测数据。
- Failure:
- 如果消息发起者的实体类型不受支持。
- 如果消息发起者未分配给客户。
- 如果在消息处理过程中发生意外错误。
使用示例:智能地铁管理系统
设想一个智能地铁管理系统,其中每列火车都会发送遥测数据,而客户是管理列车的地铁运营商。地铁运营商拥有用于监控列车运行的独特配置。这些配置存储为客户属性。
对于这种情况,我们将使用之前提供的配置。
我们有一个属于客户“SubwayOperator”的设备“TrainA”。
“SubwayOperator” 具有以下属性:

来自“TrainA”的传入消息如下:
|
传出消息将通过成功链路由,并将在消息元数据中包含以下属性:
|
使用示例:智能交通管理系统
考虑一个智能交通管理系统,其中交叉路口报告交通灯持续时间和交通密度的遥测数据。
此场景将具有以下配置:
我们有一个属于客户“Intersection”的设备“TrafficLight”。
“Intersection”的最新遥测数据如下:
来自“TrafficLight”的传入消息如下:
|
传出消息将通过成功链进行路由,并将在消息中包含以下遥测信息:
|
3.Customer details(客户详细信息)

使用客户的详细信息来丰富发出的消息。
配置
- Select details (选择详细信息)——从客户处获取的详细信息列表。
- Add selected details to(将选定的详细信息添加到)- 控制是否将获取的详细信息添加到消息或元数据中。

选定的详细信息将添加到带有前缀的发送消息中:customer_。
注意:支持以下消息发起者的实体类型:资产、设备、实体视图、用户、边缘。
输出连接
- Success:
- 如果找到并成功获取客户的详细信息。
- 如果未找到客户的详细信息。
- Failure:
- 如果消息发起者的实体类型不受支持。
- 如果消息发起者未分配给客户。
- 如果在消息处理过程中发生意外错误。
使用示例
设想这样一个场景:温室监测系统将数据发送到规则链。其目标是丰富遥测数据,使其包含客户详细信息,以便进一步处理。为此,我们可以使用客户详细信息节点。
对于这种情况,我们将使用之前提供的配置。
我们有一个设备“温室传感器 01”,属于客户“仓库经理”。
以下是有关客户的信息:

来自“温室传感器 01”的传入消息如下:
|
传出消息将通过成功链路由,并将在消息中包含以下详细信息:
|
4.Fetch device credentials(获取设备凭证)

使用设备凭证丰富传出消息。
配置
- 获取凭证到- 控制是否应将获取的凭证添加到消息或元数据中。

输出连接
- 成功:
- 如果凭证已成功获取。
- 失败:
- 如果传入消息发起者的实体类型不是DEVICE。
- 如果在消息处理过程中发生意外错误。
使用示例
让我们使用上面屏幕截图中所示配置的示例来检查规则节点的行为。假设来自不同设备的以下消息到达规则节点:
msg: {"pulseCounter": 678}, metadata: {"deviceType": "WaterMeter", "deviceName": "WM-001"} # WaterMeter device with Access token credentials
msg: {"temperature": 22}, metadata: {"deviceType": "Thermostat", "deviceName": "TH-001"} # Thermostat device with X.509 credentials
msg: {"humidity": 75}, metadata: {"deviceType": "Hygrometer", "deviceName": "HG-001"} # Hygrometer device with MQTT Basic credentials
输出如下:
msg: {"pulseCounter": 678}, metadata: {"deviceType": "WaterMeter", "deviceName": "WM-001", "credentials": "yNfZ6lL2cWhS5lh8Nd9u", "credentialsType": "ACCESS_TOKEN"} # WaterMeter device with Access token credentials
msg: {"temperature": 22}, metadata: {"deviceType": "Thermostat", "deviceName": "TH-001", "credentials": "MIIFPjCCAyYCFCk6PrTFzUn5/h0yULiwTy4anVLmMA0GCSqGSIb3DQEBCwUAMFwxCzAJBgNVBAYTAlVBMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFTATBgNVBAMMDGludGVybWVkaWF0ZTAeFw0yMzA1MjkxMjQ3MDlaFw0yNDA1MjgxMjQ3MDlaMFsxCzAJBgNVBAYTAlVBMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFDASBgNVBAMMC2RldmljZUBuYW1lMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuUCNlaBe1Qoy3CN2UpTuaJ5So3Nq+YRZS8OW3SXQihCndJDm2g7+5AiiKvYClNNqjcm+rJzWfRlWrJsQ8BQpY/r2sXVLwwjxDHKiE6wiifGtIhyBag9wsZ4DehQ7lYN0dDgypE3iRnvTqq7nQOeTWwJqxGCzTGM2EHmiReXg8WHjXBZFOZxj7hFepw+byBCFXhEEEuiZ5lOpTcw+HvJLMo0PwgCv8OOSGczm7Hb2Nw6ZEGkCJ0dlRxtxIRWMaLQDjz8wyUhuTe2Bvn3qy+4e+Kd0kU2FX9t7VPJ9CU+rHUfp7Y4I0jm/06Sj5bv2HlB2Qs/6hKZQq1DHFGQQC1snRljm1ZwjanTvuyGbzrpKPsAarck6mmNInmWELdMgj9PTrWpN3hkuDXI4U4FumiA6344CYIa+0cefjKdHljnyE/U04YNZJs1ECygsflXzyuUwAwa0Y9EgyadbSOCiMhLITOqtD+bV6uHw2pjCp9MyNIMuUMNQkqnVj6rA5XCGVx5eTnPNljxWVVCdtqcfw6H/DH8Den4FL46zJJhb3ZFLryCzNdzvDZz6eJWFhqmAGSiCXu/EE9/LCC6ic0lBlzIgjabaZbSpZXcQ0Xx7S1zj+mbJN4u2rhE8I9+sLttjR7gczhJGyk4Gqvi7GwJ2NS5e53DxQlSwyxcM3SbsgZhtfhkCAwEAATANBgkqhkiG9w0BAQsFAAOCAgEARloOcoBWGk5/OIkMZZLyey+80mKEeD+7aNTvsC5OW/Pdnof1ElHoUG5q/ANLxmXD5gGU8z15mcjJIZt1OqqRqB+s7nOQxqv9TY+L/8l25iE0wZRw1ljCi3Av+gACBFNLiu5hJPneopncofGWNeDZlAVzClpkDu2hHD5f7W6gxrnN372+csHfb8ksD/bS/f736woaacCrgcAzXfHoLlpR+7YkF0Je21GWXbw5FqwctMxQP7NO8PyYqcjEg8XhZomiqqYp3q8tBYLZVM3BbdpxFrRjJpW3+hXhLNhZgM7pYjbqHj5BCFrpK3IvH4ZtowCIUKc1uwcip/rBCgYr1+TpfKmWmnyxpDHnlItKjyprhLsXrgPAA8PcmNu7C+pOsbwjDLubdJ19LcVHOJknu3YQm/8BvKj1QMzAHirl2UxCqRfMoZpkmYLotGSGQy8Qp6IlhBLIMcPaqMObpyhSr0RVdoAulhtFg6rVvpKPM/OQkFfUFfWvp52UDYh1wsJzoIwFOXk7edHqXKTKWYpJNe039NGqdo2+B9GAbzqQorwan7WYEtETNUdTw30mwiNEZAxgP9QXUSW14GzIxwlzbQgmyGZfeH+YwN0MCJgoAwL+Zij0TXjJ+YW+st0Dp8tQrpJjofa8o4IYQJUSx2I8mNberFywsbmzLdE+BoxFaLDvZNs=", "credentialsType": "X509_CERTIFICATE",} # Thermostat device with X.509 credentials
msg: {"humidity": 75}, metadata: {"deviceType": "Hygrometer", "deviceName": "HG-001", "credentials": "{\"clientId\":\"bv1ilvxhq50m8cyi5jjz\",\"userName\":\"ejkkd1fm9csvwakzym1o\",\"password\":\"o04xj87rguv8d6nvi158\"}", "credentialsType": "MQTT_BASIC",} # Hygrometer device with MQTT Basic credentials
5.related device attributes(相关设备属性)

使用配置的关系查询查找消息发起者实体的相关设备,并使用设备的属性或最新的遥测数据丰富传出消息。
配置: Device relations query(设备关系查询)
- Direction (方向)- 关系查询的方向。可以是From originator(“从发起者”)或To originator.(到发起者”)。
- Max relation level(最大关联层级)- 关联搜索的最大深度。可选。若未设置,则深度不受限制。
注意:即使找到多个实体,搜索查询结果也只返回一个实体。
- Fetch last level relation only (仅获取最后一级关系)- 如果启用,则强制规则节点仅在最大关系级别设置的级别上搜索相关实体。
注意:仅当最大关系级别大于一时可用。
- Fetch last level relation only (仅获取最后一级关系)- 如果启用,则强制规则节点仅在最大关系级别设置的级别上搜索相关实体。
- Relation type(关系类型)- 关系的类型。可选。如果未设置该值,关系查询将搜索任何类型的关系。
注意:默认设置为“包含”。但是,您可以指定自己的关系类型。
- Device profiles(设备配置文件)- 设备配置文件过滤器。仅会找到具有指定配置文件的设备。

配置:Related device attributes(相关设备属性)
- Client/Shared/Server attributes and Latest telemetry(客户端/共享/服务器属性和最新遥测)- 用于从相关设备获取属性或最新遥测的密钥列表。
注意:本节所有输入字段均支持模板化。
- Fetch latest telemetry with timestamp(获取带有时间戳的最新遥测数据)- 如果启用,获取的最新遥测值将添加到带有时间戳的消息中。
注意:仅当配置至少具有一个最新的遥测密钥集时可用。
- Fetch latest telemetry with timestamp(获取带有时间戳的最新遥测数据)- 如果启用,获取的最新遥测值将添加到带有时间戳的消息中。
- Add selected attributes to(将选定的属性添加到)- 控制是否将映射的属性添加到消息或元数据。

配置: 其他
- Tell failure if any of the attributes are missing(如果缺少任何属性,则告知失败)- 如果启用,则如果至少一个选定的键不存在,则消息处理失败。
注意:即使发生失败,发出的消息仍将包含成功获取的遥测密钥。

使用范围前缀将属性添加到传出消息中:
注意:最新的遥测数据被添加到传出消息中,没有任何前缀。
输出连接
- Success:
- 如果找到并成功获取相关设备的属性或最新遥测数据。
- 如果禁用缺少任何属性则告知失败,并且未找到相关设备的属性或最新遥测。
- Failure:
- 如果没有找到相关设备。
- 如果启用“如果缺少任何属性则告知失败”,并且至少一个选定的键不存在。
- 如果在消息处理过程中发生意外错误。
使用示例
假设有一个水压监测系统,其中水压传感器设备报告水压水平、温度和湿度的遥测数据。该系统还包含一个控制单元设备,用于管理水压传感器并记录其数据。
对于这种情况,我们将使用之前提供的配置。
我们有一个设备“ControlUnitDevice”来管理设备“WaterPressureSensor”。

ControlUnitDevice 具有以下属性和最新遥测数据:


来自“WaterPressureSensor”的传入消息如下:
|
传出消息将通过成功链进行路由,并将在消息中包含以下属性和最新遥测:
|
6.originator attributes(发起者属性)

配置
- Client/Shared/Server attributes and Latest telemetry(客户端/共享/服务器属性和最新遥测)- 用于获取发起者属性或最新遥测的密钥列表。
注意:本节所有输入字段均支持模板化。
- Fetch latest telemetry with timestamp(获取带有时间戳的最新遥测数据)- 如果启用,获取的最新遥测值将添加到带有时间戳的消息中。
注意:仅当配置至少具有一个最新的遥测密钥集时可用。
- Fetch latest telemetry with timestamp(获取带有时间戳的最新遥测数据)- 如果启用,获取的最新遥测值将添加到带有时间戳的消息中。
-
Add originator attributes to(添加发起者属性到)- 控制是否应将映射的属性添加到消息或元数据。
- Tell failure if any of the attributes are missing(如果缺少任何属性,则告知失败)- 如果启用,则如果至少一个选定的键不存在,则消息处理失败。
注意:即使出现故障,发出的消息仍将包含成功获取的遥测密钥。

使用范围前缀将属性添加到传出消息中:
注意:最新的遥测数据被添加到传出消息中,没有任何前缀。
输出连接
- Success:
- 如果找到并成功获取消息发起者的属性或最新遥测数据。
- 如果禁用“如果缺少任何属性则告知失败”,并且未找到消息发起者的属性或最新遥测。
- Failure:
- 如果启用“如果缺少任何属性则告知失败”,并且至少一个选定的键不存在。
- 如果在消息处理过程中发生意外错误。
使用示例
您可以在以下教程中看到使用此节点的真实示例:
7.originator fields(发起者字段)

使用消息发起者的详细信息来丰富发出的消息。
配置
- Originator fields mapping(发起者字段映射)-Source field(源字段)和Target key(目标键)之间的映射列表。
- Source field(源字段)——应该获取的字段。
- Target key (目标键)——将在传出消息中存储获取的值的键。
注意:目标关键字段支持模板化。

注意:如果配置的映射包含发起者实体类型不可用的字段(例如,
phone当发起者是设备时),则此类映射将被忽略。
- Add mapped originator fields to(将映射的发起者字段添加到)- 控制是否应将映射字段添加到Message (消息)或Metadata(元数据) 。

- Skip empty fields(跳过空字段)- 如果启用,则不会在发出的消息中添加没有值或空字符串的字段。

注意:支持以下消息发起者的实体类型:租户、客户、用户、资产、设备、警报、规则链、实体视图和边缘。
输出连接
- Success:
- 如果消息发起者的字段被成功获取并添加到传出消息中。
- Failure:
- 如果消息发起者的实体类型不受支持。
- 如果在消息处理过程中发生意外错误。
8.related entity data(相关实体数据)

使用配置的关系查询查找与消息发起者相关的实体,并将相关实体属性、最新遥测或字段添加到传出消息中。
配置:Relations query(关系查询)
- Direction (方向)- 关系查询的方向。可以是From originator(“从发起者”)或To originator(“到发起者”)。
- Max relation level(最大关联层级)- 关联搜索的最大深度。可选。若未设置,则深度不受限制。
注意:即使找到多个实体,搜索查询结果也只返回一个实体。
- Fetch last level relation only(仅获取最后一级关系)- 如果启用,则强制规则节点仅在最大关系级别设置的级别上搜索相关实体。
注意:仅当最大关系级别大于一时可用。
- Fetch last level relation only(仅获取最后一级关系)- 如果启用,则强制规则节点仅在最大关系级别设置的级别上搜索相关实体。
- Relation filters(关系过滤器)- 基于关系类型和实体类型的查询过滤器。可选。如果未设置过滤器,关系查询将搜索任何类型的关系。

配置: Data to fetch(要获取的数据)
- Attributes/Latest telemetry/Fields(属性/最新遥测/字段)- 控制是否获取属性、最新遥测或字段。
- Source attribute/telemetry key or field (源属性/遥测键或字段)- 用于从相关实体获取属性、最新遥测或实体字段值的键。
- Target key(目标键)——将在传出消息中存储获取的值的键。
注意:所有输入字段都支持模板化。
- Add mapped attributes/latest telemetry/fields to (添加映射的属性/最新遥测/字段到)- 控制是否应将获取的数据添加到消息或元数据中。

输出连接
- Success:
- 如果找到了相关实体,即使相关实体不存在要获取的指定数据。
- Failure:
- 如果未找到相关实体。
- 如果在消息处理过程中发生意外错误。
9.tenant attributes(租户属性)

识别消息发起者的租户,并使用租户的属性或最新的遥测数据丰富传出消息。
配置
-
Tenant’s attributes/latest telemetry mapping(租户的属性/最新遥测映射)- 控制是否向消息添加属性或最新遥测数据。
- Source attribute/telemetry key (源属性/遥测密钥)- 用于从租户获取属性或最新遥测值的密钥。
- Target key (目标键)- 将在传出消息中存储获取的值的键。
注意:所有输入字段都支持模板化。
-
Add mapped attributes/latest telemetry to (添加映射属性/最新遥测数据到)- 控制是否将映射Attributes/Latest telemetry (属性/最新遥测数据)添加到Message (消息)或Metadata(元数据)中。

输出连接
- Success:
- 如果找到并成功获取租户的属性或最新遥测数据。
- 如果未找到租户的属性或最新的遥测数据。
- Failure:
- 如果在消息处理过程中发生意外错误。
此节点的功能与客户属性节点类似。主要区别在于,此节点从租户获取属性或最新遥测数据,而客户属性节点则从客户获取属性或最新遥测数据。有关使用示例,请参阅客户属性节点。
10.originator telemetry(发起者遥测)

将使用配置的获取间隔和获取策略找到的消息发起者的时间序列数据添加到消息元数据中。
配置:通用
- Time series keys (时间序列键)- 用于获取发起者的时间序列数据的时间序列键列表。
注意:所有输入键都支持模板化。

配置: Fetch interval(获取间隔)
获取间隔是指获取时间序列数据的时间段。获取间隔可以通过以下两种方式之一配置:
- Fixed interval(固定间隔)-Interval start(间隔开始时间)和Interval end (间隔结束时间)均通过指定持续时间值和时间单位进行配置。此间隔是相对的,这意味着对于每条消息,开始时间和结束时间都是通过从消息处理时间中减去指定的持续时间来计算的。

- Use dynamic interval(使用动态间隔)- 如果启用,则Interval start(间隔开始)和 Interval end (间隔结束)可通过指定模板进行配置。使用这些模板提取的值将被视为UNIX 毫秒时间戳。此间隔是绝对的,这意味着开始和结束时间基于模板提供的特定时间点。

注意:在这两种情况下,间隔开始必须早于间隔结束。
配置:Fetch strategy(获取策略)
获取策略控制在指定的获取间隔内获取哪些值。共有三种策略:
- First (首先)——获取间隔内的第一个时间序列条目。

- Last (最后)- 获取间隔内的最后一个时间序列条目。

获取的时间序列条目将作为简单的键值条目放置在传出消息元数据中。示例:
{
"frequency": "67.88"
} |
- All (全部)——获取间隔内的所有时间序列条目。
默认情况下,节点未配置聚合已提取数据(在数据聚合功能中选择了无选项)。在这种情况下,您可以指定按时间戳排序 的方向和限制提取的条目数。
注意:获取的时间序列条目的最大数量为 1000。

获取的时间序列条目将以对象数组的形式放入传出消息元数据中,每个对象包含一个ts时间戳和一个value字段。示例:
{
"velocity": "[{\"ts\":1718874345362,\"value\":45.777},{\"ts\":1718874365362,\"value\":50.346},{\"ts\":1718875365362,\"value\":60.117}]"
} |
您可以指定一个数据聚合函数来应用于获取的数据。可用函数:最小值、最大值、平均值、总和和计数。

聚合数据将作为简单的键值条目放置在传出消息的元数据中,就像在First或Last策略中一样。
输出连接
- Success:
- 如果找到时间序列数据并将其添加到传出消息元数据中。
- 如果未找到时间序列数据。
- Failure:
- 如果启用了“使用动态间隔”,并且在传入消息中未找到一个或两个模板。
- 如果启用“使用动态间隔”,则使用一个或两个模板提取的值无法解析为数字。
- 如果在消息处理过程中发生意外错误。
注意:发出的消息不是新消息,而是元数据经过修改的传入消息。
使用示例:遥测增量计算教程
Tips
提示:如果要获取具有特定时间戳的时间序列条目,请切换至“使用动态间隔”,并提供模板,使间隔结束时间等于间隔开始时间 加上一毫秒。这将有效地创建一个一毫秒的间隔,以捕获间隔开始时间的条目。
提示:元数据中的所有数据都存储为字符串,因此您可以在其他节点中使用
JSON.parse()它将数据转换为 JSON 格式。
11.Tenant details(租户详情)

使用租户的详细信息来丰富发出的消息。
配置
- Select details(选择详细信息)- 从租户获取的详细信息列表。
- Add selected details to(将选定的详细信息添加到)- 控制是否将获取的详细信息添加到消息或元数据中。

选定的详细信息将添加到带有前缀的发送消息中:tenant_。
输出连接
- Success:
- 如果成功获取租户的详细信息。
- Failure:
- 如果在消息处理过程中发生意外错误。
3)转换节点(用于更改传入消息字段,如发起者、类型、有效负载、元数据)
1.Change originator(变更发起人)

Thingsboard 中所有传入的消息都包含一个发起者字段,用于标识提交消息的实体。该实体可以是设备、资产、客户、租户等。
此节点用于当提交的消息需要作为来自其他实体的消息处理时。例如,设备提交遥测数据,而遥测数据需要复制到更高级别的资产或客户。在这种情况下,管理员应在“保存时间序列节点”之前添加此节点。
发起者可以更改为:
- 发起人的客户
- 发起人的租户
- 由关系查询识别的相关实体
在“关系查询”配置中,管理员可以选择所需的方向和关系深度级别。还可以配置一组关系过滤器,其中包含所需的关系类型和实体类型。
Thingsboard 中所有传入的消息都包含一个发起者字段,用于标识提交消息的实体。该实体可以是设备、资产、客户、租户等。
此节点用于当提交的消息需要作为来自其他实体的消息处理时。例如,设备提交遥测数据,而遥测数据需要复制到更高级别的资产或客户。在这种情况下,管理员应在“保存时间序列节点”之前添加此节点。
发起者可以更改为:
- 发起人的客户
- 发起人的租户
- 由关系查询识别的相关实体
在“关系查询”配置中,管理员可以选择所需的方向和关系深度级别。还可以配置一组关系过滤器,其中包含所需的关系类型和实体类型。

如果找到多个相关实体,则仅使用第一个实体作为新的发起者,其他实体将被丢弃。
如果未找到相关实体/客户/租户,则使用失败链,否则使用成功链。
出站消息将具有新的发起者 ID。
2.Copy key-value pairs(复制键值对)

将键值对从消息复制到消息元数据,反之亦然。
根据配置的方向和键,将键值对从消息复制到消息元数据,或反之。可以使用正则表达式来定义要复制的键值对。任何在源中找不到的配置键都将被忽略。
输出连接:Success,Failure。
配置:

3.Deduplication(重复数据删除)

根据指定的重复数据删除策略,在可配置的时间段内对同一发起方实体内的重复消息进行删除。
重复数据删除策略:
- FIRST - 返回重复数据删除期间到达的第一条消息。
- LAST - 返回重复数据删除期间到达的最后一条消息。
- ALL - 将所有消息以单个 JSON 数组 message 的形式返回。其中每个元素代表一个包含 msg 和 metadata 内部属性的对象。
配置:

4.Delete key-value pairs(删除键值对)

从消息或消息元数据中删除键值对。
根据配置的键和/或正则表达式从消息或消息元数据中删除键值对。
输出连接:Success,Failure。
配置:

5.JSON path (JSON 路径)

使用 JSONPath 表达式转换传入的消息正文。
JSONPath 表达式指定 JSON 结构中某个元素或一组元素的路径。
输出连接:Success,Failure。
配置:
6.Rename keys(重命名键)

重命名消息或消息元数据键。
根据提供的映射重命名消息或消息元数据中的键。如果要重命名的键在指定的源(消息或消息元数据)中不存在,则会被忽略。
输出连接:Success,Failure。
配置:

7.Script(脚本)

使用配置的 JavaScript 函数更改消息有效负载、元数据或消息类型。
JavaScript 函数接收 3 个输入参数:
msg- 是消息有效载荷。metadata- 是消息元数据。msgType- 是一种消息类型。
脚本应返回以下结构:
{
msg: new payload,
metadata: new metadata,
msgType: new msgType
}

结果对象中的所有字段都是可选的,如果未指定,将从原始消息中获取。
来自此节点的出站消息将是使用配置的 JavaScript 函数构建的新消息。
可以使用测试 JavaScript函数来验证 JavaScript 转换函数。
例子
节点接收带有有效载荷的消息:
{
"temperature": 22.4,
"humidity": 78
}
原始元数据:
{ "sensorType" : "temperature" }
原始消息类型- POST_TELEMETRY_REQUEST
应进行以下修改:
- 将消息类型更改为“CUSTOM_UPDATE”
- 在有效载荷中添加附加属性版本,值为v1.1
- 将元数据中的sensorType属性值更改为roomTemp
以下转换函数将执行所有必要的修改:
var newType = "CUSTOM_UPDATE";
msg.version = "v1.1";
metadata.sensorType = "roomTemp"
return {msg: msg, metadata: metadata, msgType: newType};
您可以在这些教程中看到真实示例,了解如何使用此节点:
9.Split array msg(拆分数组消息)

将数组消息拆分为多个消息。
将数组消息拆分为单个元素,每个元素作为单独的消息发送。所有发出的消息都将具有与原始数组消息相同的类型和元数据。
输出连接:Success,Failure。
配置:

10.To email(发送电子邮件)

使用从消息元数据派生的值填充电子邮件字段,将消息转换为电子邮件消息。设置“SEND_EMAIL”输出消息类型,以便稍后由“发送电子邮件节点”接受。所有电子邮件字段均可配置为使用元数据中的值。支持发送 HTML 页面和图像。

例如,传入消息在元数据中具有deviceName字段,并且电子邮件正文应包含其值。
在这种情况下,可以像以下示例中一样引用deviceName的值:${deviceName}
|
如果您想发送 HTML 或图像,则必须在邮件正文类型字段中选择HTML或动态。请参阅在电子邮件中发送 HTML 或图像的 示例。
此外,如果传入消息元数据包含参考数据库中存储的文件的附件字段,则该节点可以准备电子邮件附件。
注意这是ThingsBoard 专业版支持的文件存储功能的一部分。
4)动作结点(根据传入的消息执行各种动作)
1.Assign to Customer node(分配给客户节点)

将消息发起者实体分配给客户。
允许以下消息发起者类型:资产、设备、实体视图、仪表板。
根据客户名称模式查找目标客户,然后将发起实体分配给该客户。
如果不存在则创建新客户,如果不存在则创建新客户设置为true。
配置:

- 客户名称模式(Customer name pattern)- 可以设置直接客户名称或使用模式,使用消息元数据将其解析为真实客户名称。
- 如果不存在则创建新客户(Create new customer if not exists)- 如果选中则在客户不存在时创建新客户。
- 客户缓存过期时间(Customers cache expiration time (sec))- 指定允许存储找到的客户记录的最大时间间隔(秒)。0 值表示记录永不过期。
在以下情况下,消息将通过失败链进行路由:
- 当发起者实体类型不受支持时。
- 目标客户不存在,并且未选中“如果不存在则创建客户”。
在其他情况下,消息将通过成功链进行路由。
2.Calculated fields node(计算字段节点)

此节点用于触发计算字段处理,而无需将传入的遥测数据存储在数据库中。默认情况下,计算字段的处理由“保存属性”和“保存时间序列”节点触发。计算字段节点接受与这些节点相同类型的消息,但允许您将处理与数据持久性分离——当您只想使用遥测数据进行计算字段处理时,这是理想的选择。
注意:此节点不会在数据库中存储任何遥测或属性数据- 它只是根据传入的遥测触发计算字段的执行。
为了避免将不必要的数据持久化到数据库中,请将消息路由到此节点,而不是保存时间序列或保存属性节点。
重要提示:计算字段时,会生成包含已更新计算字段状态的发起者的新消息,并将其推送到发起者的根规则链中。要存储计算结果,您仍然需要在规则链中使用“保存时间序列”或“保存属性”节点。
输出连接
- Success:
- 如果消息有效负载包含要处理的有效遥测或属性数据,或者为空。
- Failure:
- 如果传入消息类型不是
POST_TELEMETRY_REQUEST或POST_ATTRIBUTES_REQUEST。 - 如果在消息处理过程中发生意外错误。
- 如果传入消息类型不是
使用示例:
考虑一个智能建筑能源管理系统,其中建筑运营商想要监控空调系统的能源效率比(EER)来分析性能趋势。
涉及两种类型的设备:
- 传感器(例如流量计、功率计):这些设备发送高频遥测数据,例如冷却输出和功耗,可用于计算字段处理。由于数据变化迅速,且单独使用毫无用处,因此不值得长期保存。
- HVAC 单元(例如,HVAC 控制器、基于区域的 HVAC 系统的逻辑聚合器):这些设备发送诊断和分析所需的关键遥测数据,例如压缩机温度和振动水平。这些数据以及计算出的 EER 将被保存以供长期分析。
计算字段在HVAC 控制器上定义,并使用来自传感器设备的遥测数据。当遥测消息(例如来自流量计的消息)进入规则链时,设备配置文件切换节点会将此消息路由到计算字段节点。 计算字段节点会根据来自消息的传入遥测数据触发计算字段的处理。计算完成后,将生成一条以HVAC 控制器为发起方的新消息,其中包含计算值。该消息进入规则链,设备配置文件切换节点会将其路由到保存时间序列节点以保存结果。

3.Clear alarm node(清除报警节点)

该节点加载为消息发起者配置的警报类型的最新警报,并清除警报(如果存在)。
节点配置:
- 警报详情构建器脚本
- 警报类型- 表示警报类型的任何字符串

用于更新警报详情JsonNode 的警报详情构建器脚本。它有助于在警报中存储附加参数。例如,您可以保存原始消息负载或元数据中的属性名/值对。
警报详细信息构建器脚本应返回详细信息对象。

- 消息有效载荷可以通过
msg属性访问。例如msg.temperature - 消息元数据可以通过属性访问
metadata。例如metadata.customerName - 消息类型可以通过属性访问
msgType。例如msgType - 当前警报详细信息可通过 访问
metadata.prevAlarmDetails。
请注意,这 metadata.prevAlarmDetails是一个原始字符串字段,需要使用以下构造将其转换为对象:
var details = {};
if (metadata.prevAlarmDetails) {
details = JSON.parse(metadata.prevAlarmDetails);
}
可以使用测试 JavaScript 函数来验证警报详情生成器脚本功能。
详细信息生成器函数示例
此函数count从之前的警报中获取属性并将其递增。同时将temperature 入站消息负载中的属性添加到警报详细信息中。
var details = {temperature: msg.temperature, count: 1};
if (metadata.prevAlarmDetails) {
var prevDetails = JSON.parse(metadata.prevAlarmDetails);
if(prevDetails.count) {
details.count = prevDetails.count + 1;
}
}
return details;
此节点更新当前警报:
- 如果已经确认,则将警报状态更改为CLEARED_ACK ,否则更改为CLEARED_UNACK
- 将清除时间设置为当前系统时间
- 使用从警报详细信息构建器脚本返回的新对象更新警报详细信息
如果警报不存在或者已经清除警报,原始消息将通过False链传递到下一个节点。
否则,新消息将通过清除链传递。
出站消息将具有以下结构:
- 消息类型(Message Type)-警报
- 发起者(Originator )- 与入站消息的发起者相同
- 有效负载(Payload )- 已清除警报的 JSON 表示
- 元数据(Metadata )- 原始消息元数据中的所有字段。此外,元数据中还将添加附加属性 -> isClearedAlarm,值为true。
以下是出站消息有效负载的示例
{
"tenantId": {
"entityType": "TENANT",
"id": "22cd8888-5dac-11e8-bbab-ad47060c9bbb"
},
"type": "High Temperature Alarm",
"originator": {
"entityType": "DEVICE",
"id": "11cd8777-5dac-11e8-bbab-ad55560c9ccc"
},
"severity": "CRITICAL",
"status": "CLEARED_UNACK",
"startTs": 1526985698000,
"endTs": 1526985698000,
"ackTs": 0,
"clearTs": 1526985712000,
"details": {
"temperature": 70,
"ts": 1526985696000
},
"propagate": true,
"id": "33cd8999-5dac-11e8-bbab-ad47060c9431",
"createdTime": 1526985698000,
"name": "High Temperature Alarm"
}
4.Copy to view node(复制到视图节点)

根据实体视图配置,将资产/设备的属性复制到相关实体视图。复制操作仅针对起始日期和结束日期之间且符合属性键配置的属性进行。将消息发起者更改为相关实体视图,并根据更新的实体视图数量生成新消息
配置:

5.Create alarm node(创建报警节点)

此节点尝试加载已配置警报类型的最新警报,并将其发送给消息发起者。如果存在未清除的警报,则更新此警报;否则,将创建新警报。
节点配置:

- 警报详情构建器脚本
- 警报类型(Alarm Type)- 表示警报类型的任何字符串
- 警报严重程度(Alarm Severity)- {CRITICAL | MAJOR | MINOR | WARNING | INDETERMINATE}
- 是传播(Propagate )- 警报是否应该传播到所有与父相关的实体。
-
从消息中读取警报配置:
-
使用消息元数据中的字段模式获取警报类型:
按关系类型过滤传播到父实体:

用于生成警报详情(Alarm Details Builder)JsonNode 的警报详情构建器脚本。它有助于在警报中存储附加参数。例如,您可以保存原始消息负载或元数据中的属性名/值对。
警报详细信息构建器(Alarm Details Builder)脚本应返回详细信息(details )对象。

- 消息有效载荷可以通过
msg属性访问。例如msg.temperature - 消息元数据可以通过属性访问
metadata。例如metadata.customerName - 消息类型可以通过属性访问
msgType。例如msgType
可选:可以通过 访问上一个警报详情metadata.prevAlarmDetails。如果上一个警报不存在,则此字段将不会出现在元数据中。请注意, metadata.prevAlarmDetails 是一个原始字符串字段,需要使用以下结构将其转换为对象:
var details = {};
if (metadata.prevAlarmDetails) {
details = JSON.parse(metadata.prevAlarmDetails);
}
可以使用测试 JavaScript 函数来验证警报详情生成器脚本功能。
详细信息生成器函数示例
此函数count从之前的警报中获取属性并将其递增。同时将temperature 入站消息负载中的属性添加到警报详细信息中。
var details = {temperature: msg.temperature, count: 1};
if (metadata.prevAlarmDetails) {
var prevDetails = JSON.parse(metadata.prevAlarmDetails);
if(prevDetails.count) {
details.count = prevDetails.count + 1;
}
}
return details;
使用以下属性创建/更新警报:
- 警报详情(Alarm details ) - 从警报详情构建器脚本返回的对象
- 报警状态 - 如果是新报警(Alarm status - if new alarm)-> ACTIVE_UNACK。如果是现有报警-> 未更改
- 严重性(Severity ) - 来自节点配置的值
- 传播(Propagation ) - 来自节点配置的值
- 警报类型 (Alarm type)- 来自节点配置的值
- 闹钟开始时间(Alarm start time) - 如果是新闹钟->当前系统时间。如果是现有闹钟-> 不改变
- 闹钟结束时间(Alarm end time) -当前系统时间
出站消息将具有以下结构:
- 消息类型(Message Type)-警报
- 发起者(Originator )- 与入站消息的发起者相同
- 有效负载(Payload )- 已创建/更新的新警报的 JSON 表示
- 元数据(Metadata )- 原始消息元数据的所有字段
新的警报创建后,出站消息将在元数据中包含一个附加属性 - isNewAlarm,其值为true。消息将通过Created链传递。
现有警报更新后,出站消息将在元数据中包含附加属性 - isExistingAlarm,值为true。消息将通过更新链传递。
以下是出站消息有效负载的示例
{
"tenantId": {
"entityType": "TENANT",
"id": "22cd8888-5dac-11e8-bbab-ad47060c9bbb"
},
"type": "High Temperature Alarm",
"originator": {
"entityType": "DEVICE",
"id": "11cd8777-5dac-11e8-bbab-ad55560c9ccc"
},
"severity": "CRITICAL",
"status": "ACTIVE_UNACK",
"startTs": 1526985698000,
"endTs": 1526985698000,
"ackTs": 0,
"clearTs": 0,
"details": {
"temperature": 70,
"ts": 1526985696000
},
"propagate": true,
"id": "33cd8999-5dac-11e8-bbab-ad47060c9431",
"createdTime": 1526985698000,
"name": "High Temperature Alarm"
}
6.Create relation node(创建关系节点)

根据类型和方向创建从选定实体到消息发起者的关系。
允许以下消息发起者类型:资产、设备、实体视图、客户、租户、仪表板。
通过元数据键模式查找目标实体,然后在发起实体和目标实体之间创建关系。
如果选择的实体类型为资产、设备或客户, 规则节点将在不存在时创建新实体,并且选中复选框:如果不存在则创建新实体。
注意:如果选择的实体类型为资产或设备,则需要设置两种模式:
-
实体名称模式;
-
实体类型模式。
否则,仅应设置名称模式。
配置:

- 方向(Direction )- 允许以下类型:从、到。
- 关系类型(Relation type )- 与消息发起实体的直接连接类型。默认类型“包含”和“管理”可从下拉列表中选择。
- 名称模式(Name pattern)和类型模式(Type pattern)- 可以设置直接实体名称/类型或使用模式,使用消息元数据将其解析为真实实体名称/类型。
- 实体缓存过期时间(Entities cache expiration time)- 指定允许存储找到的目标实体记录的最大时间间隔(秒)。0 值表示记录永不过期。
在以下情况下,消息将通过失败链进行路由:
- 当发起者实体类型不受支持时。
- 目标实体不存在。
在其他情况下,消息将通过成功链进行路由。
-
根据方向和类型从传入消息的发起者中删除当前关系:

-
将传入消息的发起者更改为所选实体,并将传出消息作为来自另一个实体的消息进行处理:

7.Delete attributes node(删除属性节点)

删除消息发起者的属性。
该规则节点尝试根据指定的键删除消息发起者实体(例如,设备)的属性。
行为:
- 如果缺少具有指定键的属性,它将被忽略。
- 如果具有给定键的属性存在 - 它将会被删除。
- 成功删除后:
- 向消息发起者的根链发送“属性已删除”事件。
- 通过成功链发送传入消息。
- 删除失败时:
- 消息通过失败链进行路由。
配置:

8.Delete relation node(删除关系节点)

按类型和方向删除选定实体与消息发起者之间的关系。
允许以下消息发起者类型:资产、设备、实体视图、客户、租户、仪表板。
通过实体名称模式查找目标实体,然后删除发起实体和该实体之间的关系。
配置:

- 方向(Direction )- 允许以下类型:从、到。
- 关系类型(Relation type)- 与消息发起实体的直接连接类型。默认类型“包含”和“管理”可从下拉列表中选择。
- 名称模式(Name pattern)- 可以设置直接实体名称或使用模式,使用消息元数据将其解析为真实实体名称。
- 实体缓存过期时间(Entities cache expiration time)- 指定允许存储找到的目标实体记录的最大时间间隔(秒)。0 值表示记录永不过期。
在以下情况下,消息将通过失败链进行路由:
- 当发起者实体类型不受支持时。
- 目标实体不存在。
在其他情况下,消息将通过成功链进行路由。
规则节点可以通过禁用规则节点配置中的以下复选框,根据方向和类型删除从传入消息的发起者到指定实体或实体列表的关系:

9. Device profile node(设备配置文件节点)

设备配置文件规则节点根据设备配置文件中定义的警报规则创建和清除警报。默认情况下,它是处理链中的第一个节点。此节点处理所有传入消息,并对属性值和遥测数据做出反应。

节点配置:
-
保留报警规则状态(Persist state of alarm rules)
存储报警规则的处理状态。默认禁用。此选项在使用持续时间或重复条件时很有用。
例如:如果有“温度大于 50°C 持续 1 小时”这样的条件,并且第一个高于 50°C 的温度读数出现在13:00,那么应该在14:00触发警报(假设温度保持在阈值以上)。
但是,如果服务器在 13:00 到 14:00 之间重启,规则节点需要从数据库中检索状态才能按预期触发警报。
如果此选项与“获取报警规则的状态”一起启用,则规则节点即使在重启后也能够创建警报。如果它保持禁用状态,则规则节点在重启后将不会生成警报。出于性能原因,
它默认是禁用的。启用后,每个与至少一个报警条件匹配的传入消息都会导致额外的写入操作以将状态保留在数据库中。 -
获取报警规则状态(Fetch state of alarm rules)
在规则节点初始化时恢复报警规则处理状态。默认禁用。
此设置对于持续时间或重复条件也很有用。它与“持久化报警规则状态
” 协同工作,但在某些情况下,您可能希望在禁用此选项的同时保持“持久化状态”启用。例如,如果您有许多设备频繁或连续地发送数据,禁用此选项可以避免在启动期间从数据库加载状态。 在这种情况下,规则节点将仅在第一条消息从特定设备到达时才从数据库加载状态。
10.Device state node(设备状态节点)

触发设备连接事件。如果传入消息的发起者是设备,此节点会在设备状态服务中注册该设备的已配置事件,然后设备状态服务会将相应的消息发送到规则引擎。如果存在元数据ts属性,则该属性将用作事件时间戳;否则,将使用消息时间戳。
如果发起方实体类型不是DEVICE,或者处理过程中发生意外错误,则传入消息将被转发至“故障”链。如果特定发起方的连接事件发生率过高,则传入消息将被转发至“速率受限”链。
支持的设备连接事件:
- 连接事件
- 断开连接事件
- 活动事件
- 不活动事件
当设备不使用传输协议发送数据时,此节点特别有用,例如从外部 API 获取数据或在规则链本身内计算数据时。
配置:

11.Generator node(生成器节点)

生成可配置周期的消息。消息生成使用 JavaScript 函数。
节点配置:
- 消息生成频率(Generated messages limit )(以秒为单位)
- 消息发起者(Originator)
- 将生成实际消息的 JavaScript 函数。
JavaScript 函数接收 3 个输入参数:
prevMsg- 是先前生成的消息有效载荷。prevMetadata- 是先前生成的消息元数据。prevMsgType- 是先前生成的消息类型。
脚本应返回以下结构:
{
msg: new payload,
metadata: new metadata,
msgType: new msgType
}

结果对象中的所有字段都是可选的,如果未指定,将从先前生成的消息中获取。
来自此节点的出站消息将是使用配置的 JavaScript 函数构建的新消息。
可以使用测试 JavaScript 函数来验证 JavaScript 生成器函数。
该节点可用于规则链调试目的。
12.GPS geofencing events node(GPS 地理围栏事件节点)

根据 GPS 参数生成传入消息。从传入消息数据或元数据中提取经纬度,并根据配置参数(地理围栏)返回不同的事件。

规则节点默认从消息元数据中获取边界信息。如果未选中“从消息元数据中获取边界信息”,则需要配置其他信息。
从消息元数据中获取周边信息(Fetch perimeter information from message metadata)
根据周长类型,区域定义有两种选择:多边形和圆形
传入消息的元数据必须包含名称为perimeter 的密钥和以下数据结构:
- 多边形
|
- 圆圈
|
输入“纬度”和“经度”即可得出该点的坐标。
“半径”键——它是坐标点到圆的距离。
这些键的所有值都是双精度浮点数据类型。
“radiusUnit”键需要从METER、KILOMETER、FOOT、MILE、NAUTICAL_MILE(必须大写字母)列表中选取特定值。
从节点配置中获取周长信息(Fetch perimeter information from node configuration)
根据周界类型,区域定义有两种选择:
- 多边形

- 圆圈

事件类型
地理围栏规则节点管理 4 种类型的事件:
- 已进入(Entered )— 每当收到消息时,报告经纬度首次属于所需的周长区域;
- 左图(Left )— 表示当收到的消息中的经纬度第一次不属于所需的周长区域时进行报告;
- 内部(Inside )和外部(Outside )事件用于报告当前状态。
管理员可以配置报告内部或外部事件的持续时间阈值。例如,当最短内部时间设置为 1 分钟时,消息发送者进入区域 60 秒后将被视为进入区域内。最短外部时间则定义消息发送者何时被视为离开区域。

在以下情况下将使用故障链:
- 传入消息的数据或元数据中没有配置纬度或经度键。
- 缺少周长定义;
13.Log node(日志节点)

使用配置的 JavaScript 函数将传入的消息转换为字符串,并将最终值记录到 Thingsboard 日志文件中。
INFO日志级别用于记录日志。
JavaScript 函数接收 3 个输入参数
metadata- 是消息元数据。msg- 是消息有效载荷。msgType- 是一种消息类型。
脚本应该返回字符串值。

可以使用测试 JavaScript函数来验证 JavaScript 转换函数。
14.Math function node(数学函数节点)
| 功能 | 参数数量 | 描述 | 参考 |
|---|---|---|---|
| ADD | 2 | x + y | |
| SUB | 2 | x - y | |
| MULT | 2 | x * y | |
| DIV | 2 | x / y | |
| SIN | 1 | 返回某个角度的三角正弦值。 | 数学 |
| SINH | 1 | 返回双精度值的双曲正弦值。x 的双曲正弦定义为 ( e x - e -x )/2,其中e是欧拉常数。 | 数学.sinh |
| COS | 1 | 返回某个角度的三角余弦。 | Math.cos |
| COSH | 1 | 返回双精度值的双曲余弦值。x 的双曲余弦定义为 ( e x + e -x )/2,其中e是欧拉常数。 | 数学.cosh |
| TAN | 1 | 返回某个角度的三角正切。 | 数学.tan |
| TANH | 1 | 返回双精度值的双曲正切。 | 数学.tanh |
| ACOS | 1 | 返回某个值的反余弦值;返回的角度范围是0.0到pi。 | Math.acos |
| ASIN | 1 | 返回某个值的反正弦值;返回的角度范围在-pi/2到pi/2之间。 | 马萨辛 |
| ATAN | 1 | 返回某个值的反正切;返回的角度范围是 -pi/2 到 pi/2。 | 马塔坦 |
| ATAN2 | 2 | 返回直角坐标 (x, y) 转换为极坐标 (r, theta) 后的角度 theta。 | Math.atan2 |
| EXP | 1 | 返回值e x,其中e是自然对数的底数。 | 数学表达式 |
| EXPM1 | 1 | 返回e x -1。注意,当 x 的值接近 0 时,expm1(x) + 1 的精确和比 exp(x) 更接近e x的真实结果。 | 数学.expm1 |
| SQRT | 1 | 返回双精度值正确舍入的正平方根。 | 数学.sqrt |
| CBRT | 1 | 返回双精度值的立方根。 | 数学.cbrt |
| GET_EXP | 1 | 返回双精度表示中使用的无偏指数。 | Math.getExponent |
| HYPOT | 2 | 返回 sqrt(x2 +y2),中间没有溢出或下溢。 | Math.getExponent |
| LOG | 1 | 返回双精度值的自然对数(底数为 e)。 | 数学对数 |
| LOG10 | 1 | 返回双精度值的以 10 为底的对数。 | Math.log10 |
| LOG1P | 1 | 返回参数和 1 之和的自然对数。请注意,对于较小的值 x,log1p(x) 的结果比 log(1.0+x) 的浮点评估更接近 ln(1 + x) 的真实结果。 | Math.log1p |
| CEIL | 1 | 返回大于或等于参数且等于数学整数的最小(最接近负无穷大)双精度值。 | Math.ceil |
| FLOOR | 1 | 返回小于或等于参数且等于数学整数的最大(最接近正无穷大)双精度值。 | Math.floor |
| FLOOR_DIV | 2 | 返回小于或等于代数商的最大值(最接近正无穷大)long 值。 | Math.floorDiv |
| FLOOR_MOD | 2 | 返回长参数的地板模数。 | Math.floorMod |
| ABS | 1 | 返回双精度值的绝对值。 | 数学抽象 |
| MIN | 2 | 返回两个双精度值中较小的一个。 | 数学 |
| MAX | 2 | 返回两个双精度值中较大的一个。 | Math.max |
| POW | 2 | 返回第一个参数的第二个参数的幂的值。 | 数学.pow |
| SIGNUM | 1 | 返回参数的符号函数;如果参数为零,则返回零;如果参数大于零,则返回 1.0;如果参数小于零,则返回 -1.0。 | 数学符号 |
| RAD | 1 | 将以度为单位测量的角度转换为以弧度为单位测量的近似等效角度。 | 数学转弧度 |
| DEG | 1 | 将以弧度测量的角度转换为以度数测量的近似等效角度。 | 数学到学位 |
| CUSTOM | 1-16 | 使用此函数指定复杂的数学表达式。例如,使用 (x - 32) / 1.8) 将华氏度转换为摄氏度 | exp4j |
您可以使用 5 种类型的参数:
- 常量(Constant);
- 来自消息正文的值(Value from the message body);
- 来自消息元数据的值(Value from the message meta data);
- 属于消息发起者(设备、资产等)的属性值(Value of the attribute that belongs to the message originator (device, asset, etc))。值应为数值类型或可转换为浮点数的字符串;
- 属于消息发起者(设备、资产等)的最新时间序列的值(Value of the latest time-series that belongs to the message originator (device, asset, etc).)。值应为数值类型或可转换为浮点数的字符串;
此规则节点的主要用例是从数据库中获取一个或多个值,并根据消息中的数据进行修改。例如,您可以totalWaterConsumption根据deltaWaterConsumption设备报告的值进行增加。
另一个用例是script用更轻量、更高效的实现替换简单的 JS 节点。例如,你可以使用 CUSTOM 操作符和表达式(x - 32) / 1.8)将华氏度转换为摄氏度 ( C = (F - 32) / 1.8 ) 。
执行在消息发起者(例如设备)和服务器节点范围内同步。如果您的规则节点位于不同的规则链中,它们将在服务器节点范围内同步处理来自同一发起者的消息。
函数的结果可以添加到消息正文或元数据中。您也可以将结果作为属性或时间序列保存到数据库中。

15.Message count node(消息计数节点)

在指定的时间间隔内接收消息并生成带有消息计数的 POST_TELEMETRY_REQUEST 消息
配置:

16.REST call reply node(REST 调用回复节点)

将回复发送至最初发送到规则引擎的 REST API 调用。
接收任意类型的消息。将传入消息作为 REST API 调用的回复转发给规则引擎。
配置:

17.RPC call reply node(RPC调用回复节点)

将响应发送给 RPC 调用发起者。所有传入的 RPC 请求都以消息的形式通过规则链传递。此外,所有 RPC 请求都包含请求 ID 字段。该字段用于映射请求和响应。消息发起者必须是设备实体,因为 RPC 响应是向消息发起者发起的。
节点配置有特殊的请求 ID 字段映射。如果没有指定映射,则默认使用requestId元数据字段。

RPC 请求可以通过不同的传输方式接收:
- MQTT
- HTTP
- CoAP
消息有效载荷示例:
{
"method": "setGpio",
"params": {
"pin": "23",
"value": 1
}
}
在以下情况下,消息将通过失败链进行路由:
- 入站消息发起者不是设备实体
- 消息元数据中不存在请求 ID
- 入站消息有效负载为空
18.RPC call request node(RPC调用请求节点)

向设备发送 RPC 请求,并将响应路由到下一个规则节点。消息发起者必须是设备实体,因为 RPC 请求只能由设备发起。
节点配置有超时字段,用于指定等待设备响应的超时时间。

消息负载必须符合 RPC 请求的正确格式。它必须包含方法和参数字段。例如:
{
"method": "setGpio",
"params": {
"pin": "23",
"value": 1
}
}
如果消息有效负载包含requestId字段,则该字段的值用于标识向设备发出的 RPC 请求。否则,将生成随机的 requestId。
出站消息的发起者和元数据与入站消息相同。设备的响应将被添加到消息有效载荷中。
在以下情况下,消息将通过失败链进行路由:
- 入站消息发起者不是设备实体
- 入站消息缺少方法或参数字段
- 如果 Node 在配置的超时时间内没有收到响应
否则消息将通过成功链进行路由。
19.Save attributes node(保存属性节点)

将传入消息有效负载存储为消息发起者的属性数据。
预期的传入消息格式
该节点接受以下类型的消息POST_ATTRIBUTES_REQUEST,并期望传入的消息负载为一个对象,其中每个属性名称代表一个属性键,其对应的值是属性值。例如:
{
"firmware_version": "1.0.1",
"serial_number": "SN-001"
}
配置:处理设置
保存属性节点可以执行三种不同的操作,每种操作都由可配置的处理策略控制:
- 属性(Attributes):将属性数据保存到数据库。
- WebSockets(WebSockets):通知 WebSocket 订阅有关属性数据的更新。
- 计算字段(Calculated fields):通知计算字段有关属性数据的更新。
对于每个操作,您可以从以下处理策略中进行选择:
- 对每条消息(On every message):对每条传入消息执行操作。
- 重复数据删除(Deduplicate):仅对可配置时间间隔内来自特定发起者的第一条消息执行此操作。重复数据删除间隔的最小值为 1 秒,最大值为 1 天。为了确定某条消息是否位于先前处理的时间间隔内,系统会使用以下公式计算重复数据删除间隔数:
long intervalNumber = ts / deduplicationIntervalMillis;在哪里:
ts是用于重复数据删除的时间戳(以毫秒为单位)。deduplicationIntervalMillis是配置的重复数据删除间隔(自动转换为毫秒)。intervalNumber确定消息所属的逻辑时间段。
时间戳
ts是使用以下优先级确定的:- 如果消息元数据包含
ts属性(以 UNIX 毫秒为单位),则使用该属性。 - 否则,将使用消息的创建时间。
所有时间戳均为 UNIX 毫秒(UTC)。
- 跳过(Skip):从不执行该操作。
可以使用基本或高级处理设置来设置处理策略。

- 基本处理设置(Basic processing settings)——为所有操作提供预定义的策略:
- 在每封邮件上(On every message):将“在每封邮件上”策略应用于所有操作。所有操作均针对所有邮件执行。
- 重复数据删除(Deduplicate):将重复数据删除策略(具有指定的间隔)应用于所有操作。
- 仅限 WebSocket(WebSockets ):除 WebSocket 通知外,所有操作均应用“跳过”策略,而 WebSocket 通知则使用“每条消息触发”策略。实际上,数据库中不存储任何内容;数据仅通过 WebSocket 订阅实时获取。

- 高级处理设置(Advanced processing settings)- 允许您独立配置每个操作的处理策略。

在高级模式下配置处理策略时,某些组合可能会导致意外行为。请考虑以下场景:
-
跳过数据库存储(Skipping database storage)
选择禁用一个或多个持久性操作(例如,跳过时间序列或最新值的数据库存储,同时保持 WS 更新启用)会带来仅部分数据可用的风险:
- 如果仅为实时通知(WebSockets)处理消息而不将其存储在数据库中,则历史查询可能与仪表板上的数据不匹配。
- 当时间序列和最新值的处理策略不同步时,遥测数据可能存储在一个表中(例如,时间序列),而相同的数据却不存在于另一个表中(例如,最新值)。
-
禁用 WebSocket (WS) 更新(Disabling WebSocket (WS) updates)
如果禁用 WS 更新,任何时间序列数据的更改都不会推送到仪表板(或其他 WS 订阅)。这意味着即使数据库已更新,仪表板也可能无法显示更新的数据,直到浏览器页面重新加载。
-
跳过计算字段的重新计算(Skipping calculated field recalculation)
如果将遥测数据保存到数据库,同时绕过计算字段的重新计算,则聚合值可能不会更新以反映最新数据。相反,如果使用新数据重新计算计算字段,但相应的遥测值未保留在数据库中,则计算字段的值可能包含未存储的数据。
-
不同操作的重复数据删除间隔不同(Different deduplication intervals across actions)
当您为操作配置不同的重复数据删除间隔时,相同的传入消息可能会因操作不同而得到不同的处理。例如,如果设置为“每条消息” ,则某条消息可能会立即存储在时间序列表中,而不会存储在最新值表中,因为其重复数据删除间隔尚未结束。此外,如果 WebSocket 更新配置了不同的间隔,则仪表板显示的更新可能会与数据库中存储的内容不匹配。
-
重复数据删除缓存清除(Deduplication cache clearing)
重复数据删除机制使用内存缓存来按间隔跟踪已处理的消息。此缓存最多可保留 100 个间隔,最长保留 2 天,但由于使用软引用,条目可能随时被清除。因此,即使在轻负载下也无法保证重复数据删除的有效性。例如,如果重复数据删除间隔为一天,并且消息每小时到达一次,则如果在到达之间清除缓存,则每条消息仍可能被处理。重复数据删除应被视为一种性能优化,而不是严格保证每个间隔只处理一次。
-
整条消息去重(Whole message deduplication)
需要注意的是,重复数据删除功能应用于整条传入消息,而非单个时间序列键。例如,如果第一条消息包含键 A 并已处理,而后续消息(在重复数据删除间隔内收到)包含键 B,则第二条消息将被跳过,即使它包含一个新键。为了安全地利用重复数据删除功能,请确保您的消息保持一致的结构,以便所有必需的键都包含在同一消息中,从而避免意外的数据丢失。
由于上述情况,独立配置每个持久性操作的能力(包括设置不同的重复数据删除间隔)应被视为性能优化,而不是严格的处理保证。
配置:范围(Scope)

节点通过评估每个传入消息scope元数据中的属性来确定其属性范围。支持的范围类型包括客户端属性、共享属性和服务器属性。算法如下:
- 如果传入消息元数据包含非空
scope属性,则节点会将其值与支持的范围值进行比较:CLIENT_SCOPE对应于客户端属性SHARED_SCOPE对应于共享属性SERVER_SCOPE对应于服务器属性
- 如果找到匹配项,则应用相应的范围并继续处理。
- 如果未找到有效匹配,则消息处理失败。
- 如果该
scope属性不存在或为空字符串,则节点使用节点配置中指定的范围。
配置:高级设置(Advanced settings)

-
仅当值发生变化时保存属性(Save attributes only if the value changes)- 如果启用,节点将首先检索指定属性键的当前值,然后将其与传入值进行比较。如果某个属性缺失、其值已更改或其数据类型与存储的数据类型不同,则会将其标记为保存。如果未检测到任何更改,节点将跳过保存操作。
注意:避免同时写入相同的属性,因为变更检测不是事务性的,在这种情况下可能会产生意外的结果。
注意:如果由于值未改变而跳过属性保存,则不会更新属性的最后更新时间戳。
- 发送属性更新通知(Send attributes updated notification)- 如果启用,并且属性范围不为
CLIENT_SCOPE(即,对于SHARED_SCOPE和SERVER_SCOPE),则节点会将属性更新事件放入名为的队列中Main。 - 强制通知设备(Force notification to the device)- 节点通过评估“强制通知设备”选项以及
notifyDevice传入消息元数据中的属性来确定是否通知设备有关属性更新的信息。算法如下:- 如果启用强制通知设备选项,则节点始终向设备发送属性更新通知,而不管
notifyDevice元数据值如何。 - 如果禁用该选项,节点将检查
notifyDevice消息元数据中的属性:- 如果该属性不存在或为空字符串,则默认发送通知。
true如果提供了该属性,则仅当其值为(忽略大小写)时才发送通知。
- 在所有情况下,仅当设备对更新(或删除)的属性有有效订阅时才会发送通知。
- 此外,在以下情况下不会发送属性通知:
- 跳过属性保存,因为其值未改变(当启用“仅当值改变时保存属性”时)。
- 由于配置的处理策略(例如,设置为“跳过”),因此跳过属性保存。
- 如果启用强制通知设备选项,则节点始终向设备发送属性更新通知,而不管
输出连接
- Success:
- 如果传入消息已成功处理。
- Failure:
- 如果传入的消息类型不是
POST_ATTRIBUTES_REQUEST。 - 如果传入的消息有效负载无法解析为属性键值对。
- 如果传入消息元数据包含非空属性,其值与有效属性范围之一(即、或)
scope不匹配。CLIENT_SCOPESHARED_SCOPESERVER_SCOPE - 如果在消息处理过程中发生意外错误。
- 如果传入的消息类型不是
20.Save timeseries node(保存时间序列节点)
将传入的消息有效负载存储为消息发起者的时间序列数据。
预期的传入消息格式
该节点接受类型的消息POST_TELEMETRY_REQUEST并支持以下三种有效载荷格式:
1.键值对:一个对象,其中每个属性名称代表一个时间序列键,其对应的值为时间序列值。
{
"temperature": 42.2,
"humidity": 70
}
2. 带时间戳的键值对:包含ts时间戳属性和values包含键值对的属性的对象(以格式 1 定义)
{
"ts": 1737963587742,
"values": {
"temperature": 42.2,
"humidity": 70
}
}
3.多个带时间戳的键值对:带时间戳的键值对对象数组(以格式 2 定义)。
[
{
"ts": 1737963595638,
"values": {
"temperature": 42.2,
"humidity": 70
}
},
{
"ts": 1737963601607,
"values": {
"pressure": 2.56,
"velocity": 0.553
}
}
]
配置:处理设置
保存时间序列节点可以执行四个不同的操作,每个操作都由可配置的处理策略控制:
- 时间序列(Time series):将时间序列数据保存到
ts_kv数据库中的表中。 - 最新值(Latest values)
ts_kv_latest:如果新数据较新,则更新数据库表中的时间序列数据。 - WebSockets:通知 WebSocket 订阅有关时间序列数据的更新。
- 计算字段(Calculated fields):通知计算字段有关时间序列数据的更新。
对于每个操作,您可以从以下处理策略中进行选择:
- 对每条消息(On every message):对每条传入消息执行操作。
- 重复数据删除(Deduplicate):仅对可配置时间间隔内来自特定发起者的第一条消息执行此操作。重复数据删除间隔的最小值为 1 秒,最大值为 1 天。为了确定某条消息是否位于先前处理的时间间隔内,系统会使用以下公式计算重复数据删除间隔数:
long intervalNumber = ts / deduplicationIntervalMillis;在哪里:
ts是用于重复数据删除的时间戳(以毫秒为单位)。deduplicationIntervalMillis是配置的重复数据删除间隔(自动转换为毫秒)。intervalNumber确定消息所属的逻辑时间段。
时间戳
ts是使用以下优先级确定的:- 如果消息元数据包含
ts属性(以 UNIX 毫秒为单位),则使用该属性。 - 否则,将使用消息的创建时间。
所有时间戳均为 UNIX 毫秒(UTC)。
- 跳过(Skip):从不执行该操作。
可以使用基本或高级处理设置来设置处理策略。

- 基本处理设置(Basic processing settings)——为所有操作提供预定义的策略:
- 在每封邮件上:将“在每封邮件上”策略应用于所有操作。所有操作均针对所有邮件执行。
- 重复数据删除:将重复数据删除策略(具有指定的间隔)应用于所有操作。
- 仅限 WebSocket:对时间序列和最新值应用“跳过”策略,对 WebSocket 应用“每条消息触发”策略。实际上,数据库中不存储任何内容;数据仅通过 WebSocket 订阅实时获取。

- 高级处理设置(Advanced processing settings)- 允许您独立配置每个操作的处理策略。

在高级模式下配置处理策略时,某些组合可能会导致意外行为。请考虑以下场景:
-
跳过数据库存储(Skipping database storage)
选择禁用一个或多个持久性操作(例如,跳过时间序列或最新值的数据库存储,同时保持 WS 更新启用)会带来仅部分数据可用的风险:
- 如果仅为实时通知(WebSockets)处理消息而不将其存储在数据库中,则历史查询可能与仪表板上的数据不匹配。
- 当时间序列和最新值的处理策略不同步时,遥测数据可能存储在一个表中(例如,时间序列),而相同的数据却不存在于另一个表中(例如,最新值)。
-
禁用 WebSocket (WS) 更新(Disabling WebSocket (WS) updates)
如果禁用 WS 更新,任何时间序列数据的更改都不会推送到仪表板(或其他 WS 订阅)。这意味着即使数据库已更新,仪表板也可能无法显示更新的数据,直到浏览器页面重新加载。
-
跳过计算字段的重新计算(Skipping calculated field recalculation)
如果将遥测数据保存到数据库,同时绕过计算字段的重新计算,则聚合值可能不会更新以反映最新数据。相反,如果使用新数据重新计算计算字段,但相应的遥测值未保留在数据库中,则计算字段的值可能包含未存储的数据。
-
不同操作的重复数据删除间隔不同(Different deduplication intervals across actions)
当您为操作配置不同的重复数据删除间隔时,相同的传入消息可能会因操作不同而得到不同的处理。例如,如果设置为“每条消息” ,则某条消息可能会立即存储在时间序列表中,而不会存储在最新值表中,因为其重复数据删除间隔尚未结束。此外,如果 WebSocket 更新配置了不同的间隔,则仪表板显示的更新可能会与数据库中存储的内容不匹配。
-
重复数据删除缓存清除(Deduplication cache clearing)
重复数据删除机制使用内存缓存来按间隔跟踪已处理的消息。此缓存最多可保留 100 个间隔,最长保留 2 天,但由于使用软引用,条目可能随时被清除。因此,即使在轻负载下也无法保证重复数据删除的有效性。例如,如果重复数据删除间隔为一天,并且消息每小时到达一次,则如果在到达之间清除缓存,则每条消息仍可能被处理。重复数据删除应被视为一种性能优化,而不是严格保证每个间隔只处理一次。
-
整条消息去重(Whole message deduplication)
需要注意的是,重复数据删除功能应用于整条传入消息,而非单个时间序列键。例如,如果第一条消息包含键 A 并已处理,而后续消息(在重复数据删除间隔内收到)包含键 B,则第二条消息将被跳过,即使它包含一个新键。为了安全地利用重复数据删除功能,请确保您的消息保持一致的结构,以便所有必需的键都包含在同一消息中,从而避免意外的数据丢失。
由于上述情况,独立配置每个持久性操作的能力(包括设置不同的重复数据删除间隔)应被视为性能优化,而不是严格的处理保证。
配置:高级设置(Advanced settings)

-
使用服务器时间戳(Use server timestamp)- 如果启用,当时间序列数据没有与其关联的显式时间戳时(使用有效负载格式 1 ),规则节点将使用当前服务器时间。
节点使用以下优先级确定每个时间序列数据点的时间戳:
- 如果时间序列数据包含
ts属性(有效载荷格式 2 和 3),则使用此时间戳。 - 如果启用了使用服务器时间戳选项,则使用当前服务器时间。
- 如果消息元数据包含
ts属性(预计以 UNIX 毫秒为单位),则使用该值。 - 如果以上均未提供,则使用消息创建时的时间戳。
在顺序处理场景中,使用服务器时间尤为重要,因为消息可能来自多个来源,并带有乱序的时间戳。数据库层会进行某些优化,如果新记录的时间戳早于上一条记录,则会忽略属性和最新值的更新。因此,为了确保所有消息都能正确处理,在顺序消息处理场景中,应该启用此参数。
- 如果时间序列数据包含
-
默认 TTL(生存时间)(Default TTL (Time-to-Live)) - 决定存储的数据在数据库中保留的时间。TTL 根据以下优先级设置:
- 如果元数据包含一个
TTL属性(预期为表示秒的整数),则使用该值。 - 如果元数据未指定
TTL,则应用节点配置的 TTL 值。 - 如果节点的配置 TTL 设置为0,则使用租户配置文件中定义的存储 TTL。
- 如果元数据包含一个
注意:TTL 值为 0 表示数据永不过期。
输出连接
- Success:
- 如果传入消息已成功处理。
- Failure:
- 如果传入的消息类型不是
POST_TELEMETRY_REQUEST。 - 如果传入消息有效负载为空(例如,
{}或[]甚至[{}, {}, {}])。 - 如果在消息处理过程中发生意外错误。
- 如果传入的消息类型不是
21.Save to custom table node(保存到自定义表节点)

节点将传入消息有效负载的数据存储到 Cassandra 数据库中,并将其存储到应具有cs_tb_前缀的预定义自定义表中,以避免将数据插入到公共 TB 表中。
请注意,该规则节点只能用于Cassandra DB。
配置:
管理员应设置不带前缀的自定义表名称:cs_tb_。

管理员可以配置消息字段名称与表列名称之间的映射。如果映射键为$entityId,即由消息发起者标识,则相应的列名称(映射值)将被写入消息发起者 ID。

如果指定的消息字段在消息数据中不存在或者不是 JSON 原语,则出站消息将通过失败链路由,否则,消息将通过成功链路由。
注意:请确保您没有在配置中使用元数据键 - 只能使用数据键。
22.Unassign from Customer node(从客户节点取消分配)

取消分配给客户的消息发起者实体。
允许以下消息发起者类型:资产、设备、实体视图、仪表板。
根据客户名称模式查找目标客户,然后取消分配该客户的发起实体。
配置:

- 客户名称模式- 可以设置直接客户名称或使用模式,使用消息元数据将其解析为真实客户名称。
- 客户缓存过期时间- 指定允许存储找到的客户记录的最大时间间隔(秒)。0 值表示记录永不过期。
在以下情况下,消息将通过失败链进行路由:
- 当发起者实体类型不受支持时。
- 目标客户不存在。
在其他情况下,消息将通过成功链进行路由。
5)外部节点(用于与外部系统/外部规则链 交互)
1.AWS lambda节点

Node 将消息发布到 AWS Lambda,这项服务允许您在无需配置或管理服务器的情况下运行代码。它使用 RequestResponse 调用类型发送消息。该节点使用预配置的客户端和指定的函数来运行。
配置:

功能配置
- 函数名称(Function name):必需参数,用于指定应调用哪个 AWS Lambda 函数。
- Qualifier:可选参数,用于指定 Lambda 函数的版本或别名。如果未指定限定符,则将使用默认限定符$LATEST 。
注意:函数名称和限定符字段支持模板化。
AWS 凭证
- AWS 访问密钥 ID和AWS 秘密访问密钥是具有编程访问权限的 AWS IAM 用户的凭证。有关 AWS 访问密钥的更多信息,请参阅此处。
- AWS 区域必须与创建 Lambda 函数的区域相对应。当前的 AWS 区域列表可在此处找到。
高级设置
- 连接超时(Connection timeout):初始建立连接时,在放弃并超时之前等待的时间(以秒为单位)。值 0 表示无穷大,不建议使用。
- 请求超时(Request timeout):等待请求完成的时间(以秒为单位),超过此时间则放弃并超时。0 表示无限长,不建议使用。
- 如果 AWS Lambda 函数执行引发异常,则告知失败(Tell Failure if AWS Lambda function execution raises exception):如果启用,则当 AWS Lambda 函数执行引发异常时,强制消息处理失败。如果禁用,则错误信息将添加到响应负载中,并通过成功链路由消息。
输出
- Success:如果消息被成功处理。
- Failure:如果在消息处理期间发生错误或者 AWS Lambda 函数执行引发异常,并且启用了“如果 AWS Lambda 函数执行引发异常则告知失败”选项。
使用示例:使用 AWS Lambda 监控和处理水表数据
设想以下场景:我们有一个水表物联网设备,它会定期向系统发送用水量更新。我们需要处理这些更新,以检查是否存在异常,并根据用水模式执行特定的操作。
使用 AWS Lambda 节点的解决方案:
- 接收水表数据:我们的规则链从接收水表更新开始。每次更新都包含用水量数据。
- 预处理数据:消息通过转换节点,以适合 AWS Lambda 的格式格式化数据。
- 调用 AWS Lambda 函数:格式化的消息随后将发送到 AWS Lambda 节点。此节点已配置必要的 AWS 凭证和函数详细信息。
- 使用 Lambda 处理数据:调用 AWS Lambda 函数处理用水量数据。它会检查异常情况(例如用水量异常高),并记录结果或触发进一步的操作。
- 处理 Lambda 响应:成功执行后,Lambda 函数将返回响应。AWS Lambda 节点将捕获此响应,并在消息元数据中包含 requestId。
- 基于 Lambda 响应的路由:根据 AWS Lambda 的响应,消息将通过成功路径或失败路径进行路由。成功路径可以继续进一步处理,而失败路径则处理遇到的任何错误或问题。
通过以这种方式利用 AWS Lambda 节点,我们可以高效地处理和响应实时水表数据,利用 AWS Lambda 的数据处理和异常检测功能。

已发布的负载- 节点将消息负载发布到 AWS Lambda。如有需要,可以配置规则链,使用转换节点链将正确的负载发送到 AWS Lambda。
从此节点发出的消息将在消息元数据中包含响应请求 ID。消息有效负载将包含函数执行的结果。
2.AWS SNS 节点

节点将消息发布到 AWS SNS(Amazon Simple Notification Service)。
配置:

- 主题 ARN 模式(Topic ARN pattern)- 可以设置消息发布的直接主题名称或使用模式,使用消息元数据将其解析为真实的 ARN 主题名称。
- AWS 访问密钥 ID(AWS Access Key ID)和AWS 秘密访问密钥(AWS Secret Access Key)是具有编程访问权限的 AWS IAM 用户的凭证。有关 AWS 访问密钥的更多信息,请参阅此处。
- AWS 区域(AWS Region)必须与创建 SNS 主题的区域相对应。最新的 AWS 区域列表可在此处查看。
在以下示例中,主题名称取决于设备类型,并且元数据中有一个包含deviceType字段的消息:
{
deviceType: controller
}
为了在控制器的主题中发布消息,我们将在主题 ARN 模式中设置此模式:
|
在运行时,模式将解析为arn:aws:sns:us-east-1:123456789012:controller
已发布的负载(Published payload)- 节点将向 SNS 发布完整的消息负载。如有需要,可以配置规则链,使用转换节点链将正确的负载发送到 SNS。
从此节点发出的消息将在消息元数据中包含响应的messageId和requestId 。原始消息的有效负载、类型和发起者将保持不变。
3.AWS SQS 节点

节点将消息发布到 AWS SQS(Amazon Simple Queue Service)。
配置:
6)流节点(流节点用于控制消息处理流程)
3.调试
ThingsBoard 提供了查看每个规则节点的传入和传出消息的功能。要启用调试,用户需要确保在主配置窗口中选中“调试模式”复选框
启用调试后,用户只要对应关系类型,就能查看传入和传出消息信息。下图为调试消息视图示例:
4.导入导出
您可以将规则链导出为 JSON 格式,并将其导入到相同或另一个 ThingsBoard 实例。
为了导出规则链,您应该导航到规则链页面并单击特定规则链卡上的导出按钮。
类似地,要导入规则链,您应该导航到规则链页面,然后单击屏幕右下角的大“+”按钮,然后单击导入按钮。
798

被折叠的 条评论
为什么被折叠?



