[UPDATE] node-red-semaphore-plus 3.1.0

After a discussion under the below thread with @cymplecy

node-red-semaphore-plus 3.1.0 is now available.

New Features

  • You can now reset the lock (which will dispose of all messages)
    To do this, send a property of msg.smp_reset = true to the Release Node


  • The color and shape of the status in the Take Node, now denotes whether or not a message will be queued, where a dot denotes if this Take has queued messages, and a ring denotes that it does not.

    No messages queued here, but will be if one is passed to it
    Screenshot 2023-11-05 at 13.12.20

    No messages queued here, and a message will pass right away
    Screenshot 2023-11-05 at 13.13.13

    Messages queued here, and further message will be queued
    Screenshot 2023-11-05 at 13.14.17


Works very nicely - good scheme :slight_smile:

The release node doesn't quite follow exactly (i.e. no green ring when not going to queue next message)

Of course, I didn't read the instructions and just tried msg.reset = true - which failed of course

Worked fine when I sent correct message but AFAIK all other NR nodes that accept reset msgs just use msg.reset so I'd suggest just using that (as who has time to read instructions/documentation???) :slight_smile:

1 Like

I was in 2 minds about this one :smile:
Given Release/FS Reset won't be queuing anything, I think I customised the status shapes more for Take Nodes as their queue stats can differ from each other

Yup, was also at a cross road, as all nodes passthrough the msg and didn't want to step on other nodes toes so to speak, that also use msg.reset but then I'm portably too kind :sweat_smile:

Presently, I'll keep it as the prefixed smp_ as there are a few other magic properties that can control behaviour like setting the fail-safe timeout in a message.. example: smp_failsafeTimeout

But will keep it in mind.

I think the unwritten rule of the other nodes is that if a msg.reset is received, they clear their internal state and don't output anything so no propagation occurs

So 1st node to get the reset wins :slight_smile:

Thats a very good point <walks around living room, thinking> :smile:

1 Like

@cymplecy I'm going to play devils advocate

msg.reset - Reset state and don't forward the msg to adhere to the 'norm' :smiley:
msg.smp_reset - Reset state only


The Semaphore Release Node can also be used to reset the entire queue state, this will result in all queued message being dropped.

Setting a message property smp_reset = true will achieve this. If you wanted to stop the message containing this command from propagating, use reset instead of smp_reset


I "think" you saying yes to msg.reset into the release node will drop all messages at the take node and reset queue state to non-queued

And nothing will come out of the release node

Which is what I believe is the norm

But you going to keep existing (well since this afternoon anyway) msg.smp_reset to do the same as 1st paragraph but be sent on from the release node

Have I got this right?


I'm about to push a release in a few mins, as I saw a minor issue (since fixed)

1 Like

3.2.0 pushed

New Features

  • Add support for msg.reset to stop message propergation on the Release node


  • Check if a permit is undefined before executing an atomic Release

V3.2.0 working fine for me

1 Like

One (more) thing

If I change the fail-safe

when I press deploy - the status is not updated to reflect new value

This causes me to go back into the node to check that I've set it correctly

Hi @cymplecy,

The LFS status shows what the current LFS is, as it can change during flow activity (or more accurately, when a message has passed through) it’s at that time, the FS is actually applied and ticking down so to speak

I.e once a message is allowed through, it shows what LFS is currently applied

But if I edit a node and set a value and deploy node, does that value not become the current LFS?

The FS that is set on the node, is the default that will be applied, when a message passes through, unless you override it of course with the magic property.

As the FS is global, I think what I am aiming to show is what the current / active LFS (last) is.

What I can show is another value perhaps, what the default is (as set in the node properties) , as well as the current FS that is currently enforced.

This should show what your default value is

In fact I like this idea

DFS - default fail safe (for this take/fs reset node)
LFS - last fail safe applied (what is currently active)

I’m in B’Ham today - so will have a play once home

1 Like

Just throwing this out as it's used in quite a few nodes


where - if you don't specify a node name, it puts some of the node field info into the node name

This would save overloading (even more) the status

1 Like

Ok @cymplecy,

I think I have found the sweet spot.

LQ - Local Queue Size
GQ - Global Queue Size
DFS - Default Fail-Safe (for this Take or Reset node) - i.e what is set on the Node it's self
LAFS - Last Active Fail-Safe

I am not using the node label currently, but may do in the future.
I am now using vertical bars to separate the stats, I think its much clearer when reading.

Screenshot 2023-11-06 at 18.47.34


The node setting label has also been updated

Screenshot 2023-11-06 at 18.49.35

Looks OK :slight_smile:

1 Like

3.3.0 Released.

New Features

  • Both the Take and FS Reset Nodes, now includes a new output property.
    smp_appliedFailsafe This denotes what fail-safe was applied for this msg allowing reference to the current fail-safe time.
    You can, for example, use its value to decide on an updated fail-safe time, for the current message


  • Improvements to the node Status.
  • Improvements to node help, and README