本页目录

• 概述
• 设置
  • 规则琏
  • 队列
  • 传输
    • 默认
    • MQTT
      • 主题
      • 设备payload
        • 兼容payload
    • CoAP
      • 默认设备类型
      • NB-IoT
  • 警报规则
    • 示例1. 简单的报警条件
    • 示例2. 持续时间的报警条件
    • 示例3. 重复的报警条件
    • 示例4. 清除警报规则
    • 示例5. 自定义警报规则时间
    • 示例6. 高级
    • 示例7. 租户或客户属性的动态阈值
    • Device profile
    • 通知
  • 设备配置

概述

ThingsBoard 3.2以上版本允许租户管理员通过设备配置为每个设备设置不同的配置，每个设备都会有拥有一个唯一的配置。

你会发现设备类型已经被弃用了而在新版中是通过设备配置进行实现，如果你从老版本进行升级时会根据升级脚本进行自动创建一个设备配置并将其分配到对应的设备。

下面是关于设备配置中的相关设置介绍。

设置

规则琏

Root Rule Chain默认处理所有设备的输入消息和事件，如果你的设备类型太多会导致你的Root Rule Chain变的臃肿和复杂所以平台允许用户自己根据不同设备类型的创建对应的Root Rule Chain从而实现特定的规则琏处理不同设备的消息。

ThingsBoard 3.2开始可以为特定的设备自定义规则琏用于接收所有的telemetry, device activity(Active/Inactive)和设备生命周期(Created/Updated/Deleted)事件，此项设置可以在设备配置向导中进行设置。

队列

Main队列默认处理所有设备的输入消息和事件传输层向队列提交消息，规则引擎轮询队列获取最新消息，队列的分离允许你自定义不同的提交和处理策略。

例如：你希望区分烟雾探测器传感器和其他设备的数据处理，当发现有火警时立即处理数据可以通过消息队列进行隔离，这样即使你的其它设备有百万级别的并发也能保证数据处理的能力。

下面是关于设备配置中的相关设置介绍。

传输

ThingsBoard平台支持传输类型有: Default, MQTT, CoAP, LWM2M和SNMP。

默认

你可以使用平台的默认的MQTT, HTTP, CoAP和LwM2M的API协议进行设备连接。

MQTT

你可以为时序数据和属性指定自定义的MQTT主题分对别对应 遥测上传和属于更新API

MQTT设置如下：

主题

自定义MQTT主题支持’+‘和’#‘通配配符进行数据过滤并允许设备的payload发送JSON或Protobuf数据格式。

发布时序列数据：

1
mosquitto_pub -h 'mqtt.thingsboard.cloud' -i 'c1' -u 't1' -P 'secret' -t '/telemetry' -m '{"humidity": 10.3}'

更新属性数据：

1
mosquitto_pub -h 'mqtt.thingsboard.cloud' -i 'c1' -u 't1' -P 'secret' -t '/attributes' -m '{"firmwareVersion": "1.3"}'

参考实例：

• Step 1. Specify MQTT device topic filter in the Device profile.
• Step 2. Provide basic MQTT credentials for your device with the client id ‘c1’, username ‘t1’ and password ‘secret’.
• Step 3. Use Terminal to publish time-series data.
• Step 4. Transmitted data will be displayed in the "Last telemetry" tab of the device.

设备payload

平台默认接收设备的JSON数据但是也可以使用Protocol Buffers数据格式。

Protocol Buffers和Protobuf是一种与语言和平台无关的序列化结构数据具有体积小的特点。

ThingsBoard平台支持用于遥测上传和属性上传的可自定义原型模式，并实现了为下行消息（RPC调用和属性更新）定义模式的能力。

protobuf的某些特性不支持这是因为ThingsBoard动态解析protobuf结构的原因。

兼容payload

启用后平台将默认使用Protobuf的payload格式，如果解析失败平台将尝试使用JSON的payload格式对于固件更新期间的向后兼容性很有用，例如：固件的初始版本使用Json而新版本使用Protobuf在设备队列的固件更新过程中，需要同时支持Protobuf和JSON兼容模式会导致一点的性能下降因此建议在所有设备更新后禁用此模式。

CoAP

通过CoAP传输类型可以启用高级CoAP传输设置。

默认设备类型

CoAP设备类型的Default将设备的payload设置为支持CoAP API的JSON与Default相同，但是也可以通过CoAP的设备payload更改为Protobuf发送Protocol Buffers数据。

Protocol Buffers和Protobuf是一种与语言和平台无关的序列化结构数据具有体积小的特点。

ThingsBoard平台支持用于遥测上传和属性上传的可自定义原型模式，并实现了为下行消息（RPC调用和属性更新）定义模式的能力。

