Help with concept for `ON/OFF` control scenarios

General
1

(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.

2

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

image
image592×532 26.2 KB

I would have this before the gate node[s] so the flood protection was entirely separate from the message enabled/disabled nodes.

3

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.... :wink: (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?

4

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.

5

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. :wink: ) 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.) :person_shrugging:

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.

6

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.

7

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. :cry:

(Not dumping this on you)

Actually I'll now do a general reply and explain myself another way.

8

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?