Q-gate - 4 messages in, 3 messages out

General
1

Good morning,

I have been playing around with the Gate Nodes (Simple Gate and Q-Gate), trying to understand the interaction between the nodes from a queuing flow that @Colin suggested in this Post.

In doing this I have broken the node down to it's very basics and have seemingly found that if there is a single message in q-gate, it doesn't seem to get through. Add a message and the new message will be passed through, but the first message waiting in the queue seems to get lost. Changing 'Max queue' makes no difference.

Can't understand why this should be, but I would like to know if I am missing something here.

TIA,
Colin J

Minimal flow...

[{"id":"a46a37a8.38f5d8","type":"inject","z":"9dd4ed29.e99178","name":"Payload","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":140,"y":80,"wires":[["8b5f68e5.69c498"]]},{"id":"8b5f68e5.69c498","type":"q-gate","z":"9dd4ed29.e99178","name":"q-gate","controlTopic":"control","defaultState":"queueing","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","queueCmd":"queue","defaultCmd":"default","triggerCmd":"trigger","flushCmd":"flush","resetCmd":"reset","peekCmd":"peek","dropCmd":"drop","statusCmd":"status","maxQueueLength":"","keepNewest":false,"qToggle":false,"persist":true,"x":470,"y":80,"wires":[["4c97c82b.2c6cc"]]},{"id":"48756100.807508","type":"inject","z":"9dd4ed29.e99178","name":"Next!","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":130,"y":140,"wires":[["9cabe358.3e8938"]]},{"id":"9cabe358.3e8938","type":"function","z":"9dd4ed29.e99178","name":"get next","func":"node.send({topic: \"control\", payload: \"drop\"})\nmsg.topic = \"control\"\nmsg.payload = \"peek\"\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":300,"y":140,"wires":[["8b5f68e5.69c498"]]},{"id":"4c97c82b.2c6cc","type":"debug","z":"9dd4ed29.e99178","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":610,"y":80,"wires":[]}]

EDIT:
25 Nov 09:33:33 - [info] Node-RED version: v1.2.5
25 Nov 09:33:33 - [info] Node.js version: v12.18.4
25 Nov 09:33:33 - [info] Linux 5.4.51-v7+ arm LE
25 Nov 09:33:35 - [info] Loading palette nodes
25 Nov 09:33:49 - [info] Dashboard version 2.24.0 started at /ui

All nodes up to date

RPi 3B+ Buster

2

I haven't looked at your flow yet, but I have made some improvements to the original and put it on the flows site: https://flows.nodered.org/flow/05e6d61f14ef6af763ec4cfd1049ab61

1 Like
3

In your get next function node you are sending a drop control message which drops the oldest message. That is the right thing to do after peeking it if you want to discard it, but if you queue a message and then immediately drop it then it just gets discarded.

4

Besides, dequeue doesn't seem to work?? It is described at Github as a supported action

image
image3652Ă—1418 232 KB

node.send({topic: "control", payload: "dequeue"})

gives "Invalid command"

1 Like
5

I believe that is an error on the qithub page, it should be trigger not dequeue.

1 Like
6

Thank you for that, both of you!

I just wanted to understand what was going on as the original flow doesn't do this. Having spent several hours comparing the original with the copy, I was at my wits end! None so blind as those can't see!!

I will look at the (simplified) simplified flow and see how to incorporate that. But, first I need to understand the basic gate nodes, so I will concentrate on that before progressing further.

7

Seems I made things too simple! Added the Retry from the original flow and it now works. Getting there on the understanding of what is happening!!

8

It is quite complex, there are a lot of different conditions to cover. However I am quite pleased with the version in the flows site, it cleanly separates the bits that don't need changing for a different application (apart from a couple of configuration choices) from the bit that does vary, where the requirement is just to provide an OK or FAIL result to tell the rest of it what to do noxt.

image
image600Ă—655 69.8 KB

9

The new flow is now running on my system, replacing the earlier version, uploading data to the InfluxDB, like the layout and simply adapted. I see what you have done, excellent!

Since adding the queue, the RPi3 has behaved itself and is not throwing up errors when loading a lot of data to InfluxDB (until I reduced the retry time down below 5 seconds earlier!). Back up at 10 seconds and all looks good again.

Thank you for the flow, it makes my 'work' easier.

Just running the minimal flow on my Ubuntu Laptop to make sure I get what is going on under 'the bonnet'. I am a 'brute force' kind of programmer, know what I want, have no proper skill, but play until I get it to do what I want (which may mean tens of iterations to get a small bit working!! - Please don't tell anyone!!)

10

No, but I am thinking about how to clarify the documentation. Every control message (command) has three attributes: a name, a default value (payload), and an action it produces. The message you are discussing is named triggerCmd. Its default value is "trigger", and the action it causes is dequeue. I can see how even someone very familiar with the node could become confused. In this case, the error is in how the node was configured in the edit dialog. If the triggerCmd were defined as "dequeue", the node would work as @krambriw expects.

BTW, when the node was being developed, I was reminded that several existing nodes and flows for queueing messages use a command called trigger to release the next message, and that the term "dequeue" might be too technical for the average user. It seems that no good deed goes unpunished.

2 Likes
11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.