Ignore same message within 5 seconds

[cymplecy]

I'm trying to come up with a method of ignoring short term duplicate messages

But this little idea doesn't quite seem to work in the way I want it to
i.e use RBE to block repeats but reset it 5 secs after a message comes thru

[{"id":"5c4fbe47.40f5","type":"inject","z":"e1dfe9ca.bed568","name":"","topic":"","payload":"test","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":386,"y":462,"wires":[["3b5085e4.3a795a"]]},{"id":"3b5085e4.3a795a","type":"rbe","z":"e1dfe9ca.bed568","name":"","func":"rbe","gap":"","start":"","inout":"out","property":"payload","x":578,"y":462,"wires":[["c601b096.43ef6","5bfec0f9.8927c"]]},{"id":"c601b096.43ef6","type":"trigger","z":"e1dfe9ca.bed568","op1":"","op2":"true","op1type":"pay","op2type":"bool","duration":"5","extend":false,"units":"s","reset":"","bytopic":"all","name":"","x":742,"y":462,"wires":[["ff2d4a2d.9208c8"]]},{"id":"5bfec0f9.8927c","type":"debug","z":"e1dfe9ca.bed568","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":814,"y":396,"wires":[]},{"id":"ff2d4a2d.9208c8","type":"change","z":"e1dfe9ca.bed568","name":"","rules":[{"t":"delete","p":"payload","pt":"msg"},{"t":"set","p":"reset","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":894,"y":462,"wires":[["3b5085e4.3a795a"]]}]

If I press inject 3 times quickly - 1st msg goes thru and others are ignored
But at end of trigger timeout - another one of the messages appears

[cymplecy]

PS Although I'd like to know why my idea isn't working properly - all other suggestions welcomed as to how to the job in a different way

[edit]

I've just realised that I'm re-inventing the delay node rate limiting and discarding intermediate messages option aren't I #LOL

[Steve-Mcl]

@cymplecy

I've just realised that I'm re-inventing the delay node rate limiting

Yep

[Trying_to_learn]

I know you have found a solution, but for the sake of learning.....

From my recent post about "message repeat speeds" I was pointed to this:

Could this be interesting?

[dceejay]

That was a solution created 6 years ago (before that rate limit capability was built into the delay node)

[Trying_to_learn]

Ooops.

Sorry. I was just sharing something I thought could be useful.

[dceejay]

No worries, it was useful back then, and is interesting from a historical perspective

[cymplecy]

But still interested if anyone can explain why my flow doesn't do the same job properly

[Trying_to_learn]

I'll look at the flow soon, but before I do I was just wanting to check I am up to speed with what it is you want to do / have the flow do / see.

I think I can see the problem!

The trigger node.

It is set so:

[{"id":"f19fc18.be60d4","type":"trigger","z":"b4f1ccd4.5e8d1","op1":"","op2":"true","op1type":"pay","op2type":"str","duration":"5","extend":false,"units":"s","reset":"","bytopic":"all","name":"","x":566,"y":1260,"wires":[["8649549c.f4d508","1f7fbfd4.050dd8"]]}]

So, it sends the original message, waits 5 seconds then sends a reset message.

Try it like this:

[{"id":"f19fc18.be60d4","type":"trigger","z":"b4f1ccd4.5e8d1","op1":"","op2":"true","op1type":"nul","op2type":"str","duration":"5","extend":false,"units":"s","reset":"","bytopic":"all","name":"","x":566,"y":1260,"wires":[["8649549c.f4d508","1f7fbfd4.050dd8"]]}]

I can't promise it is the solution.

Alas even this machine's Node-Red is slow (but 200+ tabs open, you have to expect things to slow down) but the tabs for (with) Node-Red are really loading the processor.
So there is another problem.

But sorry, I am getting off topic.

But I think what I did with the trigger node helps with the problem.

[zenofmud]

@cymplecy Simon here is my take on your flow

When you press the inject and msg is sent with a payload of 'test'

• the msg enters the rbe node which stores the payload and sends the msg on
• since there was no previous msg (the payload has changed)
• the msg goes to debug and shows up
• the msg also goes to the trigger node which sends the msg on (first time)
• the msg goes to the change node where the payload is removed from msg and msg.reset is set to true
• the msg is sent back to the rbe node
• Since msg.reset is true, it clears the stored msg.payload.
• the msg is sent on to the debug (shows up in debug list) and to the trigger node

Here is where the gotcha comes in. The msg now has msg.reset set to true, so when it gets to the trigger node

reset

If a message is received with this property, any timeout or repeat currently in progress will be cleared and no message triggered.

and everything stops.

If you add a change node (set to delete msg.reset) between the rbe and trigger node I think it will work the way you want.

[cymplecy]

@zenofmud

If you add a change node (set to delete msg.reset) between the rbe and trigger node I think it will work the way you want.

That didn't make any difference

[zenofmud]

Yes it does, but the second msg sent from the trigger ends up with reset = true so it never gets thru the rbe again.

Here is your flow with the change and an extra debug.

[{"id":"c0e62e53.8a175","type":"inject","z":"a48607a.1581178","name":"","topic":"","payload":"test","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":110,"y":180,"wires":[["951b2c1.e7e0ad"]]},{"id":"951b2c1.e7e0ad","type":"rbe","z":"a48607a.1581178","name":"","func":"rbe","gap":"","start":"","inout":"out","property":"payload","x":302,"y":180,"wires":[["7a33cf5f.3a5048","1c9d9ff4.4eba18"]]},{"id":"23f644f4.741c4c","type":"trigger","z":"a48607a.1581178","op1":"","op2":"true","op1type":"pay","op2type":"bool","duration":"5","extend":false,"units":"s","reset":"","bytopic":"all","name":"","x":280,"y":340,"wires":[["c6f210a8.bdc7a"]]},{"id":"7a33cf5f.3a5048","type":"debug","z":"a48607a.1581178","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":538,"y":114,"wires":[]},{"id":"c6f210a8.bdc7a","type":"change","z":"a48607a.1581178","name":"","rules":[{"t":"delete","p":"payload","pt":"msg"},{"t":"set","p":"reset","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":460,"y":340,"wires":[["951b2c1.e7e0ad","7f66138.9cd916c"]]},{"id":"1c9d9ff4.4eba18","type":"change","z":"a48607a.1581178","name":"","rules":[{"t":"delete","p":"reset","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":290,"y":280,"wires":[["23f644f4.741c4c"]]},{"id":"7f66138.9cd916c","type":"debug","z":"a48607a.1581178","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":670,"y":340,"wires":[]}]```

[cymplecy]

Your flow doesn't work for me - you seem to have changed the way the trigger node is configured
[edit] ignore the bit about trigger node change [/edit]

[zenofmud]

Only thing I did was to add the change node and debug node. Here is what it looks like after the initial click of the inject node:

NOTE: I moved the nodes to make it easier to take the screen shot

You can see the blue dot under the trigger node. After 5 seconds you see the other msg and the blue dot is off:

What versions of NR, node.js and what platform? I tried it on a Pi and on my mac and get the same results (both using NR v1.0.4)

[cymplecy]

I'm just have a mare of a day here

Just ignore me

[cymplecy]

I've altered my trigger node to do WHAT I THOUGHT I'D TOLD IT TO DO IN THE FIRST PLACE!!!!!!

Did I mention that I was having a mare!

This is what I thought i'd set it to and now it works perfectly of course

Thanks for sticking with me Paul and forcing me to find out what I'd done wrong

[Trying_to_learn]

Wasn't that me who mentioned setting the trigger node to send nothing?

I'll chirp in and give you my rundown on what was happening:
(It was late and while I was sleeping I saw the problem.
I didn't think it was worth getting up and posting then.)

Overview:

• There will be 3 messages coming in.

The first message comes in.
The RBE allows it to pass.
It is sent to the debug node and the trigger node.
The trigger node on-sends the original message to change node, and starts a 5 second count down.
In the mean time: messages 2 and 3 arrive.
They are filtered by the RBE node.
(Back to the other part)
If it is more than 5 seconds for the messages to arrive.......
{
The trigger will have sent a reset message to reset the RBE node.
The second (or third) message arrives. (Though probably third in your case)
The RBE node will allow it to pass because it has been reset.
}
or
Going back to the second message message:
The trigger node has just sent the reset command and the RBE node will allow messages to pass.
The second message arrives - the RBE has been reset from the message sent from the trigger node.
The second message is passed.
The trigger node again sends the original message and waits 5 seconds to send the reset command.
And so the problem can repeat for the third message.