Examples: Runtime Commands

Reconfiguring the node from the flow itself: setcountlimit, setwindow, and the disable/enable gate — including the two moments where a set command has immediate, visible consequences. Command reference: Input Messages.

Import it

Import → Examples → node-red-contrib-timer-threshold → runtime-commands, then Deploy.

What you get

Six inject buttons — Sensor event, Set count limit = 2, Set window = 10 seconds, Disable, Enable, and Query — into a Timer Threshold node (5 in 60s (runtime adjustable) — Count Limit 5, Window 60 Seconds, Fixed mode, Status Reporting Every Second), with a debug on each output.

Open the two set-command injects in the editor and note how they're built: the payload is the command string, and the value rides as a separate message property — msg.setcountlimit = number 2 on one; msg.setwindow = number 10 plus msg.setwindowunits = string seconds on the other.

Walkthrough

1. Lower the limit into an immediate Trigger. Click Sensor event twice — Counting: 2/5. Now click Set count limit = 2. Output 3 shows countlimitset (with msg.countLimitSet: 2, the applied value), immediately followed by the Trigger on outputs 1 and 3: the live count already met the new limit. Note the Trigger's payload is exceeded — with no completing click of its own, it cloned the last counted message. The set event dispatches first, so the debug sidebar reads causally: limit changed, therefore triggered.

2. Shrink the window out from under a cycle. Click Sensor event once and let ~15 seconds pass (Window: 00:00:45 or so). Now click Set window = 10 seconds. Output 3 shows windowset (msg.windowSet: 10000 — always echoed in milliseconds), immediately followed by windowexpired: fixed mode re-anchors from the original window start, and 15 elapsed seconds already exceed a 10-second window. Same experiment with more than 10 seconds still remaining and the cycle simply continues against the shorter deadline.

3. Send an invalid value. Edit the Set count limit inject to msg.setcountlimit = 0 (or 2.5, or a string) and click it: output 3 shows countlimitset with ignored: true and the rejected value echoed in msg.countLimitSet. Nothing changed — and nothing was silently swallowed. Restore the inject to 2 afterward.

4. Gate the input. Click Disable, then Sensor event a few times: each click surfaces on output 3 as counted / ignored: true with disabled: true in the envelope. Click Enable and counting resumes. Try a redundant Enable while already enabled: enabled / ignored: true — same no-op pattern as everywhere else.

5. Verify with Query. After steps 1–2, click Query: countLimit: 2 and windowDuration: 10000 — the effective values, not the dialog's. The overrides govern all future cycles too.

One thing to know about overrides

Runtime overrides live in the node's memory: a redeploy or restart returns the node to its configured values — unless the Resume on deploy/restart option is enabled, in which case overrides persist and restore along with everything else. See Persistence.

Things to try

• setwindow also accepts milliseconds, minutes, and hours (singular or plural, any case) in msg.setwindowunits — or omit the property entirely and send msg.setwindow in raw milliseconds.
• Build a two-node arrangement where a timer-events node's output drives this node's Disable/Enable — a scheduled quiet period during which breaches are visible (output 3) but never counted.