Cooldown

A timed block on counting that begins automatically after each Trigger. Its purpose is to prevent rapid re-triggering from a noisy source: once the alert has fired, further breaches for the next Z minutes tell you nothing new, so the node refuses to count them.

Configuration

Cooldown Duration + Cooldown Units in the edit dialog (see Configuration).

0 (the default) disables cooldown entirely — which is simple-reset behavior: after a Trigger the node is immediately idle and the very next candidate starts a fresh cycle. There is no separate "recovery mode" setting; the duration is the whole configuration.

Lifecycle

counting ──count = limit──► TRIGGER (output 1 + 3, fires exactly once)
                                │
                                ▼
                       cooldownstarted (output 3)
                                │
              [ cooldown: candidates blocked, Z counting down ]
                                │
              ┌─────────────────┴─────────────────┐
              ▼                                   ▼
     cooldown completes                    stop received
              │                                   │
     cooldownended (output 3)          stopped (output 3, genuine)
              │                                   │
              ▼                                   │
            idle ◄────────────────────────────────┘

Two guarantees in that sequence:

• The Trigger fires exactly once. cooldownended marks the gate reopening — it does not re-fire the Trigger, which was already reported when the count hit the limit.
• Both cooldown bracket events are source: "internal" — the node's own clock, never a message.

What happens to messages during cooldown

Count candidates are discarded — not counted, not queued — and routed to output 3 as counted events with msg.ignored: true. The running total of discards is visible on every message as msg.ignoredCount (with msg.lastIgnoredTime), and resets when the next counting cycle begins. If you want an alert like "the condition is still breaching during cooldown," wire a switch on timerEvent == "counted" && ignored == true.

Commands all still work during cooldown — but with sharp differences:

Command	During cooldown
stop	Cancels the cooldown immediately — the only thing that does.
reset	Bounces off — ignored: true.
enable / disable	Toggle the flag as normal, but have no effect on the cooldown — disabled and cooldown are fully independent blocking conditions.
query	Reports timerState: "cooldown" with the time remaining in both windowRemaining and cooldownRemaining.
setcountlimit / setwindow	Apply as normal, taking effect for the next cycle.

The stop-only cancellation is deliberate: a cooldown is a protection mechanism, and the commands that routinely appear in flows (reset, enable) should not be able to release it by accident. Cutting it short requires the one command whose meaning is unambiguous.

Interactions

• Heartbeat keeps ticking straight through a cooldown — each tick's snapshot shows timerState: "cooldown" and the remaining time, making the Query output a live cooldown monitor.
• Status label shows Cooldown: 00:02:30 (yellow dot), counting down at the configured reporting cadence. See States.
• Persistence saves and restores an in-progress cooldown across deploys and restarts, at the correct remaining time.

Pattern: pure rate limiter

Count Limit 1 plus a cooldown turns the node into a rate limiter: every accepted message triggers immediately, then nothing passes for the cooldown period. "At most one notification per hour, no matter how often the sensor complains" is Count Limit 1, any window, Cooldown 1 Hour.