# ThgingsBoard
https://iothub.org.cn/docs/iot/
https://iothub.org.cn/docs/iot/device/device-alarm/
以下警报的主要概念:
发起者
警报发起者是警报的实体例如:如果ThingsBoard收到来自它的温度读数并因读数超过阈值而引发“HighTemperature” 警报则设备A是警报的发起者。
类型
警报类型有助于确定警报的根本原因例如:”HighTemperature”和”LowHumidity”是两个不同的警报。
级别
警报支持级别如下:Critical, Major, Minor, Warning或Indeterminate(按优先级降序排序)。
生命周期
ThingsBoard创建警报时可能处于活动或已清除状态并保留开始和结束时间,警报默认将开始时间和结束时间设置成相同如果警报触发条件重复将更新结束时间,当警报清除条件匹配时自动清除警报,报警清除条件是可选项用户可以手动清除警报。
警报的状态除了有活动和清除外还会跟踪是否已经人为确认过警报通过仪表板或实体详细信息选项卡进行警报确认。
有4个”状态“字段:
标识
ThingsBoard根据发起者、类型和开始时间的组合做为警报的判断依据,因此在相同时间点只能有一个相同的发起者、类型和开始时间的活动警报。
假设已配置警报规则以便在温度大于20时创建”HighTemperature”警报;此外还配置了警报规则以便在温度小于或等于20时清除”HighTemperature”警报。
假设事件序列如下:
因此应该创建一个”HighTemperature”警报开始时间=12:30结束时间=13:00。
ThingsBoard3.2及以上版本引入警报规则进行简化配置过程而无需通过规则引警进行配置只需要使用”Device Profile”即可,因为在以前的版本中需要一定的编程技巧才能完成。
警报规则包含以下属性:
温度高于10度时创建Critical警报。
假设修改示例1仅当温度超过特定阈值1分钟时才发出警报。
因此需要编辑报警条件并将条件类型从“简单”修改为“持续时间”还应该指定持续时间值和单位。
假设要将1分钟的持续时间替换为指定的设备、客户或租户的设置的动态值。
建议使用服务端属性这个功能。
请为设备创建一个服务器端属性*“highTemperatureDurationThreshold”* 其整数值是 “1”。
假设我们想修改示例1仅当传感器连续3次报告温度超过阈值时才发出警报。
因此需要编辑报警条件并将条件类型从“简单”修改为“重复”还应该将“3”指定为“事件数量”。
假设要将指定的设备、客户或租户的设置的动态值替换警报条件超出的设定次数。
建议使用服务端属性这个功能。
请为设备创建一个服务器端属性*“highTemperatureRepeatingThreshold”* 其整数值是 “3”。
假设希望温度恢复正常时自动清除警报。
假设希望警报规则只在工作时进行预警。
假设我们的用户能够从仪表板UI设置阈值并启用或禁用每个设备的某些警报,因为我们可以在警报规则中使用动态值进行匹配通过布尔值temperatureAlarmFlag和数字temperatureAlarmThreshold两个属性进行控制,然后匹配条件则是”temperatureAlarmFlag = True AND temperature is greater than temperatureAlarmThreshold“同步满足是产生警报。
示例6演示了如何根据设备的“temperatureAlarmFlag”属性值启用或禁用规则,如果想为属于租户或客户的所有设备启用或禁用某些规则怎么办?为避免为每个设备配置属性可以配置警报规则以将常量值与租户或客户属性的值进行比较因此使用“常量”键类型并将其与动态值进行比较。
请参阅下面的配置示例:
设备配置规则节点根据设备配置中定义的警报规则创建和清除警报。 默认情况下这是处理链中的第一个规则节点并对所有输入消息的属性和遥测值做处理。
规则节点中有两个重要的设置:
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’关系类型在大多数情况下应该忽略它以避免重复通知。
{
"temperature": 62.2,
"humidity": 79
}
{
"temperature": 40.2,
"humidity": 79
}
# ThgingsBoard
https://iothub.org.cn/docs/iot/
https://iothub.org.cn/docs/iot/device/device-alarm/