Too-short time windows let false triggers recur

What it is

Set the debounce window too short and debouncing is as good as absent: repeats slower than the window still fire every time. The signature symptom is recurring false triggers — the "lights off when the room is empty" rule keeps switching off the light on a person sitting still (they shift occasionally; the sensor reports "present", then "absent" again); a notification rule sounds every quarter hour about the same thing.

"Too short" is not an absolute duration but a relation between the window and the repeat period of events: the window must cover the natural repeat period of same-kind signals in that sensing context, or every repeat is an independent firing. A pet crossing, a thermal draft, family members taking turns to fetch a package — each has its own period; the same 30-second window that suffices for package runs is nowhere near enough for a cat.

Why it happens

The failure mechanism is a mismatch between window and signal period:

• Presence sensing via PIR reports "motion seen", not "person present". A seated person naturally shifts every minute or two; if the silence between shifts outlasts the window, the rule sees present–absent–present–absent. The window must exceed the natural stillness interval of the quietest occupant — minutes, in meeting rooms and studies, far beyond the intuitive "debounce = a few seconds".
• Threshold conditions (temperature, illuminance) with too narrow a hysteresis band have none at all: noise amplitude larger than the band still crosses back and forth. The window (or band) must exceed the noise peak-to-peak, not the "average noise".
• In condition-action feedback loops, a cooldown shorter than the system's response time leaves the oscillation intact: cooling runs 5 minutes before the temperature falls back, but the cooldown re-arms at 3.

A compounding effect follows: facing repeated false triggers, users' first move is often another rule to counteract ("if someone appears within 2 minutes of lights-off, turn them back on") — and the two rules now fire against each other, a fresh oscillation source. False triggers answered with more automation; complexity snowballs.

Where it stops holding

• "Too short" is relative, binned by sensor type and space. Discrete events (door contacts, buttons) barely need windows beyond seconds; presence and threshold sensing need minutes; the exact value depends on installation (a PIR-dense living room and a single doorway sensor have utterly different repeat periods).
• The cost of lengthening cashes out on the other side. Every increase that removes false triggers defers responses to real ones — the reverse trade handled in the same group's discussion of sluggishness. No window minimises both; only a compromise chosen by the relative costs of false fires versus latency.
• Some "repeated firing" is not a window problem at all. A badly placed sensor (facing sun-warmed windows), a mis-set sensitivity dial — the symptom is the same recurring false alarm. Check the physical layer before tuning time parameters, or you are compensating hardware in software.

Applying it

• Set window floors by action consequence: for notifications, at least twice the sensor's repeat period (minutes as a floor in PIR contexts); for rules with feedback loops (climate, lighting control), cooldown longer than the controlled plant's response time constant.
• From trigger logs, compute each rule's same-source firing-interval distribution and let its shape inform the window: the window belongs in the gap between the "noise repeat" cluster and the "real event interval" cluster — the valley between two peaks on the distribution.
• For rules whose false fires are expensive (notifying others, unlocking, spending), double the window rather than hug the floor; for cheap ones (dimming), hug the floor and buy responsiveness.
• When users report "it keeps firing", show the trigger timeline before discussing adjustments: turn "this light is broken" into "window 30 s, intervals 90 s" — adjustment needs a shared language.
• How to check: for two weeks after a change, track both the false-trigger rate (user-flagged "should not have fired") and true-event coverage (fired when it should have). Only a change that lowers the first without lowering the second counts as correct; both numbers moving means something else changed (like sensor position).

Related

• Same group: Z5.06.1 Debouncing prevents the same automation from re-firing within a short window · Z5.06.3 Too-long windows make responses to real change feel sluggish · Z5.06.4 Debounce parameters must be exposed, not buried
• Nearby: Z2.03 The asymmetric costs of false alarms and misses · Z2.01 The capability limits of sensors
• Search terms: cooldown · debounce window · false trigger · PIR sensor