protobuf的某些特性不支持这是因为ThingsBoard动态解析protobuf结构的原因。

NB-IoT

ThingsBoard平台本支持与下一代Efento NB-IoT传感器集成：

• temperature,
• humidity,
• air pressure,
• differential pressure,
• open / close,
• leakage,
• I/O.

需要固件版本为06.02+的Efento设备。

警报规则

ThingsBoard3.2及以上版本引入警报规则进行简化配置过程而无需通过规则引警进行配置只需要使用”Device Profile”即可，因为在以前的版本中需要一定的编程技巧才能完成。

警报规则包含以下属性：

• Alarm Type - 警报类型在规则内唯一标识；
• Create Conditions - 定义created/updated警报的条件须由以下属性组成：
  • Severity - 用于create/update警报，ThingsBoard按照严重级别的降序验证条件，例如：级别是Critical并且条件为true时只会产生Critical警报并不会产生”Major”、”Minor”或”Warning”条件的警报，每个警报的Severity必须唯一。（例如：同一个警报规则中创建的两个条件不能有相同的Severity）；
  • Key Filters - 使用attributes或telemetry的值逻辑表达式,例如：”(temperature < 0 OR temperature > 20) AND softwareVersion = ‘2.5.5’“*;
  • Condition Type - 简单、持续时间或重复, 例如:如果在连续3次或5分钟内匹配第一个事件，触发简单条件并发出警报；
  • Schedule - 定义规则处于活动状态的时间间隔，“始终启用”、“定时启用”或“自定义启用”；
  • Details - 通过${attributeName}语法的警报的详细信息模板；
• Clear condition - 定义清除警报的条件；
• Advanced settings - 定义警报传播到相关资产、客户、租户或其他实体。

通过示例学习如何使用警报规则，假设冰箱内的温度。 假设已经创建了一个名为“Temperature Sensors”的设备配置并为我们的设备提供了温度传感器和访问令牌”ACCESS_TOKEN”，下面是数据上传命令将数据上传到地址。

1
mosquitto_pub -d -h 'mqtt.thingsboard.cloud' -t "v1/devices/me/telemetry" -u "$ACCESS_TOKEN" -m '{"temperature": 5.3}'

示例1. 简单的报警条件

温度高于10度时创建Critical警报。

• Step 1. Open the device profile and toggle edit mode.
• Step 2. Click the "Add alarm rule" button.
• Step 3. Input Alarm Type and click on the red "+" sign.
• Step 4. Click the "Add Key Filter" button.
• Step 5. Select the "Timeseries" key type. Input the "temperature" key name. Change "Value type" to "Numeric". Click the "Add" button.
• Step 6. Select the "greater than" operation and input the threshold value. Click "Add".
• Step 7. Click the "Save" button.
• Step 8. Finally, apply changes.

示例2. 持续时间的报警条件

假设修改示例1仅当温度超过特定阈值1分钟时才发出警报。

因此需要编辑报警条件并将条件类型从“简单”修改为“持续时间”还应该指定持续时间值和单位。

• Step 1. Edit the alarm condition and change the condition type to "Duration". Specify duration value and unit. Save the condition.
• Step 2. Apply changes.

假设要将1分钟的持续时间替换为指定的设备、客户或租户的设置的动态值。

建议使用服务端属性这个功能。

请为设备创建一个服务器端属性“highTemperatureDurationThreshold” 其整数值是 “1”。

• Step 3. Edit the alarm condition. Go to the dynamic value of the alarm delay by pressing the "Switch to dynamic value" button;
• Step 4. Select a value: current device, current customer or current tenant. And specify the attribute from which the alarm threshold value will be taken. You may optionally check "Inherit from owner". Inheritance allows to take the threshold value from customer if it is not set on the device level. If the attribute value is not set on both device and customer levels, rule will take the value from the tenant attributes;
• Step 5. Apply all changes.

示例3. 重复的报警条件

假设我们想修改示例1仅当传感器连续3次报告温度超过阈值时才发出警报。

因此需要编辑报警条件并将条件类型从“简单”修改为“重复”还应该将“3”指定为“事件数量”。

• Step 1. Edit the alarm condition and change the condition type to "Repeating". Specify "3" as "Count of events" to trigger the alarm. This value will be used by default, if no attribute is set for your device. Save the condition.
• Step 2. Apply changes.

假设要将指定的设备、客户或租户的设置的动态值替换警报条件超出的设定次数。

建议使用服务端属性这个功能。

请为设备创建一个服务器端属性“highTemperatureRepeatingThreshold” 其整数值是 “3”。

