温控器报警最容易做错的地方，是把它理解成一个布尔条件：温度超过上限，发送消息；温度回到上限以内，关闭消息。这个实现可以在演示中工作，但投入现场后往往同时出现三种问题：补货或化霜造成的短时温升不断误报，持续故障被同一条消息重复轰炸，而操作员点击“确认”后，系统又把尚未恢复的设备当作正常。
可用的报警系统不是阈值集合，而是事件状态机。检测条件只决定异常是否值得进入观察；持续时间决定它是否升级为真实事件；确认表示有人接手；恢复表示设备重新满足健康条件；关闭则意味着这次事件的证据已经完整保存。把这几个动作压缩成一个 alarm=true/false，后续的通知升级、工单、责任追踪和故障复盘都会失去可靠依据。
超温、探头故障、门开过久和断电也不能复用同一条规则。超温是带热惯性的连续量，探头故障首先是数据可信度问题，门磁是离散输入与操作过程问题，断电则常常表现为设备数据突然消失。四类异常需要不同的起始条件、延时、恢复证据和本地保护动作。本文用一组可复现的策略测试解释这些差异；测试数值只是验证状态转换的 fixture，不是可直接复制到任何冷柜、恒温箱或加热设备的现场参数。
一次报警要有完整的生命线
报警事件至少要经历 pending、active、acknowledged 和 recovered 四个有业务含义的状态。pending 用来吸收短时波动；active 表示条件已经持续到必须处理；acknowledged 只说明责任人已经接手；recovered 则要求设备重新满足正常条件并稳定一段时间。是否再增加 closed，取决于平台是否需要人工补充原因、工单结果或损失记录。
状态拆开以后，系统才能回答几个在事故后一定会被追问的问题：异常第一次出现是什么时候，何时满足了报警条件，第一条通知发给了谁，是否有人确认，异常在确认后持续了多久，恢复依据是什么，以及同一故障有没有在短时间内反复出现。单一布尔值只能告诉你“现在亮不亮红灯”，不能重建这条时间线。
状态模型还解决了一个常见歧义：检测恢复和业务关闭不是一回事。温度回落可以让设备进入 recovered，但如果这是一次造成商品损耗的高温事件，平台仍可能要求补充原因和处理结果后才能 closed。相反，普通门开过久事件在柜门关闭并稳定一分钟后，可以按策略自动关闭。事件类型不同，关闭责任也不同。
超温规则必须同时理解热惯性和控制状态
温度越过上限只是一条观测，不足以直接证明设备故障。开门补货、化霜结束、热食品放入柜内或探头附近气流变化，都可能制造短时峰值。若采样周期是十秒，系统连续收到六个超限点，也不代表已经发生需要维修的异常；它可能只覆盖了一分钟，而设备的正常回落时间是十分钟。
更稳妥的超温检测至少包含四部分：进入阈值、持续时间、恢复阈值和恢复保持时间。进入与恢复使用不同阈值，形成滞回，避免温度在边界附近来回切换状态；持续时间过滤瞬时波动；恢复保持则防止一个正常采样就过早关闭事件。Prometheus 的 alerting rule 把类似语义分成 pending、for 和 keep_firing_for，说明“条件出现”和“事件应该触发或结束”本来就是不同问题。温控系统可以借鉴状态语义，但参数必须由目标设备的热惯性和业务风险决定，而不是照搬软件监控示例。
控制状态也必须进入判定上下文。处于主动化霜、开门补货或上电恢复阶段时，同样的温度值代表的风险不同。平台可以延长 pending，降低通知级别，或记录为“受已知操作影响”；如果压缩机已经持续运行、门磁关闭、化霜结束很久，温度仍然上升，才更接近制冷能力下降或冷媒、门封、风道问题。这里不是要用复杂模型替代阈值，而是避免在已知状态下把可解释波动误判成故障。
一条可执行规则可以表达为：只有探头有效、数据新鲜且设备不在允许的化霜窗口时，才评估高温；温度高于进入阈值后进入 pending；持续超过项目配置的时间才创建 active event；温度低于恢复阈值并连续稳定一段时间，才标记 recovered。阈值和时间都必须带配置版本，使事故复盘时能知道当时使用的不是今天刚修改的规则。
固定延时同样不是越长越安全。延时过短会增加误报，延时过长会延迟处置。高价值药品、普通饮料柜和恒温发酵设备的容忍时间完全不同；同一设备在营业时段和夜间无人时段，也可能需要不同升级路径。项目参数应来自热响应测试、允许暴露时间、人员响应速度和后果成本，而不是来自一篇通用文章。
探头故障先否定数据，再决定本地保护
探头开路、短路、越量程或采样值长期不变化时，最危险的做法是继续把这个数值交给温度规则。一个断开的输入可能被解析成极高温或极低温，如果平台同时创建“高温”和“探头故障”两次事件，操作员会以为发生了两个独立问题；更糟的是，本地控制器可能继续依据无效温度驱动压缩机或加热器。
探头有效性应当位于温度判断之前。输入被判定无效后，温度报警规则停止评估，由传感器故障事件接管；本地控制器进入经过风险评估的安全策略，例如关闭高风险输出、使用受限备用探头，或在有明确安全依据时执行限时保底控制。安全动作属于设备固件责任，平台通知不能替代它。现有制冷控制状态测试也采用了“无效探头优先于制冷和化霜”的顺序，并在故障状态关闭压缩机、风扇和加热输出；这证明的是策略顺序可执行，不是任何量产设备已经通过安全认证。
探头故障也需要去抖，但去抖依据不是温度热惯性，而是采集链路特征。单次 CRC 错误、ADC 抖动或总线重试不必立刻升级为故障；连续无效、越界或更新时间超过允许窗口，才应形成 active event。恢复时不能只看到一次合法数值就关闭，至少要确认样本连续有效、时间戳前进，必要时再核对备用探头或控制输出是否回到预期状态。
“数值存在”也不等于“探头正常”。探头固定在一个合理值、采样时间戳停止、设备持续重发缓存数据，都可能骗过简单范围检查。平台需要把 value、quality、sample_time 和设备上报时间分开保存。否则断网后的旧数据会看起来像一条稳定温度曲线，系统反而在最缺信息时显示“正常”。
门开过久和断电分别考验流程与可见性
门磁事件通常不是设备内部故障，而是操作行为、门体机构和制冷负载共同形成的问题。门打开十秒可能是正常取货，三分钟可能需要本地提示，持续更久才需要通知门店；如果同一扇门每天反复出现长开，即使每次最终都关闭，也可能需要形成维护趋势。门开策略因此更适合“短时本地提醒、持续后平台事件、无人确认再升级”的路径。
门磁还必须处理触点抖动和反复开合。平台不应为同一次长开每个采样点创建新事件，而应使用稳定的 event_id 更新持续时间。关闭后先进入恢复保持；保持期内再次打开，应回到原 active event，而不是生成一串“开—关—开”的短事件。只有在关闭稳定、事件证据完整后，下一次开门才获得新的 event ID。
断电则相反：设备可能无法发送“我断电了”。如果网关、平台或独立电源监测仍在线，可以由最后遗嘱、外部电表或离线超时推断；如果整个站点同时失联，平台必须把“设备离线”和“确定断电”区分开。缺少遥测只证明可见性中断，不能自动证明现场电源故障，更不能把最后一条温度值延长成正常状态。
断电事件的恢复条件也比“设备重新上线”严格。设备启动后可能还没加载正确配置，探头还没稳定，继电器保护延时尚未结束，平台时钟也可能没有同步。只有固件版本和配置版本已确认、关键输入有效、第一份新鲜状态快照已上传，本地控制状态进入可解释阶段，平台才能开始恢复保持。重启上线是恢复流程的起点，不是事件关闭证据。
ACK 表示有人负责，不表示设备已经正常
很多告警平台把“确认”按钮同时当作停止通知和关闭事件，这会制造最隐蔽的数据失真。操作员点击 ACK 的真实含义应当是：我看到了这次事件，我或指定责任人开始处理。此时温度可能还在升高，门可能还没关闭，探头可能仍然无效。把状态改成正常，会让监控面板和统计报表提前消失风险。
ACK 后系统可以调整通知策略，例如停止对同一责任人的重复提醒，同时保留超时升级。如果维护人员接手十五分钟后，高温仍未下降，事件可以升级给区域负责人；如果已经创建工单，通知可以携带工单号而不是重复生成新的故障。是否在 ACK 后继续升级，要由责任边界决定，但事件本身必须继续由设备状态驱动，不能由按钮覆盖。
恢复也不能删除 ACK 信息。完整事件应该保留第一次检测、激活、各级通知、确认人、确认时间、处理动作、恢复开始、恢复完成和关闭原因。这些字段使团队能够区分三类问题：设备恢复慢、人员响应慢，还是通知链路本身没有触达。只保存开始和结束时间，会把真正的流程瓶颈藏在一个平均时长里。
当事件需要合规或损失追踪时，关闭权限还应与确认权限分开。门店人员可以 ACK，维修人员可以填写处理结果，区域负责人或质量人员才能关闭。普通商业冷柜未必需要这么重的流程，但数据模型最好预留这些角色，而不是以后用备注字段拼补。
通知系统要围绕事件去重和升级
通知对象不应该是原始采样点，而应该是报警事件。事件键通常至少包含租户、站点、设备和报警类型；如果同一设备有多路探头，还要包含通道。事件处于 active 时，新采样只更新峰值、持续时间和上下文，不创建新 ID。这样短信、App、邮件和工单才能引用同一个事实源，也能判断某个渠道失败后是否需要换渠道，而不是把每次重试当作新报警。
升级计划要回答“多久无人负责”和“风险是否继续扩大”，而不是简单按时间群发。第一层可以发给现场角色；超过确认时限或风险等级提高，再发给区域角色；设备状态持续恶化或站点整体离线时，再进入紧急路径。通知发送成功、用户已读和事件已确认是三个不同证据，任何一个都不能替代另外两个。
去重也不能把不同根因粗暴合并。探头故障导致温度值不可用时，可以抑制派生的高低温事件；门开过久和温度升高则可以保持两个事件，但在界面上建立关联，因为关门动作可能直接解决温升。如果把所有异常合成“设备告警”，操作员看不到优先动作；如果完全不关联，同一现场问题又会触发多条互相竞争的工单。
平台还需要防止通知服务反过来拖垮事件处理。短信接口超时、邮件退信或 App push 失败，应记录为通知投递状态，而不是改变设备事件状态。事件存储先落盘，再异步发送；渠道重试使用幂等键；人工界面始终从事件状态读取，而不是从最后一次通知结果推断是否有故障。
用故障注入验证状态，而不是只点一次推送
本轮新增的确定性测试把四类策略放进同一种事件生命周期，但为每类输入设置不同条件。高温样例使用十分钟 pending、较低的恢复阈值和五分钟恢复保持；门磁使用三分钟 pending、一分钟恢复保持和无人确认后的升级；探头故障先抑制派生温度事件；断电恢复要求设备启动完成并提供新鲜样本。所有数值都只是测试 fixture，目的是让状态转换可复现。
测试首先注入三分钟短时高温。事件从 inactive 进入 pending，温度回落后没有生成通知，证明延时可以过滤这次波动。第二条路径让高温持续到十分钟，系统创建唯一的 high-001 并发送一次通知；操作员 ACK 后，事件仍保持 acknowledged；温度进入恢复区间并稳定五分钟后，才写入 recovered。这个结果直接检查了“确认不等于恢复”。
门磁路径持续输入开门状态，三分钟后创建 door-001。后续重复采样没有增加通知数量；无人确认达到升级时间后只增加一次 escalation；关门后保持一分钟才恢复。探头路径把一个明显异常的温度值和 probeOk=false 同时注入，传感器故障进入 active，而高温规则保持 inactive，避免用无效数值制造第二次报警。
断电路径在失去电源时立即建立 power-001。模拟设备重新供电但尚未启动完成时，事件仍为 active；收到启动完成和新鲜状态后进入恢复保持；保持完成才 recovered。脚本最终通过 22 项确定性断言，并验证重复采样不会创建重复事件。项目实施时，应把同一组状态与去重断言迁移到目标控制器和平台的测试环境，而不是把 fixture 结果当作现场验收。
这组测试证明状态语义和去重逻辑按预期工作，但没有证明真实冷柜能在这些时间内恢复，也没有测试 ZigBee、网关、短信供应商、继电器或传感器硬件。下一步项目验证应把 fixture 换成目标设备的热响应、采样周期、断电行为和人员响应时限，再用硬件在环或现场演练重复同一批断言。
本地控制器与平台不能互相代替
本地控制器负责在网络不可用时仍能安全执行。探头无效后的输出策略、压缩机最小启停时间、化霜保护、本地蜂鸣和门磁输入，都不应依赖云端往返。以现有智能温控器资料为例，设备侧有 NTC 探头、最多三路输入、五路继电器输出、压缩机延时和本地高低温及传感器故障报警，这些能力适合承担第一层保护。
平台负责跨时间、跨设备和跨人员的判断。它可以保存事件历史，比较同类设备，执行通知升级，绑定工单，并识别一个站点同时离线是否更像网络或供电问题。平台也能下发策略配置，但必须带版本和生效结果；如果设备仍在使用旧阈值，界面不能只显示“保存成功”。
网关位于两者之间时，应缓存事件和状态，而不是只转发最新值。断网期间发生并恢复的探头故障，如果只保留重连后的正常温度，会从平台历史中消失。更可靠的做法是为设备事件分配单调序号或唯一 ID，网关确认平台落库后再清理缓存；平台按事件 ID 幂等写入，避免重连重放造成重复通知。
这种分层也给出了失败时的降级边界：平台不可用，本地保护继续；网关不可用，设备保留关键事件；通知渠道不可用，事件仍然存储并在控制台可见。反过来，如果本地控制逻辑本身不安全，增加云端报警不能补救；如果没有事件历史，增加更多通知渠道只会更快地传播噪音。
上线前应验证最容易被忽略的反向路径
正常路径通常很容易测：制造一次超温，看手机是否收到消息。真正决定系统是否可用的是反向路径。短时超限是否在 pending 内自行消失？条件在恢复保持期间再次出现，会回到原事件还是新建事件？ACK 后设备继续恶化，是否仍能升级？探头无效时是否抑制派生温度报警？平台重启后，pending 的计时基准和 active event ID 是否还能恢复？
还要故意让通知渠道失败。短信超时、推送服务返回 500、邮件地址无效，事件是否仍然可见？渠道重试是否复用幂等键？一个渠道成功、另一个失败时，平台是否错误地把整个事件标成“未通知”或“已处理”？这些测试不需要真实冷柜热环境，却能提前暴露数据模型和任务队列的问题。
再把设备和网络故障叠加。设备断电、网关仍在线时，应出现电源或设备离线事件；整个站点同时失联时，应优先显示站点可见性问题，而不是为每台设备发送完全相同的短信。设备恢复后先上报事件缓存，再上报当前状态时，平台能否按时间顺序重建？如果顺序颠倒，界面可能先显示恢复，再补上一条“刚刚断电”，造成错误处置。
最后验证配置变更。修改阈值、延时或升级角色后，旧事件应继续使用创建时的策略快照，新事件使用新版本。否则同一事件的判定依据会在处理中途改变，审计时也无法解释为什么昨天报警、今天同样数值却没有报警。配置发布失败时，平台必须显示哪些设备未生效，而不是用期望版本覆盖真实版本。
什么时候不值得做完整事件平台
只有一台设备、现场长期有人值守、异常后果低，并且本地蜂鸣足以驱动处置时，完整的事件状态机、短信升级和工单集成可能比问题本身更重。此时优先保证探头故障保护、本地高低温报警、压缩机保护和清晰的恢复指示即可。把每次门开都上传到云端，不一定增加价值，反而增加配置和维护成本。
完整事件平台也不替代设备验证与行业流程。医疗冷藏、食品追溯或实验室设备可能还需要校准记录、批次、权限、电子签名和法规要求；本文的状态模型只能作为技术基础，不能自动构成合规证明。固定阈值、响应时间和通知角色必须由目标业务确认。
当设备数量跨越人工巡检能力、异常需要多人接力处理，或者必须证明“谁在什么时候做了什么”时，事件模型才明显优于简单推送。设计起点不应是“支持几种通知渠道”，而应是：什么证据让异常成立，什么动作表示有人负责，什么设备状态才允许恢复，以及一次事件结束后能否完整复盘。
如果你正在把温控器接入多站点设备平台，可以先用冷柜温控器远程监控与告警确认业务价值，再用冷柜控制逻辑核对本地保护边界。进入实施阶段时，优先把本文的状态和故障注入路径转成你自己的自动化测试，而不是先堆更多通知模板。
