Stuck with message properties. `q-gate` node

[Trying_to_learn]

This bit of code is working.

[{"id":"3c80536c.fdeb74","type":"q-gate","z":"f9420cde.5b8bb8","name":"","controlTopic":"CONTROL","defaultState":"queueing","openCmd":"Go","closeCmd":"Stop","toggleCmd":"toggle","queueCmd":"queue","defaultCmd":"default","triggerCmd":"trigger","flushCmd":"flush","resetCmd":"reset","peekCmd":"","dropCmd":"","statusCmd":"","maxQueueLength":"50","keepNewest":true,"qToggle":false,"persist":false,"x":1080,"y":1690,"wires":[["6c96a140.9725d8"]]},{"id":"6c96a140.9725d8","type":"switch","z":"f9420cde.5b8bb8","name":"Last","property":"_queueCount","propertyType":"msg","rules":[{"t":"gt","v":"0","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1210,"y":1690,"wires":[["e6d3baca.8b0b38"],["160988d8.e2947f"]]},{"id":"160988d8.e2947f","type":"template","z":"f9420cde.5b8bb8","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"{{payload}} (Last)","output":"str","x":1220,"y":1730,"wires":[["e6d3baca.8b0b38"]]}]

My take on it is that the gate queues messages.
They are spat out on command and there is a property msg._queueCount
When that gets to 0 the message is formatted to have the word LAST in it so I know I have read all the messages.

That's the idea.

Version 1.5.2.
(Both machines)

I want to do that on another machine.
I'm building a test bit for now.

I'm not seeing that property like with the other one.

Why not?

[Colin]

You have not posted a full working flow for us to try.

Make sure that flow works on one system and not the other.

Personally if I want to know when the queue is empty I use the status rather than an undocumented feature. Also it is always a good idea to make sure you are using the latest version of nodes before querying behaviour in case the issue is already fixed.

[Trying_to_learn]

Correct: I haven't posted a full working flow.
I posted the part that does that which I am asking.

Here is a slightly bigger part which has all the nodes needed to see it.

There are GUI nodes, so be prepared for them.

[{"id":"e6d3baca.8b0b38","type":"ui_text","z":"f9420cde.5b8bb8","group":"e48399e0.8415c","order":3,"width":"10","height":"4","name":"Flow error","label":"","format":"{{msg.payload}}","layout":"row-spread","x":1604,"y":1690,"wires":[]},{"id":"6c96a140.9725d8","type":"switch","z":"f9420cde.5b8bb8","name":"Last","property":"_queueCount","propertyType":"msg","rules":[{"t":"gt","v":"0","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1210,"y":1690,"wires":[["e6d3baca.8b0b38"],["160988d8.e2947f"]]},{"id":"160988d8.e2947f","type":"template","z":"f9420cde.5b8bb8","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"{{payload}} (Last)","output":"str","x":1220,"y":1730,"wires":[["e6d3baca.8b0b38"]]},{"id":"e72b1b4b.639ec8","type":"inject","z":"f9420cde.5b8bb8","name":"Next","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"CONTROL","payload":"trigger","payloadType":"str","x":1080,"y":1610,"wires":[["9dde0c69.114468"]],"icon":"node-red/trigger.svg"},{"id":"bdb9721b.575c4","type":"inject","z":"f9420cde.5b8bb8","name":"Wipe","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":" ","payloadType":"str","x":1080,"y":1650,"wires":[["3148dfa8.a094e"]],"icon":"font-awesome/fa-eject"},{"id":"3c80536c.fdeb74","type":"q-gate","z":"f9420cde.5b8bb8","name":"","controlTopic":"CONTROL","defaultState":"queueing","openCmd":"Go","closeCmd":"Stop","toggleCmd":"toggle","queueCmd":"queue","defaultCmd":"default","triggerCmd":"trigger","flushCmd":"flush","resetCmd":"reset","peekCmd":"","dropCmd":"","statusCmd":"","maxQueueLength":"50","keepNewest":true,"qToggle":false,"persist":false,"x":1080,"y":1690,"wires":[["6c96a140.9725d8"]]},{"id":"9dde0c69.114468","type":"ui_button","z":"f9420cde.5b8bb8","name":"Next ","group":"e48399e0.8415c","order":4,"width":"2","height":"1","passthru":true,"label":"Next","tooltip":"","color":"","bgcolor":"lime","icon":"","payload":"trigger","payloadType":"str","topic":"CONTROL","topicType":"str","x":1210,"y":1610,"wires":[["3c80536c.fdeb74"]]},{"id":"3148dfa8.a094e","type":"ui_button","z":"f9420cde.5b8bb8","name":"","group":"e48399e0.8415c","order":5,"width":"2","height":"1","passthru":true,"label":"Wipe","tooltip":"","color":"","bgcolor":"red","icon":"","payload":"  ","payloadType":"str","topic":"","topicType":"str","x":1210,"y":1650,"wires":[["e6d3baca.8b0b38"]]},{"id":"e48399e0.8415c","type":"ui_group","name":"Flow error display","tab":"48f5e285.67a4c4","order":1,"disp":true,"width":"11","collapse":false},{"id":"48f5e285.67a4c4","type":"ui_tab","name":"ALARMS","icon":"mi-notification_important","order":5,"disabled":false,"hidden":false}]

Just send any message into the q-gate then press the Next button/node.

There is still a lot of code which I haven't posted. It isn't important to get the result.
But here is a full go to woe of things happening.

All things are good:

An error is detected. I see who has it and am prompted to look at it.
I press the NEXT button and see this.

As there is only 1 error, you can clearly see the (Last) message appended to the message.

[Trying_to_learn]

@Colin

Also it is always a good idea to make sure you are using the latest version of nodes before querying behaviour in case the issue is already fixed.

Both machines have the same version, so all things being equal if it works on one: it should work on the other.

[Trying_to_learn]

Ok, update:

Now it isn't working. There is now no longer a msg._queueCount

Sorry. I'll have to attack this from a different perspective.

[drmibell]

Andrew, I am the principal author of the q-gate node, and @Colin is a contributor. We both make an effort to assure that the code is as bug-free as possible and that it performs as users expect. I would not like to see your experience discourage others from using the node or give the impression that there are issues with it that we have not tried to find and correct.

Since msg._queueCount is not a property we use or define in q-gate, I have to assume that you have created it elsewhere in your flow. If you continue to believe that there is a difficulty in this node that needs attention, please give more specifics here or raise an issue on GitHub.

[Trying_to_learn]

There must be something wrong with how I am asking.

I'm not attacking anyone or saying it (the node/code) is faulty.

I tried searching for where I was told to use msg_queueCount but can't find it.
I am 99% certain I asked a while back and was pointed in that direction.

It is too technical for me to have contrived.

Now - of course (and typically) it isn't working/doesn't exist in the message.

I have seen my previous posts when I was asking about something and you can clearly see that property exists/existed.

Not to worry. I pfaffed around with a couple of other nodes and got what that was doing working and so have sort of moved on.

Not to lay blame or say "it wasn't me" could you have a quick search (if not for my benefit) and see if you can find where I was told that property (msg_queueCount) exists.

The thread did have q-gate in it. Be it with out without the -.

I may try again myself but when I try, I just go around and around in circles.

Ok, it is more than a year ago, but here is a screen shot which has that property existing.

I'm not going to further edit the screen shot, but look on the right at the bottom of the big red circle. Bottom line.
And it is straight out of the q-gate node.

[drmibell]

@Trying_to_learn

I'm not attacking anyone or saying it (the node/code) is faulty.

I hope I didn't sound defensive. When you mention the node in the subject of your post and say "Now it isn't working," one has to suspect that you are not happy with it.

A little detective work convinces me that the screenshot above (2020-05-13 10-24-13) does not show the q-gate node but rather node-red-contrib-simple-message-queue. This node uses message properties ttl, _queuetimestamp, and _queueCount, as seen in the screenshot. I hope this information helps you troubleshoot your flows.

[Trying_to_learn]

Ah!

Thanks very much.

I know I should have done more research before it got to this...

The Now it isn't working was more one of confusion than blame assignation.
I didn't get why it worked and now didn't.

You are right. At some stage I had the competition's node. (ie: the one you mentioned now)
For reasons I can't remember just now there was a time when I had it and your plane gate node. Then I saw you had the q-gate node and rather than having the other one I migrated them all to your node.

And if it was the previous node that did it and not yours: it would explain a lot.

I am sincerely sorry I didn't work that out myself.

(But it would be nice if that was an option in your node)

Yes, ITMT I have worked out a work around - as suggested by @Colin - I think. The status node. But that needs 2 nodes and a bit of message crunching to get the result.

Again: Thanks.

[drmibell]

Glad that's sorted.

@Trying_to_learn

it would be nice if that was an option in your node

I assume you are referring to the _queueCount property. There are two reasons I have not gone in that direction, one "philosophical" and one practical. I have made it a principle in both the gate and q-gate nodes not to modify the user's messages in any way as they pass through. Control and reporting of the state of the node is handled entirely "out-of-band." This prevents the user from relying on any particular modifications of the messages that might be affected by bugs in the code or misinterpretation downstream in the flow. Your issue seems to be a subtle case of that kind. From a practical point of view, a message property indicating the queue size when the message was sent seems less useful than a status showing the length now. The possibility of dropping messages from the queue without sending them or having new messages arrive before the dequeued message can be processed also complicates matters. In short, I think your "work-around" is actually the right answer.

[Trying_to_learn]

Fair enough.

And I respect that. I'll have to work out my work around with the other nodes.

[Trying_to_learn]

(Sorry......)

Just Spit balling......

How about a second output that gives telemetry data like the queue count?

[dceejay]

That is what the status is for.

[Trying_to_learn]

Yes, but that is not at a level where the information can be used at/in the flow.

[dceejay]

which is what the status node is for

[Colin]

Presumably you have worked out that you can use something like Number(split(":")[1]) to get the count.

[drmibell]

@Trying_to_learn

How about a second output that gives telemetry data like the queue count?

That would be possible, but there is already work underway to use an optional second output for other purposes. If you can get by with only the queueing mode of the gate, you might try node-red-contrib-multiple-queue. It has an optional second output that provides a detailed status object in response to a status command.

[Trying_to_learn]

Yes, ok.

@Colin has better way than I was going. Though that was what I was doing, mine was the longer way to get it. Colin's way is better/quicker/neater.

Ok. No problems. I didn't want to have both nodes installed only because it confuses me. (See this thread)

Keeping only one type of node is neater.