Z5.06.1Debouncing设计
防抖用于避免短时间内重复触发同一自动化
别名: 去抖 · 冷却时间 · cooldown · 触发抑制
概念解释
防抖（debouncing）是规则触发层的时间过滤：在短时间内抑制对同一自动化的重复触发。它解决的是一类固定的失效——传感信号在判定边界附近抖动时，规则被同一事件反复触发：温度在 26 度上下徘徊，空调规则一分钟内开了又关、关了又开；人在前门传感器前整理钥匙，欢迎规则连发三次。
工程上有两种常用形态：冷却时间（cooldown，触发后一段时间内忽略后续同类触发）与稳定确认（要求条件持续成立一段时间才触发，或阈值来回穿越时保持上一个动作，即滞回）。前者管「触发后」，后者管「触发前」，一个动作可以两者都挂。
机制
为什么必须有防抖？因为物理信号在阈值附近必然抖动。传感器读数是连续量加噪声，规则条件是离散判定：连续量在判定值附近时，噪声把读数反复推过线，每次穿越都是一次完整的「条件成立」。没有时间过滤，规则的触发次数不反映事件次数，只反映噪声在边界附近的逗留时长。
第二个来源是事件本身的重复结构。PIR（人体红外）报告「运动」是脉冲式的：人在传感器前小幅移动会产生一串报告而非一条；门磁在关门时的震动同样可能多次开合触点。对「有人来了开灯」这个意图，一串报告是一个事件；对规则引擎，一串报告是 N 次独立的条件成立。防抖把引擎的事件粒度对齐到人的意图粒度。
第三个来源是规则动作对条件本身的扰动——这是最隐蔽的：空调规则的动作（制冷）会让温度回落，重新穿过触发线，形成自激振荡。系统自己制造了让自己再次触发的条件。冷却时间在这种回路里起相位锁定作用，强制振荡周期不短于冷却窗口。
边界
- 防抖是触发层的概念，救不了判定层的错误。 传感器认错人、活动识别分类错，触发再少也还是错的；把误识别问题寄望于调大冷却时间，是拿时间参数修补语义缺陷。
- 对快速响应类自动化，稳定确认引入不可接受的延迟。 人来开灯要求亚秒级，「持续 30 秒才触发」的确认会让功能名存实亡；安全类（燃气、烟感）更是宁误报不延迟——这类场景用瞬时触发加重复报警，而不是防抖。
- 冷却与确认不可无限叠加。 每层时间过滤都让规则离「发生了什么」更远一层，多层叠加后用户面对的是说不清何时会触发的行为；过滤层数要节制，宁可传感层做干净。
- 重复触发不一定是要抑制的噪声。 「每小时提醒一次喝水」类周期规则、计数类意图（来一次记一次）里，「重复」就是语义本身，套防抖会默默吞掉真实事件。
怎么落地
- 给每条自动化默认挂上触发后冷却，时长按动作后果分级：调光类秒级、通知类分钟级、门锁与购买类小时级并叠加生效时段限制。
- 阈值穿越类条件（温度、湿度、电量）默认启用滞回：26 度开、25 度才关，用一段不动作区间隔开两个方向，消除边界抖动与动作自激。
- 触发历史里区分「触发」与「被抑制」：记录某规则因冷却被跳过的次数——被抑制次数高说明窗口值或条件阈值定得不合理，这是防抖参数需要调整的信号，而不是可以无视的静默。
- 多设备动作的规则对每个设备分别冷却而非整条规则统一冷却：一路窗帘卡住不应让整组设备的重试都被锁死。
- 验证办法：拉一周触发日志，按规则统计「同一分钟内的触发簇」。簇的存在就是防抖缺失或窗口过短的直接证据；没有簇但用户仍抱怨「该触发时没触发」，则是窗口过长，往同组的迟钝问题去查。