阈值每超过一次就发一条告警，可能把同一个持续异常变成几百条重复通知。
本文使用树莓派网关、独立视觉工作进程与合成业务事件。物联网与视觉结合后，数据采集、推理和业务动作有不同速率与可靠性。本文以可停止的演示链路研究状态归属，不把接口成功等同于物理动作完成。
1. 从现象推到机制
告警实例有触发、持续、确认与恢复过程，采样事件不等于告警事件。迟滞和持续时间可以减少抖动，去重键要按设备、规则与异常周期定义。恢复消息也要关联原来的告警实例。
图中的四个节点分别表示有效采样、告警状态、通知事件、处理结果。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用合成温度序列驱动状态机，通知出口先只记录。网络恢复后补传历史样本不应不加区分地重新发送实时告警。
1
2
3
4
NORMAL -> PENDING -> ACTIVE -> RECOVERED
alert_id = device + rule + activation_cycle
notification -> bounded deduplicated event
historical replay -> separate policy from real-time alerting
从单设备单图片开始，保存事件身份和所有输入输出。再逐项加入队列、重试和告警，检查重启后的归属与恢复；外部写入或控制需要明确规则与权限。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 异常持续十分钟 | 不应每次采样都新建告警 |
| 值在阈值附近跳动 | 迟滞与持续条件限制反复触发 |
| 历史样本集中补传 | 不能冒充当前新异常 |
对照 1：异常持续十分钟
不应每次采样都新建告警。观察时记录同一异常周期的告警身份。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：值在阈值附近跳动
迟滞与持续条件限制反复触发。观察时记录状态机与计时依据。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：历史样本集中补传
不能冒充当前新异常。观察时记录采样时间与告警处理模式。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
是否通知、通知谁和升级规则属于业务约定。技术状态正确后，仍需验证接收与处理结果，不能把发送成功当成问题已解决。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“历史样本集中补传”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
