"Rate detection" - can it be done "easily"?

Sort of from my other post about finding the error,

The problem is still a bit unknown to what happened.

It is now possible it was on another machine and the error handling parts of the flow went into overdrive. :frowning:

So, as a possible bit of help, I was wondering if this idea would be possible:

I know there is a way to limit the rate of message passing, with the delay node.
B-u-t....

Is there a way (easy) so: all things being good all messages are passed.
If there is a spike where the messages are climbing over one another that a threshold is exceeded and a signal sent?

That signal would shut a gate and stop the possible feedback loop.

Open to ideas on how to do that.
And if it is really viable.

I am looking at it because a couple of times I have spent/lost a lot of time in the error handling parts of the flows.
When an error happens in them: all hell breaks loose.

Write a function that counts the number of messages received per minute or per 5 minutes. If it exceeds a certain average then continue the flow and send a notification.

Mind you, it seems smelly to me and you are better off catching the error in some way.

Slightly OT: many devices and systems take this approach, but it's generally better to measure and average the interval between messages. There are good theoretical reasons for this, but the practical one is that you can get either a faster indication of rate changes or a longer averaging time very easily.

Yes, I'd probably calculate an average on each message received which means it could trigger as soon as the threshold is met.

There is also this node - https://flows.nodered.org/node/node-red-contrib-msg-speed - that may help give you a message rate which you could use to trigger a switch if too great etc.

2 Likes

(I'll get to the other replies next)

Yeah, I know.

But when you have a catch node and code to decode the error and that code has an error things get messy very VERY quickly.

You get 80 errors in one second.

Per minute (or 5) would be pointless.

The machine is nearly dead in the water after 20 seconds.
(80 x 20 = 2000)

Thanks!

That looks promising.

...if the msg flood with errors are all of the same content, why - in addition to using a gate note to stop the cause of the problem - discard at least the ones already in the system for relief?
Have you seen this? -> https://flows.nodered.org/flow/9410e4cebcc4b68fae73

You seem to be missing what I want to do.

Here is an example of what I had.

Go on, press the PRESS ME button!

[{"id":"9622ad2c.d38ad","type":"catch","z":"b4f1ccd4.5e8d1","name":"","scope":null,"uncaught":false,"x":190,"y":960,"wires":[["bcc89445.e48528","9039d6f0.c8fde8"]]},{"id":"bcc89445.e48528","type":"template","z":"b4f1ccd4.5e8d1","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"You have an error {{error.message}} !","output":"str","x":360,"y":960,"wires":[["5e8d9d8f.d6e79c"]]},{"id":"9039d6f0.c8fde8","type":"function","z":"b4f1ccd4.5e8d1","name":"Read the description for this node.","func":"var n = 23 + 56 / a;\n//var n = 23 + 56 ;\nmsg.payload = n;\nreturn msg;","outputs":1,"noerr":0,"x":430,"y":1010,"wires":[[]],"info":"ONLY for the sake of making an error.\n\nThe code is not \"real\".\n\nIt is only to show you what was happening."},{"id":"5e8d9d8f.d6e79c","type":"debug","z":"b4f1ccd4.5e8d1","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":540,"y":960,"wires":[]},{"id":"17cd6530.85b393","type":"inject","z":"b4f1ccd4.5e8d1","name":"PRESS ME!","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":180,"y":1010,"wires":[["9039d6f0.c8fde8"]]}]

Explain how putting a rate limit will fix the problem.

There is/was/could be an error.

If it is a normal error, I want to know who created it, etc.

If it is in the routine which detects the error, it is a whole different ball game.

Yes, I missed that...OK, I see...thanks for sharing

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.