# Help with concept for \`ON/OFF\` control scenarios
**URL:** https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671
**Category:** General
**Created:** [27 March 2026 23:22 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671 "2026-03-27T23:22:09Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [27 March 2026 23:22 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/1 "2026-03-27T23:22:09Z")
(Originally I said `gate`, but to be more generic I changed it to `ON/OFF`.)
To get things to work we need an `ON/OFF` control of things at some level.
At the GUI level this done with `buttons` or if you want to get fancy the `template` node and some `CSS` code.
At the CODE level the `gate` node is really handy as it provides a `stop/go` control for message passing.
Which is nice and usually works.
## _Then things get complicated_
For the sake of keeping things as close to the truth:
Voice messages/alerts.
I have _notifications_ for certain things and there is an option to turn them off if desired.
_ **PROBLEM** _
If a machine reboots (alas it has recently happened) it can _flood_ the message queue and it gets annoying.
So I added a _flood detection_ bit of code and if it detects this happening, it stops all messages.
Good: It stops the messages.
Bad: It didn't tell me. (That caused a few minutes of chasing what was going on.)
_ **IDEA** _
Use the existing bit of code to do both.
That can work, but there is now a whole new GUI side of things to address.
(There is a bit of _hidden stuff_ between the `button` and `gate` to _simplify_ what the button shows. It looks at what the button is sending and returns text/colour/etc to it to indicate the condition of the `gate`)
All that is now _void_ as it doesn't _understand_ the difference between a MANUAL intervention and a SYSTEM INITIATED one.
_And: which one has priority?_
Could someone help me get my head around the workings of how this would work?
The layers/structure of it.
I sort of understand it but I am sure there are a lot of things I am not seeing/understanding yet.
Thanks in advance.
---
### Author:  [@jbudd](https://discourse.nodered.org/u/jbudd)
#### Post date: [28 March 2026 00:40 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/2 "2026-03-28T00:40:51Z")
> [@Trying\_to\_learn](#):
>
> _ **PROBLEM** _
> If a machine reboots (alas it has recently happened) it can _flood_ the message queue and it gets annoying.
> So I added a _flood detection_ bit of code and if it detects this happening, it stops all messages.
What is this flood detection?
The "Node-red way" to stem a flood of messages would be a delay node in "Rate limit" mode, perhaps like this
I would have this before the gate node[s] so the flood protection was entirely separate from the message enabled/disabled nodes.
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [28 March 2026 00:46 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/3 "2026-03-28T00:46:49Z")
Ok, badly explained by me.
I have rate limits in there - somewhere.
But for reasons at this point unknown: There are times when a lot of messages _flood_ through the system and it is blurting out messages _for ever in a day_.
Yes, I should find out where that is and address it that point.
But for the sake of _learning_.... 😉 (And this is but an example as I have many uses for this if/when I get it working)
What this does (or the idea) is that if such an event happens, the code detects this _runaway_ event and turns off/closes that gate to prevent on going problems.
But how do I _include_ this feature in the existing code so I can see it is a system defined message and not a use one?
On the flip side:
If I turn it ON (poor use of the word) does that _OVER-RIDE_ the systemic _TURN IT OFF_ if a _FLOOD_ happens?
---
### Author:  [@jbudd](https://discourse.nodered.org/u/jbudd)
#### Post date: [28 March 2026 00:54 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/4 "2026-03-28T00:54:53Z")
I explained my thoughts badly too Andrew.
I personally would not attempt to suppress a flood of messages by opening/closing a gate.
I might use a gate node to semi-permanently disable specific message topics, that's all.
If you don't know where the flood of messages originate, do you know at what point they enter your voice alert setup?
You could use a delay node there to rate limit them by topic.
And I would probably use msg.topic to distinguish different message types. I don't know how you could include it in your existing code though.
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [28 March 2026 01:12 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/5 "2026-03-28T01:12:11Z")
Sorry, but you are concentrating too much on the bad example I used.
Recently I have been _caught_ a few times when things _run away_ in/on flows and I need to stop them _going crazy_ with things.
These are edge cases but alas happen. I need to tidy up the code.
But the number of refinements is (I'm guessing) into the `3` digit values now.
So these things are handy.
Mean time I have useful ON/OFF buttons for things and `subflows` (yeah, don't go there. 😉 ) to _control_ the interactions between the _button_ and the _gate_.
Be it a toggle, DOUBLE CLICK or what ever.
The button changes colour/text to indicate the state and the `gate` obliges with the desired state/condition.
RATHER than having BOTH sets of `gates` (and buttons) I am thinking of amalgamating them into one.
(Theoretically at this point)
So rather than the `button` being `LIME` or `RED` and indicating `ON` or `OFF`, a systemic action can also be included.
So if things _run away_ on me and the `default` status is (kind of obviously) `ON`, then it is changed to `OFF` but the button indicates this to me by being (say) `BLACK` rather than `RED`.
Sorry, the whole idea is still very foggy in how to explain it in a clear way.
(Maybe that isn't helping me understand it either.) 🤷
Is it any clearer to you now though?
(Sorry. EDIT)
Say the condition still exists. I don't want to just press the button and turn it on again without being _told_ the reason it is OFF.
Though if it is BLACK rather than RED, it is kind of self explanatory
But just so you understand the reasoning to why I'm wanting to do it this way.
To get the code _compact_ and robust enough to deal with these scenarios.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [28 March 2026 14:02 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/6 "2026-03-28T14:02:55Z")
> [@Trying\_to\_learn](#):
>
> What this does (or the idea) is that if such an event happens, the code detects this _runaway_ event and turns off/closes that gate to prevent on going problems.
>
> But how do I _include_ this feature in the existing code so I can see it is a system defined message and not a use one?
I think what you might be describing could be considered a case for a "debounce" process?
Basically, gather all notifications within a given time period into a collection and send 1 notification containing everything (or a summary or something else if the number of notifications is large).
Key would be deciding on a suitable debounce period. This is very dependent on the use-case. Could be a few ms, up to maybe a minute.
With this approach, you will always get a notification when something happens but won't get (as?) flooded when a lot happen in a short period.
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [28 March 2026 21:07 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/7 "2026-03-28T21:07:04Z")
Thanks for the reply.
I don't know. Thinking about it, it COULD be that - from what I've described.
Of course now I'm trying to explain it with REAL examples, I can't find any just now. 😢
(Not dumping this on you)
Actually I'll now do a general reply and explain myself another way.
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [28 March 2026 21:29 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/8 "2026-03-28T21:29:30Z")
Ok, after a bit of thinking on the workings of this part:
So far I have an `ON/OFF` thing that is either ON or OFF.
Elsewhere there are _safety systems_ that prevent runaway (_race_?) conditions happening.
These are times when things go awry and lots of _messages_ (as in literal messages in Node-Red) are sent.
_Another_ `gate` is CLOSED and things stop. As in: the messages are stopped at that gate.
But if there are TWO gates, then I need to turn this _second_ one back ON again to put things back to normal.
(I got caught with this recently and lost a few minutes looking for what was causing it - another story.)
So - thinking - I need the indicator to show me these conditions.
For the sake of calling them something:
ON- Normal
OFF - Normal
_TRIPPED_ (I'll get back to this one)
ON - Forced (Or maybe a `reset` so the message toggles things back to the ON- Normal state)
Given:
Normally the mode is ON.
I can turn it OFF and no problems. I'm doing something or just don't want that happening for what ever reason.
TRIPPED is when one of these special conditions happen and it is turned OFF.
ON - FORCED, not sure at this stage. But if for what ever reason I don't want it to trip.
# Another scenario:
Which is kind of the exact opposite of that one.
Say there is a queue processing things normally.
As one thing is completed, the next one is _queued_ into the process.
A system monitors the flow and all is good - usually.
But if something happens - dunno what - and the next one isn't _bumped_ along, things stall.
So if the number gets _stuck_ and doesn't move for a long time, it detects that and FORCES the next one along.
(doesn't happen often but now and then it does.)
To throw a _spanner in the works_ though: Now and then I don't want that to happen.
That is: If things get _stuck_, the next one isn't _bumped_ (triggered) along.
So it needs to be prevented.
The existing _settings_ are again loosely: ON and OFF. ON: Auto bump stalled messages. OFF, don't.
But it lacks an indication on the `BUTTON` if it is turned OFF and a _STALL_ is detected.
# HANG ON!
Now before you start going into the mechanics of all this stuff and the workings, please remember:
I'm not asking about that level.
I am asking for help with the GUI side - kinda.
I have a `subflow` (yeah...... ) for each `button` node.
It _handles_ the stuff sent to the `button` to indicate the state of things and controls the state of the `gate` node, or what ever is downstream of the button.
Mostly it is a `gate` node. But sometimes it is a `change` node that injects a message like:
`payload: trigger, topic: control` to then be sent into the `queue` node (`qgate` I think).
But anyway.
As is the `subflow` handles things at the basic level.
But if I introduce these new conditions it doesn't _work_.
(Of course not It wasn't designed for them.)
So I need help getting my head around the new _structure_ of how to handle the messages arriving indicating the conditions and translating them into messages to send the the `button` and _output_ to then actually get the job done.
Clearer?
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [26 June 2026 21:29 UTC](https://discourse.nodered.org/t/help-with-concept-for-on-off-control-scenarios/100671/9 "2026-06-26T21:29:41Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.