动作节点根据传入消息执行各种操作。

Create Alarm 节点

Since TB Version 2.0

此节点尝试为消息发起者加载带有已配置警报类型的最新警报。如果存在未清除的警报，会更新此警报，否则就会创建新警报。
节点配置:

• Alarm Details Builder 脚本
• 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);
}

Alarm Details Builder 脚本函数可以用 Test JavaScript function 来做校验。
详情构建函数示例
函数从上次警报中获取 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 Details Builder 脚本中返回的对象
• Alarm status - 如果是新警报 -> ACTIVE_UNACK。如果是 已经存在的警报 -> 不改变
• Severity - 节点配置选项中的值
• Propagation - 节点配置选项中的值
• Alarm type - 节点配置选项中的值
• Alarm start time - 如果是新警报 -> 当前系统时间。如果是 已经存在的警报 -> 不改变
• Alarm end time - 当前系统时间

出站消息将会拥有以下结构成员:

• Message Type - ALARM
• Originator - 来自入站消息的同一发起人
• Payload - 创建/更新的新警报的 JSON 表达式
• Metadata - 原始消息元数据中的所有字段

当一个新的警报创建后, 出站消息将在元数据中的添加附加属性 - isNewAlarm 的值为 true 时. 消息将走 Created 链传递。现有警报更新后，出站消息将在元数据中添加附加属性 - isExistingAlarm 的值为 true 时. 消息将通过 Updated 的链传递。
以下是出站消息内容的示例

{
  "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"
}

关于 Thingsboard 中警报的更多细节可以在本教程中找到
在下一篇教程中，您可以看到使用此节点的实际示例

• 创建和清除警报

Clear Alarm 节点

Since TB Version 2.0

该节点为消息发起者加载带有已配置警报类型的最新警报，并清除警报 (如果存在)。
节点配置选项:

• Alarm Details Builder 脚本
• Alarm Type -任何表示警报类型的字符串

Alarm Details Builder 脚本用于更新警报详情 JsonNode. 他通常用于在警报中存储额外的参数。例如，您可以从原始消息内容或元数据中保存属性的 name/value 对。
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);
}

Alarm Details Builder script function can be verified using Test JavaScript function.
详情构建函数示例
函数从上次警报中获取 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
• 将 clear time 设置为当前系统时间
• 从 Alarm Details Builder 脚本返回新对象中更新警报详情

如果警报不存在或已清除，原始消息将通过 False 链传递给下一个节点。否则，新消息将通过 Cleared 链传递。
出站消息将会拥有以下结构成员:

• Message Type - ALARM
• 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"
}

关于 Thingsboard 中警报的更多细节可以在本教程中找到
在下一篇教程中，您可以看到使用此节点的实战示例

• 创建和清楚警报

Delay 节点

Since TB Version 2.1

延迟消息的传入，可以配置其时间长短。
配置选项:

• Period in seconds - 指定传入消息挂起的时间长短
• Maximum pending messages - 指定允许的最大挂起消息数量(挂起消息队列)

当传入消息指定的延迟时间达到后，它会本踢出待定队列，并通过 Success 链传递到下一节点。
如果待定消息达到最大限制，那么后面的消息将通过 Failure 链传递。

Generator 节点

Since TB Version 2.0

按照指定时间长度来生成消息。JavaScript 函数用于消息的生成。
节点配置选项:

• 消息生成频率 (秒)
• 消息的发起者
• 将生成实际消息的 JavaScript 函数。

JavaScript 函数接收 3 个输入参数:

• prevMsg - 是以前生成的消息有效载荷。
• prevMetadata - 是以前生成的消息元数据。
• prevMsgType - 是以前生成的消息类型。

脚本应返回以下结构:

{   
    msg: new payload,
    metadata: new metadata,
    msgType: new msgType 
}

