Debouncing prevents the same automation from re-firing within a short window

What it is

Debouncing is a time filter at the rule-triggering layer: suppressing repeat firings of the same automation within a short interval. It addresses a fixed family of failures — when the sensor signal wobbles around the decision boundary, the rule fires repeatedly for what is one event: the temperature hovering at 26 °C makes the AC rule toggle on and off within a minute; someone fumbling with keys in front of the door sensor fires the welcome routine three times in a row.

Two engineering shapes dominate: a cooldown (after firing, ignore further firings of the same trigger for an interval) and stability confirmation (require the condition to hold for a duration before firing, or keep the last action when the threshold is crossed back and forth — hysteresis). The former guards after the trigger, the latter before it; one action can carry both.

Why it happens

Why is debouncing mandatory? Because physical signals necessarily chatter near thresholds. Sensor readings are continuous quantities plus noise; rule conditions are discrete judgements. When the continuous quantity sits near the decision value, noise pushes the reading across the line repeatedly, and every crossing is a full "condition met". Without a time filter, a rule's firing count reflects not the number of events but how long the noise lingered at the boundary.

A second source is the repetitive structure of events themselves. PIR (passive infrared) reports "motion" as pulses: small movements in front of the sensor produce a burst of reports, not one; a door contact can similarly bounce during closing. To the intent "turn on the light when someone arrives", a burst is one event; to the rule engine it is N independent condition-met events. Debouncing aligns the engine's event granularity with the granularity of intent.

The third source is subtler — the rule's own action disturbs its condition: the AC rule's action (cooling) drives the temperature back down across the trigger line, a self-excited oscillation in which the system manufactures the very condition that refires it. A cooldown acts as phase-locking in such loops, forcing the oscillation period to be no shorter than the window.

Where it stops holding

• Debouncing lives at the trigger layer; it cannot fix judgement-layer errors. Misidentified people, misclassified activities — suppression makes wrong firings rarer but no less wrong. Tuning up a cooldown to treat misrecognition is a time parameter patching a semantic defect.
• Fast-response automations cannot afford stability confirmation. Light-on-arrival needs sub-second latency; "fire only after 30 s of continuous presence" hollows the feature out. Safety classes (gas, smoke) prefer false alarms over delay — instant firing plus repeated alarms, never debouncing.
• Cooldown and confirmation do not stack indefinitely. Each time filter moves the rule one step further from "what happened"; layered filters end in behaviour whose firing time nobody can state. Keep filter depth restrained — better a clean sensor layer than three stacked windows.
• Repeated firing is not always noise. Periodic rules ("remind me to drink every hour") and counting intents (log each arrival) carry repetition as their semantics; debouncing them silently swallows real events.

Applying it

• Attach a default post-trigger cooldown to every automation, graded by consequence: seconds for dimming, minutes for notifications, hours plus active-window limits for locks and purchases.
• Enable hysteresis by default on threshold-crossing conditions (temperature, humidity, battery): on at 26 °C, off at 25 °C — a dead band separating the two directions removes boundary chatter and action self-excitation.
• In trigger history, distinguish "fired" from "suppressed": record how often a rule was skipped by cooldown — a high suppressed count signals a mis-set window or threshold, not silence to be ignored.
• Cool down per device, not per rule, on multi-device actions: one stuck blind must not lock the whole group's retries.
• How to check: pull a week of trigger logs and count per-rule "firing clusters within the same minute". Clusters are direct evidence of missing or too-short windows; clusters absent while users still complain "it didn't fire when it should have" point to over-long windows — the sluggishness discussed in the same group.

Related

• Same group: Z5.06.2 Too-short windows let false triggers recur · 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.01 The capability limits of sensors · Z2.03 The asymmetric costs of false alarms and misses
• Search terms: debouncing · cooldown · hysteresis · sensor noise