Delay node, rate limit don't send first message

General
1

Hello,

Been using Node-RED for a week or so now. And have a question about the delay node.

A couple of days ago I started creating a flow where I needed to limit the amount of messages passed on to another node. Found the delay node, and set it to "Rate Limit" and 1 messages per hour. And I do believe when I tested it it worked as I thought it would. That is; the first message was passed through. But all other where dropped until the hour was passed.

To day I am adding other stuff to the flow. But now the delay node pauses the first message. And releases it after the time has passed.

I have tried creating a new flow with only an inject node and a delay node with rate limit, and it behaves the same. It doesn't let the first message through, instead it holds it on delay for the time entered in rate limit, and then releases it. And dropps all messages after the first.

Is this a bug?

Found this old issue on GitHub: https://github.com/node-red/node-red/issues/346 from 2014.

I think I have updated Node-RED after it worked. Only other thing changed is that I have installed node-red-contrib-bigtimer and node-red-contrib-schedex. The later has then been uninstalled and Node-RED restarted afterwards.

I have Node-RED version 0.19.5

2

How are you deploying ? Full deploy ? or just modified flows or nodes ?

3

Full deploy

4

In that case I'm a a loss - as it should always send the first message.
Can you share the relevant part of your flow here in case there is something we can replicate ?

5

Lets hope I'm doing this right... I am a total noob on Node-RED.

Here is my test flow:

[{"id":"978372e8.76582","type":"tab","label":"Testing","disabled":false,"info":""},{"id":"8072285a.f93178","type":"inject","z":"978372e8.76582","name":"","topic":"test","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":280,"y":260,"wires":[["e1e53ea9.53262"]]},{"id":"e1e53ea9.53262","type":"delay","z":"978372e8.76582","name":"","pauseType":"queue","timeout":"20","timeoutUnits":"seconds","rate":"2","nbRateUnits":"30","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":540,"y":280,"wires":[["734b554d.b64b4c"]]},{"id":"ca8ecab6.49bda8","type":"inject","z":"978372e8.76582","name":"","topic":"test2","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":280,"y":340,"wires":[["e1e53ea9.53262"]]},{"id":"734b554d.b64b4c","type":"debug","z":"978372e8.76582","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":850,"y":280,"wires":[]}]

6

Indeed, I could reproduce in my system (windows10, Node-RED V0.20.0 beta3), however, the first msg is not forwarded only when action is configured as "For each msg.topic". It will not happen when the config is "All messages"

7

Same here I see now. If I choose "All messages" instead of "For each msg.topic" then it is working.

8

Aha - actually now I think about it - ... it IS working as designed... (possibly)

The idea being that in per topic mode there are two sub modes...
1) where you send each topic that arrives in turn... I call this a topic based fair queue - each topic gets a turn in the queue - and any more recent data arriving on a topic replaces that topics data - but each topic will be released in turn...
2) all together - at each interval all the topics that have arrived are released with their latest data values only.

I guess in the first case there is an argument that the first data should be what starts the repeating timer, but in the second it should probably wait for several/all the topics to arrive first.. and so the timer is started as soon as the flow is deployed... This has the effect that in both cases the first data won't be output until the first timer tick after deploy.

1 Like
9

But I am 99% certain that when I tried it a couple of days ago, it did pass the first message per topic and dropped the rest, until the time has passed (I do have the "drop intermediate messages") checked, or it is not possible to unselect it).

And if I read the issue on GitHub from 2014 that I referred to in my first post, it seems that it should work like I think it worked the first time I tested it.

In the flow I am trying to make I am monitoring a node that sends messages every 5 minutes, and if it is above a certain value I want to send a notification. But I only want to send those messages every 6 hours. And I found on the net that the delay node had this function.

But if it is like you say, that the delay node in "Rate Limit" mode works the same way as in "Delay each message" mode, I will have to look for another solution.

10

The code hasn't changed its operation. In per topic modes the timer starts on deploy... so say it was set for 30 seconds - if the first message actually turns up at 29 seconds then it will come out 1 second later when the timer ticks. In all topics mode then indeed it works as you suggest as the timer doesn't start until the first message arrives.

The delay node only delays a message nothing more or less so if you send one every 5 mins and delay for 6 hours you will a message at 6, 6:05, 6:10 etc...

The Rate limit allows you to drop all the intermediate messages - In all topics mode - you will get one at whenever the first message arrives (t) - then the next at 6:00 + t
In per topic modes you will either get
a) topic1 at 6:00 (where the value is the most recent to arrive on topic1 before 6:00, the topic2 at 12:00, topic3 at 18:00
or b) topic1, topic2, topic3 - most recent values of each - at 6:00, then topic1, topic2, topic3 latest values at 12:00 etc

so they are not the same as delay

2 Likes
11

Thank you for the explanation. Now I have a better understanding of what is going on. And I now know what has changed since my first tests that made me think something was not right.

At first I had only one node sending messages through the delay node, and most probably had it set to "All messages". Now I have several nodes connected to the delay node, all sending with different topics. And there for I must have changed it to "For each msg.topic" believing it would behave the same.

So I guess the solution for my flow, is to have separate delay nodes to each node sending messages I want to "Rate Limit".

1 Like