返回的结果对象中的所有字段都是可选的，如果未指定，将从以前生成的消息中获取。
此节点的出站消息将是使用配置中 JavaScript 函数构建的新消息。
使用 Test JavaScript function 可以验证 JavaScript 生成器函数。
此节点可用于规则链调试目的。

Log 节点

Since TB Version 2.0

用已配置的 JavaScript 函数将传入消息转换为字符串并将最终值记录到 Thingsboard 日志文件中。
INFO 信息日志级别用于日志记录。
JavaScript 函数接收 3 个输入参数

• metadata - 是消息元数据。
• msg - 是消息有效载荷。
• msgType - 是消息类型。

脚本应该返回字符串值。

使用 Test JavaScript function 可以验证 JavaScript 生成器函数。
您可以在下一个教程中看到使用此节点的实际应用示例:

• 回复 RPC 调用

  RPC Call Reply 节点

  Since TB Version 2.0

向 RPC 调用发起者发送响应。所有传入的 RPC 请求都作为消息在规则链中传递。此外，所有 RPC 请求都有请求 ID 字段。它用于映射请求和响应。消息发起者必须是设备实体，因为 RPC 响应是向消息发起者发送的。
节点配置可以指定请求 ID 字段。如果映射未指定，默认情况下将使用元数据中 requestId 字段。

可以通过不同的传输方式接收 RPC 请求:

• MQTT
• HTTP
• CoAP

消息有效载荷示例:

{
  "method": "setGpio",
  "params": {
    "pin": "23",
    "value": 1
  }
}

在以下情况下，消息将通过 Failure 链传递:

• 入站消息发起人不是设备实体
• 消息元数据中不存在请求 id
• 入站消息有效载荷为空

有关更多 RPC 如何在 Thingsboard 中工作的详细信息，请阅读 RPC 功能文章。
在下一篇教程中，您可以看到使用此节点的实际示例:

• 回复 RPC 调用

  RPC Call Request 节点

  Since TB Version 2.0

向设备发送 RPC 请求，并将响应传递到下级规则节点。消息发起者必须是设备实体，因为 RPC 请求只能发送到设备。
节点配置选项中有超时字段，用于指定等待设备响应的超时时长。

消息有效载荷必须使用正确的 RPC 请求格式。它必须包含 method 和 params 字段。例如:

{
  "method": "setGpio",
  "params": {
    "pin": "23",
    "value": 1
  }
}

如果消息有效载荷中包含 requestId 字段，那么它用于标识对指定设备的 RPC 请求。否则会随机生成 requestId 。
Outbound Message will have same originator and metadata as in inbound Message. Response from the Device will be added into Message payload.出站消息会与入站消息有相同的发起者和元数据。来自设备的响应会被添加到消息有效载荷中。
以下情况下，消息将通过 Failure 链传递:

• 入站消息发起者不是设备实体
• 入站消息缺少 method 或 params 字段
• 如果节点在指定 timeout 内没有收到响应

否则消息将通过 Success 链传递。
有关更多 RPC 如何在 Thingsboard 中工作的详细信息，请阅读 RPC 功能文章。

Save Attributes 节点

Since TB Version 2.0

将传入消息有效中的数据中的属性数据存储到数据库中，并将它们关联到消息发起者标识的实体上。配置的 scope 用于标识属性范围。
支持的范围类型:

• 客户端属性
• 共享属性
• 服务端属性

预期消息类型为 POST_ATTRIBUTES_REQUEST 的消息。如果消息类型不是 POST_ATTRIBUTES_REQUEST，消息将通过 Failure 链传递。
当属性通过现有 API (HTTP/MQTT/CoAP/等) 上传时，有效载荷和类型都正确的消息会被传递到 Root Rule Chain 的 Input 节点中。
如果在规则链中需要触发属性保存动作，则应在规则链配置中将消息有效载荷转换为预期格式，并将消息类型设置为 POST_ATTRIBUTES_REQUEST。可以使用脚本转换节点来完成。
预期的消息有效载荷示例:

