I'm after (I think anyway) a rate limited gate

So end result required
Messages arrive and I want them rate limited (at least 1/sec) to give upstream nodes a chance to deal with them

But I want the messages to be gated, so that if upstream nodes take 2s - the next message isn't released until told to do so by a control message

Does my requirement make sense?

And has anyone already done something like this?

Hi @cymplecy,

Can I recommend a node I created to offer this kind of control?

its semaphore node, but with a dynamic fails safe?

1 Like

Ta - I'll have a play

From my own read me :angel:

This is a set of Nodes for Node RED, that allows messages to be queued, and signalled to pass, once a message has reached the end of the flow. But at the same time, allowing an optional fail-safe, that can be controlled dynamically.

Furthermore, messages can be flagged to bypass the semaphore and 'sneak' past the messages waiting for the lock to be released.
This is achieved with either a single messge property, or a JSONata expression.

Its not a limiter - more a node(s) to tightly control access to different parts off the flow

This flow has just sat there for 30 mins while I went and made breakfast :frowning:

The fail-safe is global.

it looks like you clicked this one first?
and only released once?

I should re-order the example flow :sweat_smile:

Each message sets the current fail-safe, once it passes if that makes sense.

LQ - Local Queue
GQ - Global Queue
LFS - Last Fail Safe that was Set

I'll go and make a cup of coffee and re-read that several times before replying further :slight_smile:

1 Like

it looks like you done something like this..

x2 (should be x3) - as the 3rd message, would have it to disable the fail safe

Nov-05-2023 10-08-05

The last message to pass (allow through) is the message that sets the current active fail-safe
the 3rd message inject at the top set it to disabled

Yes- that's what I did :slight_smile:

What's all this local queue, global queue?

The whole engine works with a global queue - where each take contributes to that queue.

but at the same - the takes of course know what they, them self have waiting.

So the status' are just showing you the state of the engine

QG - The Queue size for all Takes
LQ - The Queue size for this Take
LFS - The fail-safe time currently enforced (globally)

1 Like

Ok :slight_smile:
I'll try actually using it with my MQTT project and see how it goes :slight_smile:

1 Like

Screenshot 2023-11-05 at 10.29.06

2 xLQ (5+4) = GQ = 9

Got it :slight_smile:

Why is there a config? Does this mean I can have independent flows with their own global queues?


As the nodes share an engine, it needs a config for it (it manages the queue side of it all)
so you can have 2 independent globe queues (just set them in the node that belong to that global queue)

The idea with the FS Reset node
if you set the fail-safe to say 5s, then if a message taking longer then 5s (say 4s) , you can extend (if you want) that current fail-safe to say 10s - meaning the next message will wait 10s (instead of 5s)

then once the 10s message passes, it will again set it to 5s - unless you extend again
that is the dynamic side of the fail-safe :smile:

Hi cymplecy,
I know you prefer to use standard nodes if at all possible.
Just to note you can use the delay node in rate limit, and msg.flush 1 to release next message.
So set rate limit to high value say 60 second
once up stream nodes have finish feed msg.flush = 1 back to the rate limit node, making sure there are no other msg properties in the message.
There are several examples of this on the forum How to create a sequence to send msg one after another instead in parallel - #4 by E1cid


Can you explain in a bit more detail exactly what the purpose is? I suspect there may be a better way.

Should that be downstream (ie later) nodes?

1 Like

Can I clear the queue?

@E1cid @colin I'll circle back round if this semaphore thing gets too complex :slight_smile: And yes - I meant down-stream :slight_smile:

Not presently :frowning_face:
the only way is to trigger the release a few times
messages are released with msg.smp_isFailsafe which denotes if they are released due to the FS being triggered (not sure it helps though)

But I think @Colin suggested that also when I was building it (I should really add it)

:frowning: shame - it's making testing a bit tricky

Re-naming the global queue, should reset it however (but that's just a dirty way of clearing it)

I'll add a clear control message today once a I get 5 - not to win you ever of course :smile: - but more I should really add that in