If you use the delay node in rate limit mode per topic it behaves differently and always waits for the time period before sending the last message received.
(though I'm not sure why not just using the extend option in the trigger node is bad ? as you did say that the minute on/off was a minimum and you would hope they don't keep bouncing forever:-)
To clarify, I'm not talking about per topic mode
However, if it behaves as you describe, that sounds like there's a bug in the current behaviour:
rate limiting should allow messages through immediately until the rate limit is reached; then wait until the rate limit condition would no longer occur (f.e. if allowing 5 messages per minute, and one message sent every 10 seconds, it should pass through the first 5 messages, skipping the 6th; sending the 7th again)
Using the proposed "queue last intermediate message", the above would result in the 6th message being sent 60 seconds after the first message.
Because it could receive at least 1 event per minute for a prolonged period of time; possibly hours. I don't want my heater to remain on (or off) for hours (potentially infinitely) after the flow is wanting to turn it off (or on) just because there are too many events.
That nearly works, but because it sends the values out on the time boundaries, then with it set to one message per minute, there will be a delay of up to 1 minute on the first state change, which may not be ideal.
How exactly configured? I don't see how to do it such that it guarantees On and Off times always at least 1 minute.
Yes there will be some initial delay - (the whole point of this mode is that it works across multiple topics so gives time for other topics to arrive - not relevant in this case - and that it releases the most recent information at a constant rate). You could say that it is down sampling the apparently very flappy input.
By using extend it guarantees at LEAST one minute between changes... but indeed as pointed out it has the potential to be stuck forever if the input keeps changing... (which seems like a system flaw to me but... indeed could be unsafe)
I guess my problem is that if I have this proposed mode say and set a rate of 1msg per min - send a message then at 50 secs send another - then at 60 secs that will appear (as it was queued) and now I can't send anything for another 60 secs (without violating the rate setting) - so the next will appear at 120 secs - which would be the last value prior to that... which is what the per topic mode does anyway... once running.
Configured like this, I think it does do what you want, except that the first state change after a stable state for a while will be delayed by up to 1 minute.
Otherwise I think you can use the function I posted.
That is not a bug, it is the defined behaviour of the node. It changes the rate of messages to the desired rate. But there have been a number of discussions over whether there should be an option in the node to enable the behaviour you describe - it just hasn't happened yet.
That doesn't make intuitive sense to me though; why would the per topic mode wait for the rate limit before sending anything? I could configure it to allow 10 messages per minute; how would that work then?
As a solution, I'm assuming this implies msg.topic should be "on" or "off" (or similar)? where in turn implies it'll wait ratelimit-time before sending any message from a different topic? This feels very counterintuitive though, as you don't expect a rate limit to delay (at least not initially)
edit:
(reached reply/quote limit apparently 
)
Can I read this as a (reason for creating this topic) willingness to accept a PR implementing the described behaviour?
It depends, to remove ambiguity, which behaviour you mean.
I am specifically refering to an option for the Delay node in rate limiting mode, where it will apply that limit without delaying any individual message. So if you say 2 messages per minute, then only the first 2 messages will be passed through (whenever they arrive) and then anything else will be dropped (if drop intermediate is selected) until the minute time window is up.
Consider the scenario where I have very limited bandwidth - and can say - only send one message burst per hour. If I have multiple topics of information to send I can either wait for one from anyone who want to send something (always overwriting with the most recent) and send either the whole lot as one , or maybe one topic at a time, each taking turns (and if they don't want/need to send anything they don't and the next gets released instead). Or indeed if I have a short burst of topics (eg a group of sensors wakes up and sends me info) - I can accumulate a better overall block of information and maybe compress it or filter it - before send if I wait to send rather than sending when I receive the first, then others arrive and I have to wait until next timeslot to send the rest (which may mean I have 1 reading and all the others x seconds later).
PS - I have bumped your permissions so you should be able to reply now... (not sure if you have to log out/back in)
As we've been around the discussion a few times in the past, the key point to make is that both modes of operation are entirely valid.
The current behaviour is as it is because that's what was needed for the problem being solved at the time.
The alternative behaviour is just as valid, but it just hasn't had enough interest to get implemented yet. Now would be a great time to add it ahead of the 3.0 release in April.
So one final go...
If I have trigger node set to pass first message wait 60 secs, then pass last received.... followed by a delay node in "normal" rate limit mode - again set for 60 secs with no extend - does that solve Colin's late arrival case and the constant flapping case (albeit you can't be sure which value will get passed and which will be dropped).
Here is an example set for 10 secs so you don't get bored...
[{"id":"0cf9867d9ceadef3","type":"inject","z":"a229cdb61aa18862","name":"send at start","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"1","payloadType":"num","x":135,"y":450,"wires":[["32412b0e9cd8a4e4"]]},{"id":"32412b0e9cd8a4e4","type":"trigger","z":"a229cdb61aa18862","name":"","op1":"","op2":"","op1type":"pay","op2type":"payl","duration":"10","extend":false,"overrideDelay":false,"units":"s","reset":"","bytopic":"all","topic":"topic","outputs":1,"x":385,"y":450,"wires":[["94d60631ae412e47"]]},{"id":"114bcca6d4fcc94c","type":"debug","z":"a229cdb61aa18862","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":785,"y":450,"wires":[]},{"id":"e430f645544f7701","type":"inject","z":"a229cdb61aa18862","name":"send at 9","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"9","topic":"","payload":"0","payloadType":"num","x":125,"y":495,"wires":[["32412b0e9cd8a4e4"]]},{"id":"94d60631ae412e47","type":"delay","z":"a229cdb61aa18862","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"10","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"allowrate":false,"outputs":1,"x":580,"y":450,"wires":[["114bcca6d4fcc94c"]]},{"id":"0c68180c24a16983","type":"inject","z":"a229cdb61aa18862","name":"send at 11","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"11","topic":"","payload":"1","payloadType":"num","x":135,"y":540,"wires":[["32412b0e9cd8a4e4"]]},{"id":"e06c0652109a425d","type":"inject","z":"a229cdb61aa18862","name":"send at 12","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"12","topic":"","payload":"0","payloadType":"num","x":130,"y":585,"wires":[["32412b0e9cd8a4e4"]]}]
I don't think I raised the constant flapping issue, but that doesn't matter. That does seem to do the job. I think I prefer my Function node though, at least it is clear what it does, the trigger followed by the delay may be simple to put together, but it isn't simple to understand exactly how it works. Not for me anyway.
I fully agree! (I was mainly referring to semantics/intuitive meaning; functionality as described sounds great for particular use-cases)
That would be major concern though; the requirement is a guaranteed delivery of the last message (within reasonable time)
I'm feeling the same about this
My take-away from this is that I'll raise a PR for it in the coming weeks 
Thanks for the collaboration!
Looks like logging back in didn't fix it 
Well it would always be the last one received - but if the input was still flapping you couldn't be sure what value that was. IE it would be whatever arrives at or before 59.9 secs...
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy