一. 规则引擎（Rule Engine）

Thingsboard官方解释

规则引擎是一个易于使用的框架，用于构建基于事件的工作流。有3个主要组成部分：

• 消息- 任何传入事件。它可以是来自设备的传入数据、设备生命周期事件、REST API 事件、RPC 请求等。
• 规则节点- 对传入消息执行的功能。有许多不同的节点类型可以过滤、转换或对传入的消息执行某些操作。
• 规则链- 节点通过关系相互连接，因此来自规则节点的出站消息被发送到下一个连接的规则节点。

下图为根规则链：

 Input:

规则链的总数入口

将消息传到下一个规则节点。

Device Profile:

设备配置文件节点。

根据设备配置文件设置处理设备消息

根据设备配置文件中定义的警报规则创建和清除警报。输出关系类型是“已创建警报”、“已更新警报”、“已更新警报严重性”和“已清除警报”，或者如果没有警报受到影响，则只是“成功”。

Message type switch:

二.规则节点（Rule Node）

概念

规则节点是规则引擎的基本组件，它一次处理单个传入消息并生成一个或多个传出消息。规则节点是规则引擎的主要逻辑单元。规则节点可以过滤，丰富，转换传入消息，执行操作或与外部系统通信。
作用：规则节点可以过滤，丰富，转换传入消息，执行操作或与外部系统通信。提供节点自定义能力，实现数据的运算。

规则节点类型

a、过滤节点（用于消息过滤和路由，过滤成功走真链、错误走假链）。示例1：script（脚本过滤器节点）使用javascript条件进行消息过滤（消息msg，metadata消息元数据，msgType消息类型）；示例2：switch（交换节点）将传入消息路由到一个或多个输出链，节点执行已配置的JavaScript函数。
过滤节点：

b、属性集节点：用于更新传入消息的元数据。比如1：消息发起方用户属性（customer attributes），将消息发起方属性信息或者遥测数据加入Metadata元数据中。比如2：设备属性（device attributes），将消息发起方的设备属性或者遥测数据加入metadata。
属性集节点：

c、变换节点：用户更改创立的消息字段，比如，发起方、类型、有效负载，元数据。比如1：脚本转换节点（script），作用：修改消息内容（msg（消息负载）,msgType（消息类型）,metadata（元数据））,可增加，可改。比如2：转换到电子邮件节点（to email），通过使用从消息元数据派生的值填充电子邮件字段，将消息转换为电子邮件消息。设置“ SEND_EMAIL”输出消息类型，以后可以被“ 发送电子邮件节点”接受。可以将所有电子邮件字段配置为使用元数据中的值。

d、动作节点：根据传入的消息执行各种动作。比如1：create alarm（创建告警），通过过滤节点中的过滤脚本判断后，对满足条件的消息进行告警的触发。比如2：log（创建日志），对于系统中的关键系统进行日志输出，比如3：rpc call request（远程RPC调用），监控系统rpc请求，下发控制命令请求。

e、外部节点：提供将消息及数据路由到外部中间件，或者其他第三方云平台中。用于与外部系统进行交互。实例1：kafka(kafka消息中间件)，MQTT(外部MQTT代理)，RabbitMQ,支持将系统中的数据发布到kafka/MQTT代理/RabbitMQ中，供第三方消费者订阅数据。实例2：send email （向外部发送邮件）。实例3：aws sns：将消息发布到aws sns（亚马逊简单消息通知服务，是一种发布\订阅模式的消息收发服务）。

规则节点关系

规则节点之间存在关联性每个节点都有对应关系类型，用于标识关系的逻辑标签。

当规则节点生成输出消息时，它总是将消息路由到下一个指定的节点并通过关系类型进行关联。

表示成功与否的规则节点关系是Success和Failure。

表示逻辑运算的规则节点可以是True或False。

一些特定的规则节点可能使用完全不同的关系类型例如：“Post Telemetry”、“Attributes Updated”、“Entity Created”等。

三.规则链（Rule Chain）

是什么？规则链是规则节点及其关系的逻辑组。接收来自节点的出站消息将其发送至下一个节点。
用法：租户管理员可以定义一个“ 根”规则链，还可以定义多个其他规则链。根规则链处理所有传入的消息，并将其转发到其他规则链以进行其他处理。其他规则链也可以将消息转发到不同的规则链。

四.如何创建一个规则链

在本教程中，我们将配置 ThingsBoard 规则引擎以存储 -40 至 80°C 范围内的所有温度，并将所有其他读数记录到系统日志中。

在 Thingsboard UI 中，转到Rule Chains部分并打开Root Rule Chain。

将脚本过滤器规则节点拖放到链中。将打开节点配置窗口。

可以使用TBEL（ThingsBoard 表达式语言）或 JavaScript 来开发用户定义的函数。我们建议使用TBEL，因为与 JS 相比，它在 ThingsBoard 中的执行效率更高。

TBEL

return msg.temperature == null
|| (msg.temperature >= -40 && msg.temperature <= 80);

return typeof msg.temperature === 'undefined'
 || (msg.temperature >= -40 && msg.temperature <= 80);

如果未定义温度属性或温度有效 - 脚本将返回True，否则将返回False。如果脚本返回True，传入消息将被路由到与True关系连接的下一个节点。

现在我们希望所有遥测请求都通过此验证脚本。我们需要删除Message Type Switch节点和Save Telemetry节点 之间现有的Post Telemetry关系：

并使用Post Telemetry关系将Message Type Switch节点与Script Filter节点连接起来：

接下来，我们需要使用True关系将Script Filter节点与Save Telemetry节点连接起来。所以所有有效的遥测数据都将被保存：

此外，我们将使用False关系将Script Filter节点与Log Other节点连接起来。这样所有无效的遥测都将记录在系统日志中：

按保存按钮应用更改。

验证结果

为了验证结果，我们需要创建设备并将遥测数据提交到 Thingsboard。所以转到设备部分并创建新设备：

对于发布设备遥测，我们将使用Rest API。为此，我们需要从设备DHT22复制设备访问令牌。

使用终端将发送温度读数 = 99 的消息。将$ACCESS_TOKEN替换为实际的设备令牌。

这里我们是用的是MQTTBox,做如下设置：

保存。此时我们可以看到连接状态为Connected，表示连接成功。

点击Add publisher,做如下配置：

Topic to publish表示订阅的主题；Payload表示发送的消息；我们把消息发送到如下主题：

v1/devices/me/telemetry
{"temperature": 99}

点击publish。

 我们查看DHT22发现并没有遥测数据。

 这是因为我们设置的规则链，判断temperature不满足大于等于-40，小于等于80这个条件。

return typeof msg.temperature === 'undefined'
|| (msg.temperature >= -40 && msg.temperature <= 80);

当我们传输

{"temperature": 33}

可以看到，遥测显示33。

测试成功。