温度在阈值附近波动，设备就反复开关。规则不仅要判断数值，还要考虑当前状态和时间。
本文使用米家设备、网关与 Node-RED 的架构研究，接入能力按具体型号确认。米家不是一个所有设备都开放相同本地接口的统一协议。设备型号、网关和固件会影响可用能力，本文不声称任意设备都能绕过云端或直接接受自定义控制。
1. 从现象推到机制
迟滞使用不同的开与关阈值，在中间区间保持现状；最小保持时间减少短周期切换。数据过期或质量异常时，不应继续拿旧值触发新动作。目标状态与设备反馈仍需要分开。
图中的四个节点分别表示合成输入、双阈值、保持时间、反馈核对。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先用合成温度序列驱动模拟指示灯。阈值只是演算值，真实负载的允许开关频率需按设备要求设计。
1
2
3
4
OFF and value >= 28 -> request ON
ON and value <= 26 -> request OFF
otherwise -> keep state
if stale or bad_quality -> no automatic transition
先核对本人设备支持的公开接口与授权方式，再用模拟设备打通流程。凭据只在受控配置保存；不提供账户绕过、私有密钥提取或未经确认的实物控制命令。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 数值在二十七附近波动 | 中间区间不反复切换 |
| 传感器停止更新 | 旧值不能继续代表当前环境 |
| 命令发出但设备未改变 | 规则不能直接认定已经执行 |
对照 1：数值在二十七附近波动
中间区间不反复切换。观察时记录当前状态与双阈值。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：传感器停止更新
旧值不能继续代表当前环境。观察时记录最后有效采样时间。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：命令发出但设备未改变
规则不能直接认定已经执行。观察时记录目标与真实反馈。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
迟滞不是安全联锁。涉及加热、动力或人身影响的设备，需要独立保护与人工停止，不能只依靠一个软件阈值。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“命令发出但设备未改变”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