• Step 4. Go to the dynamic value of the repeating alarm condition by pressing the "Switch to dynamic value" button;
• Step 5. Select a value: current device, current customer or current tenant. And specify the attribute from which the value will be taken, how many times the threshold value must be exceeded for an alarm to be triggered. You may optionally check "Inherit from owner". Inheritance allows to take the threshold value from customer if it is not set on the device level. If the attribute value is not set on both device and customer levels, rule will take the value from the tenant attributes;
• Step 6. Apply all changes.

示例4. 清除警报规则

假设希望温度恢复正常时自动清除警报。

• Step 1. Open the device profile and toggle edit mode. Click the "Add clear condition" button.
• Step 2. Click on the red "+" sign.
• Step 3. Add Key Filter. Then click Add.
• Step 4. Save the alarm rule condition.
• Step 4. Finally, apply changes.

示例5. 自定义警报规则时间

假设希望警报规则只在工作时进行预警。

• Step 1. Edit the schedule of the alarm rule.
• Step 2. Select timezone, days, time interval, and click "Save".
• Step 3. Finally, apply changes.

示例6. 高级

假设我们的用户能够从仪表板UI设置阈值并启用或禁用每个设备的某些警报，因为我们可以在警报规则中使用动态值进行匹配通过布尔值temperatureAlarmFlag和数字temperatureAlarmThreshold两个属性进行控制，然后匹配条件则是”temperatureAlarmFlag = True AND temperature is greater than temperatureAlarmThreshold“同步满足是产生警报。

• Step 1. Modify the temperature key filter and change the value type to dynamic.
• Step 2. Select a dynamic source type and input the *temperatureAlarmThreshold*, then click "Update". You may optionally check "Inherit from owner". Inheritance allows to take the threshold value from customer if it is not set on the device level. If the attribute value is not set on both device and customer levels, rule will take the value from the tenant attributes.
• Step 3. Add another key filter for the *temperatureAlarmFlag*, then click "Add".
• Step 4. Finally, click "Save" and apply changes.
• Step 5. Provision device attributes either manually or via the script.

示例7. 租户或客户属性的动态阈值

示例6演示了如何根据设备的“temperatureAlarmFlag”属性值启用或禁用规则，如果想为属于租户或客户的所有设备启用或禁用某些规则怎么办？为避免为每个设备配置属性可以配置警报规则以将常量值与租户或客户属性的值进行比较因此使用“常量”键类型并将其与动态值进行比较。

请参阅下面的配置示例：

• Choose constant type and value and compare it with the value of the tenant or customer attribute. Apply all changes.

上述功能可实现启用或禁用规则又或者将设备遥测/属性的过滤器与租户或客户属性的过滤器相结合。

Device profile

设备配置规则节点根据设备配置中定义的警报规则创建和清除警报。 默认情况下这是处理链中的第一个规则节点并对所有输入消息的属性和遥测值做处理。

规则节点中有两个重要的设置：

Persist state of alarm rules - 强制规则节点存储处理状态默认为禁用如果有持续时间或重复条件可以启用此设置；假设有一个条件“温度大于50度并持续1小时”并且在下午1点上报第一个温度大于50度的事件； 下午2点应该会收到警报（假设温度条件不会改变）； 如果将在下午1点之后和下午2点之前重新启动服务器则规则节点需要从数据库中查找状态。

如果启用此选项和‘Fetch state of alarm rules’选项规则节点将能够产生警报否则规则节点将不会产生警报，由于性能原因默认禁用此设置如果需要启用并且输入消息至少符合一个警报条件。

Fetch state of alarm rules - 强制规则节点恢复初始化时的处理状态默认为禁用如果有持续时间或重复条件可以启用此设置；必须与’Persist state of alarm rules’选项同时使用，但是在较少情况下可能设置’Persist state of alarm rules’为禁用。

假设有许多频繁或持续发送数据的设备可以避免在初始化时从数据库加载状态当收到指定设备的第一条消息到达时规则节点将从数据库中获取状态。

通知

假设已经配置了警报规则还希望在ThingsBoard创建或更新警报时收到通知； 设备配置规则节点有三种可以使用输入关系类型：’Alarm Created’,’Alarm Severity Updated’和’Alarm Cleared’。 请参阅下面的示例规则链继续在规则节点中配置自己的设置请确保系统管理员已配置SMS/电子邮件提供商。

使用现有指南： 发送警报电子邮件（’to email’和’send email’”节点的节能） 或Telegram通知； 还有一个额外的’Alarm Updated’关系类型在大多数情况下应该忽略它以避免重复通知。

设备配置

设备配置允许设备在制造期间或之后自动在ThingsBoard中注册；有关详细信息请参阅单独的文档页面。