Examples: Sliding Window

Sliding mode's defining behavior — the count decaying on its own as messages age out — demonstrated at a scale where you can watch it happen: 3 events within a sliding 15 seconds.

Read Window Modes first if you haven't; this flow is that page made clickable.

Import it

Import → Examples → node-red-contrib-timer-threshold → sliding-window, then Deploy.

What you get

Two inject buttons — Sensor event and Query — into a Timer Threshold node (3 in 15s (sliding) — Count Limit 3, Window 15 Seconds, Sliding mode, Status Reporting Every Second), with a debug on each output.

Walkthrough

1. Watch one message age out. Click Sensor event once. The label reads Counting: 1/3 | Oldest expires: 00:00:14 — in sliding mode the countdown is the oldest message's remaining lifetime, not a shared window. Wait it out. At zero, output 3 emits windowexpired: the last live message aged out, and decay-to-zero is the counting → idle transition.

2. Watch the count decay — silently. Click Sensor event, wait about 10 seconds, click it again. The label shows Counting: 2/3. Now watch: about 5 seconds later — 15 seconds after the first click — the label drops to Counting: 1/3 and output 3 emits nothing. Click Query to confirm: count: 1. Intermediate decay is deliberately silent; only decay to zero emits an event. If a count "mysteriously dropping" ever sends you to Troubleshooting, this is the moment to remember.

3. See why sliding has no boundary blind spot. From idle, click Sensor event, wait ~10 seconds, then click twice quickly. The first click's message is still live (it's only ~10s old), so the two quick clicks bring the live count to 3 — Trigger. Three events within any 15-second span fire it, no matter when the "window" notionally started. In fixed mode, this exact pattern can fail to trigger if a window boundary splits the cluster — see the straddling example on Window Modes.

4. windowRemaining means "next change." While at Counting: 2/3, click Query and look at msg.windowRemaining: it's the time until the oldest message ages out — the moment count will next decay. That makes a query (or a Heartbeat tick) a complete answer to "what is the count, and when does it change?"

Things to try

• Set a Heartbeat Interval of 2 Seconds in the edit dialog and redeploy: output 2 now narrates the decay continuously — source: "internal" snapshots showing the count stepping down without any clicking.
• Recreate step 2's timing but replace the wait with clicks at a steady 10-second pace, one at a time. The count hovers at 2 forever: each new arrival is offset by an old one decaying. That equilibrium is sliding mode expressing "the event rate is below threshold."