Z5.06.2Time window tuning设计
时间窗设置过短会导致误触发反复出现
别名: 触发窗口 · 冷却窗口 · 窗口过短
概念解释
防抖窗口定短了，防抖等于没装：比窗口长的重复事件照样每次都触发。典型症状是误触发的反复出现——「人离开关灯」的规则在有人久坐不动的房间里反复把灯关掉（坐着的人偶尔晃一下，传感器重新报「在」，然后又「不在」）；通知规则每隔十几分钟响一次，说的都是同一件事。
判断「过短」的标准不是绝对时长，而是窗口与事件重复周期的关系：窗口必须盖过该传感场景下同类信号的自然重复周期，否则每次重复都是一次独立触发。宠物走过、热气流扰动、家人间隔进出的取快递，各有各的周期；同一个 30 秒窗口对取快递够用、对宠物穿行完全不够。
机制
窗口过短时失效的机制是窗口与信号周期的错配：
- PIR 类存在传感只报「看到运动」，不报「人在不在」。坐着的人每隔一两分钟自然晃动一次，晃动之间的静默期若超过窗口，规则看到的就是「有人—没人—有人—没人」。窗口必须长于最安静的人的自然间歇，这在会议室、书房这类场景意味着数分钟量级，远超直觉上「防抖=几秒」的想象。
- 阈值类条件（温度、照度）的过短滞回区间等于没有滞回：噪声幅度大于区间时照样反复穿越。窗口（或区间）必须大于噪声峰峰值，而不是大于「平均噪声」。
- 条件-动作自激回路里，过短的冷却小于系统响应时间时振荡照常发生：制冷 5 分钟后温度回落，冷却却只有 3 分钟，规则在温度还没走远时再次武装。
还有一层叠加效应：过短窗口造成的重复触发，用户的第一反应往往是再建一条规则去抵消（「关灯后 2 分钟内有人就再开灯」），于是两条规则互相触发改写，形成新的振荡源。误触发的问题被用更多自动化回应，复杂度滚雪球。
边界
- 「过短」是相对的，按传感类型与空间分档。 门磁、按钮类离散事件几乎不需要长窗口（秒级足够）；存在传感与阈值类需要分钟级；具体数值取决于安装环境（一间 PIR 密布的客厅与一个只覆盖门口的传感器，重复周期完全不同）。
- 窗口调长的代价在另一侧兑现。 消除误触发的每次调长，都在把真实事件的响应推后——同组关于迟钝的讨论处理这个反向权衡；不存在同时最小化两者的窗口值，只有按误触发代价与迟钝代价的相对大小选的折中。
- 有些「反复触发」不是窗口问题。 传感器安装位置错误（对着窗户晒到太阳）、灵敏度旋钮错位，表现也是反复误报——先查物理层再调时间参数，否则是用软件补偿硬件。
怎么落地
- 按动作后果定窗口下限：通知类不少于该类传感器重复周期的两倍（PIR 场景经验上分钟级起步）；有反馈回路的规则（温控、亮度调节）冷却必须长于被控对象的响应时间常数。
- 触发日志按规则统计同源触发间隔分布，把 p95 间隔写进窗口设定的参考——窗口应落在「噪声重复」与「真实事件间隔」之间的空档里，分布图上就是两簇峰之间的谷。
- 对误触发高代价的规则（向他人发通知、开锁、花钱），宁可窗口翻倍也别贴着下限设；对误触发低代价的（调光），贴下限设，换响应速度。
- 用户报告「老是反复触发」时，先展示触发时间线再谈调整：让用户看到触发簇与间隔，把「这灯有毛病」翻译成「窗口 30 秒，间隔 90 秒」，调整才有共同语言。
- 验证办法：调窗后两周，误触发率（用户标记「不该触发」的次数）与真事件覆盖率（该触发时触发的比例）同时统计——只降前者不降后者才算调对了，两个数都动说明动的是别的东西（如传感器位置）。