告警规则定义了告警触发条件、严重级别设置逻辑以及清除和自动关闭通知的规则，便于管理员和开发者在实时系统中保持控制并快速响应异常。
自ThingsBoard4.3版本起，告警规则配置能力显著增强。规则可在设备、资产、其配置文件甚至客户级别定义，形成尊重组织结构与上下文逻辑的多层监控。可在全局、配置文件或具体设备/实体上精确控制告警产生。
告警唯一性、严重级别、时间戳和告警传播的统一机制，保证数据处理一致，帮助运维高效分析、筛选和处理关键事件。
创建告警规则
告警规则页面可集中管理系统中的全部告警规则（适用于单个实体和配置文件）。
- 在左侧菜单中打开Alarms（告警）页面
- 进入Alarm rules（告警规则）选项卡
- 点击右上角\u201c+\u201d按钮
- 在下拉菜单中选择Create new alarm rule（创建新告警规则）
该页面可集中管理系统中的所有告警规则（适用于单个实体和profile）。
建议：在Device profiles（设备配置）或Asset profiles（资产配置）中创建告警规则，避免在多个实体间重复配置。
常规（General）
\u201c常规（General）\u201d部分定义告警规则的基本配置：
- 告警类型（Alarm type）——告警的名称和唯一标识符（如\u201cHigh Temperature\u201d）。用于标识告警代表的事件，并决定是创建新告警还是更新已有活动告警。
- 实体类型（Entity type）——告警规则将应用的目标实体或实体配置文件。
设置entity type（告警规则应用的目标实体或entity profile）。
调试模式
启用调试模式可追踪与alarm rule执行相关的事件、状态及潜在错误，便于开发和排障。
注意：调试模式可能迅速增加磁盘占用，因为所有调试事件都会存入数据库。 自ThingsBoard 3.9起，平台仅在alarm rule创建后的前15分钟内存储完整调试事件，之后仅保留错误事件。
调试模式设置可组合使用或完全关闭。
参数（Arguments）
定义告警条件前，需至少添加一个参数（argument）——规则评估时使用的数据源。
点击Add argument（添加参数）并配置以下参数：
实体类型（Entity type）
定义参数值的来源：
- 当前实体（Current entity）——当前配置的实体（设备、资产、客户或配置文件）。 若规则在Device profile（设备配置）或Asset profile（资产配置）级创建，将应用于使用该配置文件的所有实体。
- 其他设备或资产（Device/Asset）——引用其他设备或资产的遥测或属性
- 客户（Customer）——从关联的客户实体获取数据
- 当前租户（Current tenant）——使用租户实体的数据
- 当前所有者（Current owner）——使用当前实体所有者的数据
参数类型（Argument type）
定义参数代表的数据类型：
- 属性（Attribute），使用实体上存储的键值属性（如model、maxTemperature），
需指定：
- 属性范围（Attribute scope）：Server attributes、Client attributes或Shared attributes
- 属性键（Attribute key）
- 可选：默认值（Default value）（属性值缺失时使用）
- 最新遥测（Latest telemetry），使用实体的最新时间序列值（如temperature、speed、voltage），
需指定：
- 时序数据键（Time series key）
- 可选：默认值（Default value）
参数名称（Argument name）
输入参数名称——在公式和条件中使用的标识符（如temperature、maxThreshold、deviceEnabled）。
配置完成后点击Add（添加）。
配置完成后点击Add。
触发条件
本步骤定义告警规则的核心逻辑：
- 告警何时创建
- 何种严重级别
- 基于时间计划（schedule）的规则生效时间
点击Add trigger condition（添加触发条件）并配置以下参数：
点击Add trigger condition并配置以下参数。
严重级别（Severity）
在ThingsBoard中，告警严重级别表示告警条件的严重程度，用于确定处理优先级。 可选严重级别：
- Critical — 表示需要立即处理的严重情况，如设备故障、安全风险或可能导致数据丢失或系统停机的状态。
- Major — 表示对系统运行有较大影响、但非立即严重的问题，如性能下降或超出推荐参数运行。
- Minor — 用于稍后监控或处理的较轻问题，如临时超阈值或预警。
- Warning — 表示潜在或正在形成的问题，尚未影响正常运行，但若持续可能需关注。
- Indeterminate — 在告警已产生但无法明确判定严重程度时使用，常因数据不完整或条件模糊。
合理选择严重级别有助于IoT系统的监控、升级和响应。
严重级别如何生效
严重级别应用于：
- 由规则创建的新告警
- 当创建条件以不同标准再次触发时对已有活动告警的更新 例如，若Warning告警仍活动，但新条件达到Major，严重级别将提升。
影响事件优先级、界面展示及自动化流程（Rule Engine、通知规则等）。
条件（Condition）
条件（Condition）定义是否创建或更新告警的逻辑，是判断规则是否满足的主表达式。
示例用途：
- temperature > 30
- device is offline
- 使用多个参数、遥测字段或属性的复杂表达式 （例如temperature > threshold AND doorState == open）
添加创建条件
点击Add condition（添加条件）
通过定义一个或多个过滤器（filter）配置告警触发逻辑。
可手动创建过滤器（filter），或使用TBEL脚本函数实现更复杂的表达式。
点击Add argument filter（添加参数过滤器）并配置：
1. 常规配置（General configuration）
- Argument（参数）——要比较的变量（如temperature）
- Value type（值类型）——评估值的数据类型（Numeric、Boolean、String等）
2. 配置过滤器（Configure filters） 在Filters（过滤器）下点击Add并指定：
- Operation（操作）——比较运算符，如equal、not equal、missing for、greater than、less than等
- Value source（值来源）——选择其一：
- Static（静态）——使用固定预定义值
- Dynamic（动态）——使用从另一参数获取的值
- Value（值）——指定要比较的值
组合多个条件 添加多个过滤器时，选择逻辑运算符：
- AND——所有条件为真
- OR——至少一个条件为真
添加所有需要的过滤器后点击Add（添加）保存条件。
- Argument——要比较的变量（如temperature）。
- Value type——评估值的数据类型（Numeric、Boolean、String等）。
- Operation——比较运算符。
- Value source——选择以下之一。
- Value——指定要比较的值。
- 添加所有需要的filter后点击Add保存条件。
条件类型（Condition types）
ThingsBoard支持三种条件类型：
- Simple（简单） 表达式为真时立即触发，用于即时超阈值。 示例：temperature > 10
- Duration（持续） 条件需在指定时间段内持续为真，可减少短暂数据尖峰带来的误报。 示例：temperature > 10持续60秒
- Repeating（重复） 条件满足指定次数后才触发，适用于重复错误比单次事件更重要。 示例：signalLost == true连续三次
- Simple.表达式为真时立即触发。
- Duration.条件需连续满足指定时长。
- Repeating.条件发生指定次数后才触发。
时间计划（Schedule）
Schedule（时间计划）定义告警创建规则的生效时间段。 系统仅在当前时间处于允许区间内时才评估创建条件。
若创建条件在定义的时间段之外为真，告警不会创建——即使逻辑表达式为真。
Schedule（时间计划）类型
静态模式（Static mode）
ThingsBoard支持三种时间计划（schedule）模式：
- Active all time——始终生效
- Active at a specific time range 示例：周一至周五09:00–18:00
- Custom schedule（自定义时间计划）——为每周每天定义不同时间区间
动态模式（Dynamic mode）
除手动配置时间计划外，可通过属性或遥测提供JSON对象。 适用于不同设备或客户需要不同时间计划的场景。
如何启用动态模式
- 在Schedule（时间计划）部分选择Dynamic mode（动态模式）。
- 选择包含所需时间计划JSON的参数（属性或遥测）。
无需手动配置schedule，可通过attribute或telemetry提供JSON对象。适用于不同设备或Customer需要不同schedule的场景。
时间计划JSON示例
1. 始终生效（Active all time）
JSON对象可为：
1
{}
或
1
2
3
{
"type": "ANY_TIME"
}
2. 特定时间计划（Specific time schedule）
此格式可为选定星期几定义精确时间范围。
示例： 周二和周四全天生效：
1
2
3
4
5
6
7
{
"type": "SPECIFIC_TIME",
"daysOfWeek": [2, 4],
"startsOn": 0,
"endsOn": 0,
"timezone": "Europe/Kiev"
}
字段说明：
- timezone——用于解释时间计划的时区
- daysOfWeek——星期几的数字格式（1–7，1=周一）
- startsOn——生效时段开始时间，距当天开始的毫秒数
- endsOn——生效时段结束时间，距当天开始的毫秒数
当startsOn和endsOn均设为0时，表示规则全天生效。
3. 自定义时间计划（Custom schedule）
为每一天分别定义时间区间。
示例：
时间计划每天24小时生效：
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"type": "CUSTOM",
"timezone": "Europe/Kiev",
"items": [
{ "dayOfWeek": 1, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 2, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 3, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 4, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 5, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 6, "enabled": true, "startsOn": 0, "endsOn": 0 },
{ "dayOfWeek": 7, "enabled": true, "startsOn": 0, "endsOn": 0 }
]
}
字段说明：
- timezone——用于解释时间计划的时区
- items——包含每天配置的数组
每项包含：
- dayOfWeek——数字格式的星期（Monday=1、Tuesday=2等），时间计划在该日生效
- enabled——规则在该日是否生效
- startsOn——时间计划在指定日期生效的起始时间戳（毫秒）
- endsOn——时间计划在指定日期生效的结束时间戳（毫秒）
当startsOn和endsOn均设为0时，表示规则全天生效。
附加信息（Additional info）
附加信息（Additional info）字段可为告警补充有助于事件分析或故障排查的上下文数据。 该信息与告警一并存储，并在告警详情视图中显示，便于运维、技术人员和分析师高效工作。
可添加的有用内容示例：
- 运维备注
- 故障排查步骤
- 文档链接
- 上下文字段，如：
- 区域ID
- 关键阈值说明
- 负责人
移动端仪表盘（Mobile dashboard）
该选项定义用户查看告警时，ThingsBoard移动应用中将打开的移动端仪表盘（mobile dashboard）。
工作方式
选择移动端仪表盘后：
- 进入告警时移动应用会自动打开该仪表盘
- 用户可立即看到相关部件与指标
- 故障排查更快捷
示例场景
- High Temperature告警的诊断仪表盘
- 面向技术人员的带控制按钮的仪表盘
- 移动资产的地理位置仪表盘
特别适用于：
- 现场工程师响应告警
- 需快速诊断
- 监控分布式设备（如冰箱、传感器、车辆）
清除条件
清除条件定义ThingsBoard将告警自动切换为已清除（Cleared）状态的逻辑。
若未配置清除条件，告警永远不会自动清除，即使监控值已恢复正常。
此类情况下，告警只能通过UI或API手动清除。
点击Add clear condition（添加清除条件）并配置以下参数：
步骤5.1清除条件
清除条件规定何时将告警视为已解决，并可安全切换至 Cleared 状态。
清除条件示例：
- temperature ≤ 30
- 值恢复正常范围
- 设备连接恢复
- 涉及多个参数的复杂表达式
添加清除条件
点击Add condition（添加条件）定义告警清除逻辑。
通过添加一个或多个过滤器（filter）配置清除条件。
可手动创建过滤器，或使用TBEL脚本函数实现更复杂场景。
1. 常规配置
点击Add argument filter（添加参数过滤器）并指定：
- Argument（参数） — 要评估的变量（如temperature）
- Value type（值类型） — 期望的输入类型（Numeric、Boolean、String等）
2. 配置过滤器（Filters）
在Filters部分点击Add并设置：
- Operation（操作） — 比较运算符，如equal、not equal、missing for、greater than、less than、greater or equal、less or equal、starts with、ends with、contains、not contains、in、not in
- Value source（值来源）：
- Static（静态） — 使用固定值
- Dynamic（动态） — 使用从另一参数获取的值
- Value（值） — 要比较的值
组合多个条件
若添加多个过滤器，选择逻辑运算符：
- AND — 所有条件必须为真
- OR — 至少一个条件必须为真
添加所有需要的过滤器后点击Add（添加）保存清除条件。
- Value type——评估值的数据类型（Numeric、Boolean、String等）
- Operation——比较运算符。
- Value source——选择以下之一。
- Value——指定要比较的值
- 添加所有需要的filter后点击Add保存条件。
条件类型
ThingsBoard支持与告警创建相同的条件类型：
- Simple（简单） — 条件为真时立即清除
- Duration（持续） — 需持续满足指定时长后才清除
- Repeating（重复） — 条件需满足指定次数后才清除
- Simple.条件为真时立即清除。
- Duration.需持续满足指定时长才清除。
- Repeating.条件满足指定次数后才清除。
完成所有必要配置后，点击Save（保存）保存清除条件。
步骤5.2时间计划（Schedule）
清除时间计划（Clear Schedule）定义清除条件何时允许触发。
示例场景：
- 仅在工作时间允许自动清除
- 仅在夜间允许清除
- 限定在特定时间段内才能清除
若清除条件在允许的时间计划之外为真，告警将不会被清除
- 仅在工作时间允许自动清除
- 仅在夜间允许清除
- 限定在特定时间段内才能清除
步骤5.3附加信息（Additional info）
此区块用于附加将在告警清除时存储于告警详情（Alarm Details）中的额外数据。
适用于：
- 维护结构化事件日志
- 添加运维备注
- 保存额外诊断上下文
- 提供后续操作提示
支持使用 ${attributeName} 动态占位符。
步骤5.4移动端仪表盘（Mobile dashboard）
定义在ThingsBoard移动应用中查看已清除告警时打开的移动端仪表盘（mobile dashboard）。
适用于以下场景：
- 清除后需展示额外诊断信息
- 运维人员需确认系统恢复
- 用户需跳转至其他场景或仪表盘
配置高级设置
在此步骤中，可定义告警传播（alarm propagation） — 告警如何在系统内其他实体间分布。
传播决定了谁可以看到告警以及告警在实体层级的哪一层可见。
这对于多级资产结构、客户层级、企业环境和MSP部署尤为重要。
可用的传播选项
向关联实体传播告警（Propagate alarm to related entities）
启用后，告警对发起实体（originator）的所有相关实体可见，与关系类型无关。
适用于：
- Device（设备）已分配给Asset（资产）
- Asset（资产）已关联至Customer（客户）
- 希望告警在互连实体间可见
这确保关系图中的所有实体（如Device ⇾ Office ⇾ Building）均可查看和处理告警。
启用后，告警对originator的所有相关实体可见，与关系类型无关。
向所有者传播告警（Propagate alarm to the owner (Customer / Tenant)）
使告警对发起实体（originator）的直接所有者可见——即Customer（客户）或Tenant（租户）。
所有者可查看其管理的所有设备/资产告警，无需额外建立关系。
使告警对originator的直接所有者（Customer或Tenant）可见。
向租户传播告警（Propagate alarm to Tenant）
使告警在Tenant级别可见，与所有权或关系无关。
适用于：
- Tenant管理员需查看所有关键事件
- 需要整个基础设施的集中概览
此为最全局的可见性选项。
使告警在Tenant级别可见，与所有权或关系无关。
保存规则
点击Add（添加）保存规则配置。
保存后，ThingsBoard将根据您定义的条件、时间计划和传播设置自动创建、更新和处理告警。
管理告警规则
创建告警规则后，其会出现在Alarms（告警） ⇾ Alarm rules（告警规则）页面的表格中。
在此可快速查看每条规则的关键参数——告警类型（alarm type）、目标实体、严重级别、是否配置清除条件，并使用一组可用操作管理规则。
每条规则行都包含操作面板，用于复制、导出、调试、编辑或删除配置。
每条告警规则都包含用于管理的操作栏：
- Copy alarm rule configuration（复制规则配置） — 复制规则配置，便于基于现有规则快速创建新规则
- Export（导出） — 将规则导出为JSON文件，用于备份或迁移至其他ThingsBoard实例
- Events（事件） — 打开与规则关联的事件日志，包括触发、清除、状态变更和错误
- Debug configuration（调试配置） — 启用调试模式，提供详细执行信息用于故障排查
- Edit（编辑） — 打开规则编辑器，可修改任意配置参数
- Delete（删除） — 从系统中移除告警规则
查看告警规则详情
点击告警规则可查看其详细信息。
编辑告警规则
要修改告警规则，点击该规则，告警规则详情窗口将打开。
点击橙色铅笔图标切换到编辑模式（edit mode）。
完成所需修改后，点击 橙色对勾 图标应用并保存更改。
点击橙色铅笔图标切换到edit mode。
导出/导入告警规则
可将告警规则导出为JSON文件，并导入到同一或其他ThingsBoard实例中。
导出告警规则（Alarm Rule）
- 进入Alarms页面⇾Alarm rules选项卡
- 在对应告警规则行中点击Export（导出）按钮
在对应告警规则行中点击Export按钮。
导入告警规则
ThingsBoard支持以JSON格式导入此前导出的告警规则，便于实例间配置迁移、快速部署标准告警模板以及从备份恢复。
导入步骤：
- 进入Alarms页面⇾Alarm rules选项卡
- 点击右上角\u201c+\u201d按钮，在下拉菜单中选择Import alarm rule（导入告警规则）
- 在导入对话框中拖放JSON文件或手动选择包含告警规则配置的文件
- 点击Import（导入）上传配置
- 在打开的对话框中指定告警规则将应用到的实体或配置文件
- 点击Add（添加）保存规则
保存后，规则将立即生效，ThingsBoard将根据其配置逻辑开始应用。
告警规则配置示例
为更好地理解告警规则的工作方式，下面介绍若干实用示例。每个示例演示特定场景、条件类型或可在实际项目中使用的告警规则功能。
在以下场景中，我们将在设备上直接创建告警规则。
建议：若同一规则需应用于多个设备，请在Device Profile（设备配置）级别创建。 这可实现告警逻辑集中管理、减少重复并简化持续维护。
准备工作
以下示例需要一台名为Thermometer、发送temperature遥测的设备。
- 下载CSV文件：thermometer-device-data.csv
- 进入\u201cDevices\u201d并导入CSV文件。
CSV包含：
- Name：Thermometer
- Type：thermostat
- Time series（时序数据）：temperature
关于CSV的重要说明：temperature键的列类型必须设为\u201cTime series（时序数据）\u201d。
示例1. 简单告警条件：
温度监控 {: #example-1-simple-alarm-condition-temperature-monitoring }
场景：
冷库用于存储易腐商品，内部温度需持续监控以防止货损并维持适宜存储条件。
目标：
当温度超过10°C时创建Critical（严重）告警。
步骤1.创建告警规则
- 从左侧菜单打开Alarms（告警）页面
- 进入Alarm rules（告警规则）选项卡
- 点击右上角\u201c+\u201d按钮
- 在下拉菜单中选择Create new alarm rule（创建新告警规则）
步骤2.常规（General）部分
在General（常规）部分指定：
- Alarm type： High Temperature
- 选择Target entity type（目标实体类型）——Device
- 指定规则应用的entity（实体）——Thermometer
步骤3.添加参数
- 在Arguments（参数）部分点击Add argument（添加参数）并填写：
- Argument name（参数名）： temperature
- Entity type（实体类型）： Current entity
- Argument type（参数类型）： Latest telemetry
- Time series key（时序数据键）： temperature
- 完成后点击Add（添加）
这将创建可在规则逻辑条件中使用的temperature变量。
步骤4.配置触发条件
在Trigger condition（触发条件）部分点击Add trigger condition（添加触发条件）。
步骤4.1 Severity（严重级别）
- Severity： Critical
步骤4.2 Condition（条件）
点击\u201cAdd condition（添加条件）\u201d。
在过滤器配置窗口中点击Add argument filter（添加参数过滤器）并指定：
- Argument（参数）： temperature
- Value type（值类型）： Numeric
- Operation（操作）： greater than
- Value（值）： 10
- 点击Add（添加）
Type（类型）： Simple
- 点击Save（保存）
配置完成后，温度超过 10°C 时将立即创建告警。
步骤5.保存规则
点击Add（添加）保存规则。
结果
保存后，当temperature值超过10°C时，ThingsBoard将自动创建Critical告警。
示例2. 告警清除条件
延续示例简单告警条件：温度监控
场景
冰箱用于存储易腐产品。Critical的High Temperature告警触发后，当温度恢复至安全水平时必须自动清除。
目标
在现有High Temperature规则中添加清除条件，当温度为≤ 4°C时将告警设为Cleared（已清除）。
步骤1.打开High Temperature规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.配置清除条件
滚动到Clear condition（清除条件）部分：
- 点击Add clear condition（添加清除条件）
- 点击\u201cAdd condition（添加条件）\u201d打开配置窗口
步骤2.1添加filter
在配置窗口中点击Add argument filter（添加参数过滤器）并指定：
- Argument（参数）： temperature
- Value type（值类型）： Numeric
- Operation（操作）： less or equal
- Value（值）： 4
此条件定义温度恢复至安全水平的时刻。点击Add（添加）
Type（类型）： Simple
- 点击Save（保存）
此后，温度降至 4°C或以下时将立即清除告警。
步骤3.保存规则
点击Apply（应用）保存更新后的规则。
结果
保存后，ThingsBoard将：
- 温度超过10°C时创建Critical—High Temperature告警
- 温度为≤ 4°C时自动清除告警
此配置形成完整的告警生命周期，保持系统状态准确，无需人工干预。
示例3. 带持续时长的告警条件
延续示例简单告警条件：温度监控
目标：
更新现有 High Temperature 规则，使其仅在温度超过阈值并持续指定时长（如 1分钟）时触发。
此机制有助于避免因短暂温度尖峰引起的误报。
步骤1.打开High Temperature规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.配置触发条件
滚动到Trigger condition（触发条件）部分，编辑现有条件：
- Condition type（条件类型）： 将Simple改为Duration
- Duration value（持续时长值）： 1
- Time unit（时间单位）： Minutes
- 点击Save（保存）应用更新后的告警条件设置
此后，告警仅在温度连续60秒超过阈值时才会触发。
步骤3.保存更新后的规则
点击Apply（应用）保存更新后的规则配置。
结果
保存后，ThingsBoard将：
- 仅在温度超过阈值并持续 整整1分钟时创建 High Temperature 告警
- 忽略短暂的随机温度尖峰
- 提供更稳定、误报更少的告警系统
点击Save保存。
示例4. 带动态持续时长的告警
延续示例带持续时长的告警条件
场景
已配置High Temperature告警，在温度超过阈值并持续1分钟时触发。
本示例将该逻辑扩展为动态持续时长（duration）——即触发告警所需的时长由设备上的服务端属性（server attribute）定义。
目标
更新High Temperature规则，使：
- 仅在温度在设备highTemperatureDurationThreshold 服务端属性中指定的时长内持续高于临界阈值时创建告警
- 无需编辑告警规则即可调整持续时长，仅需更新设备的属性值
准备工作
为Thermometer设备添加服务端属性（server attribute）：
- Key： highTemperatureDurationThreshold
- Value type： Integer
- Value： 2
此值将作为持续时长要求供告警规则使用。
步骤1.打开High Temperature规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.添加参数
在Arguments（参数）部分：
- 点击Add argument（添加参数）
- 填写字段：
- Entity type（实体类型）： Current entity
- Argument type（参数类型）： Attribute
- Attribute scope（属性范围）： Server attributes
- Attribute key（属性键）： highTemperatureDurationThreshold
- Argument name（参数名）： highTemperatureDurationThreshold
- 点击Add（添加）
现在拥有可在Duration条件中使用的动态变量。
步骤3.配置触发条件
滚动到Trigger condition（触发条件）部分，编辑现有条件：
- Condition type（条件类型）： Duration
- Value type（值类型）： 将Static改为Dynamic
- Value（值）： 指定参数highTemperatureDurationThreshold
- Unit（单位）： Minutes
- 在条件块内点击Save（保存）
此后，触发告警所需的持续时长由设备属性决定，而非固定数值。
步骤4.保存规则
点击Apply（应用）保存更新后的配置。
结果
保存后，ThingsBoard将：
- 在以下情况下创建High Temperature告警：温度
- 超过阈值（如>10°C），且
- 在highTemperatureDurationThreshold属性定义的时长内（如2分钟）保持高于阈值
这确保告警仅响应持续偏差，而非短期传感器尖峰。
点击Save保存。
示例5. 带重复条件的告警
延续示例简单告警条件：温度监控
目标：
更新 High Temperature 规则，使告警仅在阈值条件连续满足指定次数时创建。
有助于过滤随机传感器尖峰，仅响应重复或持续的偏差。
步骤1.打开High Temperature规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.编辑触发条件
更改以下参数以更新现有触发条件：
- Condition type（条件类型）： Repeating
- Count of events（事件次数）： 3
点击Save（保存）应用更改。
此配置下，ThingsBoard将在创建告警前检查阈值条件是否连续三次满足。
步骤3.保存规则
点击Apply（应用）保存更新后的配置。
结果
保存后，ThingsBoard行为如下：
- 仅在条件连续3次满足时创建 High Temperature 告警
- 单次或随机温度尖峰不会触发告警
示例6. 定义告警规则时间计划（schedule）
延续示例简单告警条件：温度监控
目标：
更新 High Temperature 规则，使告警仅在工作时间触发。
适用于仅在特定时段（如员工工作时间）需要监控的场景。
步骤1.打开High Temperature规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.配置告警规则时间计划
滚动到Trigger condition（触发条件）部分，打开Schedule（时间计划）设置。
- 选择时间计划类型： Active at a specific time
- 配置工作时间：
- Timezone（时区）： Europe/Kiev (UTC+02:00)
- Days（星期）： Monday、Tuesday、Wednesday、Thursday、Friday
- Time range（时间范围）：
- From（开始）： 10:00
- To（结束）： 19:00
- 点击Save（保存）应用时间计划配置。
此配置下，规则仅在工作日10:00至19:00 生效。
在此时间区间外，即使 temperature > 10°C 为真，系统也不会创建 High Temperature 告警。
步骤3.保存规则
点击Apply（应用）保存更新后的配置。
结果
保存后，ThingsBoard将：
- 仅在工作日 10:00至19:00 激活 High Temperature 规则
- 忽略发生在此时间窗口外的温度阈值违规
- 进入High Temperature规则并打开编辑。
- 打开告警trigger condition的schedule设置。
- 选择schedule type：Active at a specific time。
将规则配置为仅在工作日10:00至19:00生效。点击Save保存。 - 应用更改。
将规则配置为仅在工作日10:00至19:00生效。点击Save保存。
示例7. 高级阈值
延续示例简单告警条件：温度监控
目标：
更新High Temperature规则，添加通过设备级服务端属性（server attribute）启用或禁用告警的能力。
本示例中，告警应仅当以下两个条件均为真时触发：
- temperatureAlarmFlag == true
- temperature > 10°C
这使您可灵活控制特定设备的告警是否激活 — 无需编辑规则。
准备工作
为Thermometer设备添加服务端属性（server attribute）：
- Key： temperatureAlarmFlag
- Type： Boolean
- Value：
true
此属性决定告警规则对该设备是否生效。
步骤1.打开High Temperature告警规则
- 在侧边菜单中进入Alarm（告警）⇾Alarm rules（告警规则）
- 在列表中找到 High Temperature 规则
- 点击 Edit 图标（铅笔）打开规则编辑器
步骤2.添加参数
在Arguments（参数）部分：
- 点击Add argument（添加参数）
- 填写字段：
- Entity type（实体类型）： Current entity
- Argument type（参数类型）： Attribute
- Attribute scope（属性范围）： Server attributes
- Attribute key（属性键）： temperatureAlarmFlag
- Argument name（参数名）： temperatureAlarmFlag
- 点击Add（添加）
现在拥有可在告警条件中使用的布尔变量。
步骤3.配置触发条件
滚动到Trigger condition（触发条件）部分，编辑现有条件。
添加另一条件：
- 点击Add argument filter（添加参数过滤器）并配置：
- Argument（参数）： temperatureAlarmFlag
- Value type（值类型）： Boolean
- Operation（操作）： equal
- Value（值）：
true
- 点击Add（添加）
此过滤器决定告警是否允许针对该设备触发。
步骤4.保存规则
点击Apply（应用）保存更新后的配置。
结果
保存后，ThingsBoard将：
- 仅在以下情况下创建High Temperature告警：
- temperatureAlarmFlag == true，且
- temperature 超过 10°C
- 若temperatureAlarmFlag == false，则对该设备完全忽略该规则，即使超过阈值
点击Add添加。
此方法的优势
- 可无需编辑规则即启用或禁用告警
- 每台设备可有各自的告警激活状态
- 适用于设备间告警策略各异的大型项目
- 便于与仪表盘（dashboard）集成——运维人员可通过简单开关切换告警
后续步骤
-
连接设备 - 根据连接技术或方案学习如何连接设备。
-
数据可视化 - 配置ThingsBoard复杂仪表盘的说明。
-
数据处理与操作 - 学习使用ThingsBoard规则引擎。
-
IoT数据分析 - 学习使用规则引擎执行基本分析任务。
-
高级功能 - 了解ThingsBoard高级功能。
-
贡献与开发 - 了解ThingsBoard贡献与开发。