ThingsBoard MQTT链接、掉线报警、数据转换规则引擎
MQTT 客户端接入
之前都是采用HTTP RESTFUL API方式去接入ThingsBoard。ThingsBoard能够兼容多种协议，今天就来尝试下使用MQTT 客户端接入ThingsBoard。客户端采用MQTTX工具。
hello world
- 新增设备 复制ACCESS_TOKEN,输入到MQTTX客户端的username
- 如上图，输入 v1/devices/me/telemetry 点击发送
ThingsBoard 服务器已经接收到MQTT客户端发送的数据。
设备配置设置
根规则链
默认情况下，根规则处理所有入站消息跟入站事件信息。当系统接入设备越来越多时，根规则链也就越来越复杂。因此平台用户可以根据设备类型创建特殊的规则链，处理各种信息，用来降低根规则链的复杂性。
为了避免上述业务痛点，从ThingsBoard3.2,针对特殊设备，你可以自定义根规则链。新的根规则链接收、处理所有的传感数据，如设备活跃状态、设备生命周期管理(创建、更新、删除)事件。
队列名称
默认情况下，Main队列用于存储所有入站消息、入站事件。传输层提交信息至该队列，规则引擎拉取消息进行事件处理。然后复杂场景下，为了隔离数据处理，你可能需要单独的消息队列进行数据存储。或者针对不同类型的设备使用不同的消息队列。
传输配置
ThingsBoard3.2开始，系统支持两种传输类型: 默认 、MQTT
默认传输类型
默认传输类型旨在兼容早起版本，使用默认传输类型，可以继续使用平台默认的MQTT、HTTP、Coap和LwM2M API来链接设备。默认传输类型没有特定的配置设置
MQTT传输类型
MQTT传输类型启用高级MQTTT传送设置。不同于默认的传输类型，它可以自定义MQTT协议topic 过滤、属性更新等特性。创建一个MQTT传输类型的设备配置文件，如下图:
-
设置MQTT传输类型
指定topic名称 需要注意的是 这里有两个TOPIC; 应用分别如下
- 遥测数据TOPIC筛选器 - 对应设备检测实时数据的topic
- Attributes topic filter - 设备属性(如版本号)上报的topic
两种topic都支持模糊匹配，+号表示匹配一级，#匹配多级
MQTT配置案例
发送检测数据
截图参考下面 规则转换引擎 -> 数据展示部分
发送属性数据
特别注意 要想设备规则生效，需要注意以下两点(本人采坑折腾了个把小时)
-
设置MQTT设备配置为默认配置
-
新增的设备关联MQTT设备配置
规则转换引擎
业务场景
假设设备正在采集并上报温度数据(华氏度)，但是ThingsBoard平台需要展示摄氏度，因此底层需要将他们进行转换，此时规则引擎派上用场，数据转换的公式如下：
[°C] = ([°F] - 32) × 5/9.
增加转换规则节点
点击 ”规则链库“ -> 选中根节点 -> 打开规则链，如下图
转换脚本如下
function precisionRound(number, precision) {
var factor = Math.pow(10, precision);
return Math.round(number * factor) / factor;
}
if (typeof msg.temperature !== 'undefined'){
msg.temperature = precisionRound((msg.temperature -32) * 5 / 9, 2);
}
return {msg: msg, metadata: metadata, msgType: msgType};
验证规则
点击上图 “Test transformer function” 验证脚本是否正常
转换规则节点在规则链中的位置如下
数据展示
如上图，可以在设备最新的数据检查中观察到温度数据已经进行转换。
设备状态监控
物联网开发中，常用的业务是监控设备的状态，出现异常(如掉线)情况则触发报警通知，进行人工干预进行处理。ThingsBoard设备状态检测服务监控设备连接状态，并把连接事件推送给规则引擎。ThingsBoard支持一下四种事件类型：
| Event Type | Description |
|---|---|
| Connect | 设备连接到ThingsBoard时触发 |
| Disconnect | 设备断开链接时触发 |
| Activity | 设备发送数据、属性更新、接口调用时触发 |
| Inactivity | 当设备在一定时间段内不活动时触发 |
下面详细地讲解一下Inactivity事件是如何操作
- 如何通过规则引擎创建Inactivity报警
- 配置Inactivity事件超时参数
新增设备
新增设备 ，并设置Inactivity事件超时参数
-
新增设备 设备名称: Inactivity-timeout-device
-
选中设备 选择属性 -> 服务端属性
-
设置inactivityTimeout属性 6000毫秒，即一分钟
配置根规则链
创建新的根规则链
打开规则链，如下图 光秃秃的啥都没有，后面一个个规则节点添加
添加 Message Type Switch node
这个规则节点将会根据消息类型路由入站信息，比如
- POST_TELEMETRY_REQUEST;
- POST_ATTRIBUTES_REQUEST;
- ACTIVITY_EVENT;
- INACTIVITY_EVENT.
新增 Save Timeseries 节点
将节点关联到Message Type Switch节点，关联类型为 Post telemetry。该节点会保存设备发送的消息至数据中
新增 Server Attributes 节点
节点关联 Message Type Switch 节点，关联类型为Post attributes，该节点会存储设备上报的相关属性信息。
新增 Create Inactivity alarm 节点
节点关联 Message Type Switch 节点，关联类型为Inactivity Event.该节点将根据报警配置产生报警信息。如果存在未清除的报警，则更新报警，否则将创建新的报警。
新增 Clear Inactivity alarm 节点
节点关联 Message Type Switch 节点，关联类型为Activity Event.该节点会存储设备上报的相关属性信息。该节点将根据报警配置清除报警信息(如果存在)。根规则链最终效果图如下
设置为默认节点
设备配置关联规则链
测试验证
curl -v -X POST -d '{"temperature":8}' http://192.168.0.5:8080/api/v1/kkBoG2tWqExmbp9LwXuo/telemetry --header "Content-Type:application/json"
说明,如上图设备最后一次活动时间是 22:15:12 秒，理论上一分钟之后设备变成 Inactivity 状态，什么为什么把报警时间 是 22:16:40,比预期的时间晚了28秒。
回答这个问题，我们需要了解 ThingsBoard 内部检测原理，即ThingsBoard是通过什么样的机制检测设备状态，摘录自官网的一段话：
Device State service uses a global configuration parameter to detect inactivity events. This parameter is defined in thingsboard.yml (state.defaultStateCheckIntervalInSec) and by default it is set to 60 seconds (1 minute).
使用全局的配置检测inactivity 事件，可以修改thingsboard.yml文件中的state.defaultStateCheckIntervalInSec参数，默认60秒。
我试过好几次，添加多个设备观察到本机的inactivity报警时间基本维持在40-41秒这两个值的区间。个人感觉跟ThingsBoard服务的启动时间有关系。为了达到1分钟之后报警，可以尝试去修改下默认参数，测试下。我就不折腾了