I assumed it would work that way, but it's also useful, and no more difficult, to allow a "trigger" message to release messages one at a time. The improved version is shaping up as having three states, closed
, open
, and queueing
, with pretty much the obvious behavior in each.
"and no more difficult" ????
I think it would need a delay loop inside the node, and parameter for rate and ....
I wasn't thinking about rate-limiting inside the node, just one (external) trigger, one message released. (This is how node-red-contrib-simple-queue
works, and anything more complicated would make my head hurt.)
Don't forget, that the delay node already has a rate limit mode that can drip feed messages through. There is also a to do item on the whiteboard to add a flush mode to release all the stored messages. This may well cover some of your simple use cases.
BTW If you could make it like this so we can toggle its state by pressing a button without having extra inject nodes around it (like I've done with my version of inject in my NodeTARTAN fork) that would be great
Runs away very quickly before @dceejay gets here!
Nope. If the node has an input, it should not have a button.
It's still September... (ignoring all suggestions until Oct)
via trwitter _ I saw this has just been published
Interesting idea to have a separate control node I thought
Given me a great idea
But it will have to wait another 3 weeks before I dare mention it
I apologize to anyone who might have hoped for some follow-up to this discussion. Travel has kept me busy for a few weeks. Here is my update.
Done (sort of). The author added a mechanism (as I understand it) that allows the user to define a message property that causes the message to be passed through instead of being queued. Only @tilleul can say whether that solves his problem.
Done. To avoid confusion, I have re-named this as node-red-contrib-simple-gate
and published it to the npm repository. I will post a description shortly.
Done. The result is on GitHub at node-red-contrib-queue-gate. I think the node is usable, but it needs some tweaks before I publish to npm. In particular, the html file is a great display of my ignorance of html/css. Comments and suggestions are welcome.
Absent any comments about node-red-contrib-queue-gate on GitHub, I will shortly publish the node to npm. It turns out that there were a few unexpected design issues related to transitions out of the queueing
state, whether to limit the queue size, and (if so) what to do when the queue is full. The choices I made can be seen in the documentation. I hope you find the queueing feature useful. Comments are welcome.