{
  "firmware_version": "1.0.1",
  "serial_number": "SN-001"
}

成功保存属性后，原始消息将通过 Success 链传递给下一节点，否则使用 Failure 链。

Save Timeseries 节点

Since TB Version 2.0

将传入消息的有效载荷中的时间序列数据存储到数据库中，并将它们和消息发起者标识的实体相关联。配置的 TTL 秒用于时间序列数据的有效期。0 表示数据永远不会过期。

预期消息类型为 POST_TELEMETRY_REQUEST 的消息。如果消息类型不是 POST_TELEMETRY_REQUEST ，消息将通过 Failure 链传递。
当时间序列数据通过现有 API (HTTP/MQTT/CoAP/等) 推送时，具有正确有效载荷和类型的消息将传递到 Root Rule Chain 的 Input 节点。
如果在规则链中需要触发保存时序数据，则应在规则链配置中将消息有效载荷转换为预期格式，并将消息类型设置为 POST_TELEMETRY_REQUEST。可以使用脚本转换节点来完成转换。
消息元数据必须包含 ts 字段。此字段以毫秒为单位用于标识遥测推送上来的时间戳。
此外，如果消息元数据包含 TTL 字段，则其值用于配置时间序列数据有效期，否则使用节点配置中的 TTL。
预期消息有效载荷示例::

{  
  "values": {
    "key1": "value1",
    "key2": "value2"
  }
}

在时间序列数据成功保存后，原始消息将通过 Success 链传递给下一节点，否则使用 Failure 链。

Save to Custom Table

Since TB Version 2.3.1

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

管理员可以配置消息字段名和表列名之间的映射。如果映射的键是由消息发起者标识 $entity_id，那么在相应的列 (映射值)中将写入消息发起人 id。

如果指定的消息字段不存在或不是JSON Primitive，则出站消息将通过 Failure 链传递，否则将通过 Success 链传递消息。

Assign To Customer 节点

将消息发起者实体分配给客户。
允许使用以下消息发起者类型: Asset, Device, Entity View, Dashboard.
用查找客户名称的方式来找到目标用户，然后将发起者相关的实体分配给该客户。
当用户不存在，且配置选项中 Create new Customer if not exists 的值为 true 时，将创建新客户。
配置选项:

• Customer name pattern - 可以直接设置客户名或使用模式，这将被解析为使用消息元数据的真实客户名称。
• Create new customer if not exists - 如果勾选此项，将创建不存在的新客户。
• Customers cache expiration time - 用于指定搜索结果的客户记录存储的最大有效期(单位秒)，0 表示记录永远不会过期。

在以下情况下，消息将通过 Failure 链路由:

• 不支持的发起者实体类型。
• 目标客户不存在，且 Create customer if not exists 未启用。

其余情况，消息会通过 Success 链路由。

Unassign From Customer 节点

Since TB Version 2.2

将消息发起者实体撤销分配给客户。
允许以下消息发起人类型: Asset, Device, Entity View, Dashboard.
以客户名称为依据查找目标客户，然后撤销为此客户分配发起者实体。
配置选项:

• Customer name pattern - 可以直接设置客户名或使用模式，这将使用消息元数据解析为真实的客户名。
• Customers cache expiration time - 指定存储的搜索到的客户记录的以秒为单位的最大有效期。0 值表示记录永远不会过期。

在以下情况下，消息将通过 Failure 链路由:

• 不支持发起者的实体类型。
• 目标客户不存在。

其他情况，消息将通过 Success 链路由。

Create Relation 节点

Since TB Version 2.2.1

按类型和方向从选定实体创建与消息发起者的关系。
允许以下消息发起者类型: Asset, Device, Entity View, Customer, Tenant, Dashboard.
根据元数据的键方式查找目标实体，然后在发起者实体和目标实体之间创建关系。
如果选择实体类型为 Asset，Device 或 Customer 规则节点且 Create new Entity if not exists 被选中将创建新实体(如果不存在)。
注意: 如果选择了实体类型 Asset 或Device ，您需要设置两种模式:

• 实体名称模式;
  
• 实体类型模式.
  

否则，只应该设置名称模式。
配置选项:

• Direction - 允许以下类型: From, To.
• Relation type - 到消息发起者实体的定向连接的类型。默认类型 Contains 和 Manages 可以从下拉列表中选择。
• Name pattern 和 Type pattern - 可以直接设置可用的实体名称/类型或模式，这将把消息元数据解析为真实实体名称/类型。
• Entities cache expiration time - 指定存储的搜索到的目标实体记录的以秒为单位的最大有效期。0 值表示记录永远不会过期。

在以下情况下，消息将通过 Failure 链路由:

• 不支持发起人实体的类型。
• 目标实体不存在.

其他情况，消息将通过 Success 链传递。
注意: 自从 TB 2.3 版本开始，规则节点能够:

• 根据方向和类型从传入消息的发起者中删除当前关系:
  
  
• 将传入消息的发起者更改为选定实体，并将出站消息作为来自另一个实体的消息处理:
  

Delete Relation 节点

Since TB Version 2.2.1

按类型和方向从所选实体删除与消息发起者的关系。
允许以下消息发起人类型: Asset, Device, Entity View, Customer, Tenant, Dashboard.
根据实体名称方式查找目标实体，然后删除发起者实体与此实体之间的关系。
配置选项:

• Direction - 允许以下类型: From, To.
• Relation type - 到消息发起者实体的定向连接的类型。默认类型 Contains 和 Manages 可以从下拉列表中选择。
• Name pattern - 可以直接设置可用的实体名称/类型或模式，这将把消息元数据解析为真实实体名称/类型。
• Entities cache expiration time - 指定存储的搜索到的目标实体记录的以秒为单位的最大有效期。0 值表示记录永远不会过期。

在以下情况下，消息将通过 Failure 链路由:

• 不支持发起人实体的类型。
• 目标实体不存在.

其他情况，消息将通过 Success 链传递。
注: 自从 TB 2.3 版本开始，规则节点能够通过在规则节点配置中禁用以下复选框来删除从传入消息的发起者到指定实体的关系或基于方向和类型的实体列表的关系:

GPS Geofencing Events 节点

Since TB Version 2.3.1

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

默认情况下，规则节点从消息元数据中获取区域信息。如果未选中 Fetch perimeter information from message metadata ，则应配置额外信息。

从消息元数据获取区域信息

基于周界类型的区域定义有两个选项:

• 多边形
  传入消息的元数据必须包含具有名称区域的键和以下数据结构

  [[lat1,lon1],[lat2,lon2], ... ,[latN,lonN]]

• 圆形

  "centerLatitude": "value1", "centerLongitude": "value2", "range": "value3"
  All values for these keys are in double-precision floating-point data type.
  The "rangeUnit" key requires specific value from a list of METER, KILOMETER, FOOT, MILE, NAUTICAL_MILE (capital letters obligatory).

  从节点配置选项中获取区域信息

  基于周界类型的区域定义有两个选项:

• 多边形

• 圆形

事件类型

由地理围栏规则节点管理的事件有 4 种类型:

• Entered — 每当传入消息的经纬度首次在目标区域内时，就会报告;
• Left — 每当传入消息的经纬度首次不在目标区域内时，就会报告;
• Inside 和 Outside 事件用于报告当前状态。

管理员可以配置产生 inside 或 outside 事件的报告持续时间阈值。例如，每当最小 inside 时间设置为 1 分钟时，消息发起者在进入该区域 60 秒后被视为在区域范围内。最小 outside 时间也定义了何时将消息发送者视为超出范围。

Failure 链将在以下情况下使用:

• 传入消息在数据或元数据中没有配置的纬度或经度键。
• 缺失边界定义;