# Possible to listen to debug console and wait until no more messages?

**URL:** <https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182>\
**Category:** General\
**Created:** [5 October 2024 15:25 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182 "2024-10-05T15:25:17Z")\
**Posts on this page:** 12\
**Page:** 2

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [6 October 2024 13:31 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/21 "2024-10-06T13:31:02Z")

</div>

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/1/b19ae06fb2bd17f1a21218a5c36bee5a4dd18198.png)

and

```auto
let lastTopic = context.get("lastTopic") ?? msg.setting
// topic unchanged => send to output 1
let messages = [msg, null]
if (msg.setting !== lastTopic) {
    // topic changed => send to output 2
    messages = [null, msg]
}
context.set("lastTopic", msg.setting)
return messages;

```

So where would you place the queue then?  
Here it is after the start\_all function which I changed as per your suggestion to output all 10 possible `msg.setting` payloads in a row.

The problem is that the msg.setting payload does not create multiple messages until after the split nodes which are located towards the end of the sub-flows.

 ![](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/2/b/2bbfb7264cd95c7422bf9ddf3f1fb29db97d9b3b.png)  
[flows.json](https://discourse.nodered.org/uploads/short-url/dxFIMwJGWMaXxuLI7xb3OuvuuUM.json) (287 Bytes)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 13:44 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/22 "2024-10-06T13:44:05Z")

</div>

> [@AleXSR700](#):
>
> The problem is that the msg.setting payload does not create multiple messages until after the split nodes which are located towards the end of the sub-flows.

That does not agree with what you said earlier:

> [@AleXSR700](#):
>
> The "cell range" node you see in the gif can vary, so it can be one cell or 1000 cells. And each cell creates one message with the same topic.

I read that to mean that the cell range node sends one or 1000 messages. I see now that I misunderstood.

What is in the messages at the Out node?

---

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [6 October 2024 14:11 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/23 "2024-10-06T14:11:53Z")

</div>

> [@Colin](#):
>
> That does not agree with what you said earlier:

Sorry, that was poorly phrased by me. The cell range is where I define which rows to read, so depending on the values there, the number of messages will vary. But the messages are not split from each other until more or less the end.

The OUT node see each individual message (so the split has been performed and it sees all x\*y messages). So it sees all messages of the first batch, then all of the following batches. Hence, my earlier idea was to monitor the link-in node and only perform the flush after all the messages of the same `msg.setting` have been sent.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 14:23 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/24 "2024-10-06T14:23:46Z")

</div>

At the Out node is there any indication of what msg.settings was? Perhaps the topics are identifiable.

---

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [6 October 2024 14:54 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/25 "2024-10-06T14:54:18Z")

</div>

Yes.  
HEre is an example:

```auto
{"payload":"SO1 1; SO13 0; SO30 1; SO47 60; SO129 1; TelePeriod 10; SaveData 1; WattRes 0; PowerOnState 3; SwitchMode 0; SwitchMode2 0; Timezone 99; SerialLog 0; WebLog 2; LEDPower 0; Prefix3 tele; CurrentCal 10000; CurrentCal2 10000; PowerCal 1540; PowerCal2 1540; VoltageCal 26000; VoltageCal2 26000; savedata","topic":"cmnd/tasmota_235FAD/Backlog","setting":"settings","filename":"/data/IoT_Overview.xlsm","selectedSheetName":"Tasmota","selectedRange":"U2:U15","parts":{"id":"f564159a8c43d41d","type":"array","count":14,"len":1,"index":3},"_msgid":"cee9a27e2a2ccad9"}

```

or

```auto
{"payload":"Template {\"NAME\":\"Shelly 2.5\",\"GPIO\":[320,0,32,0,224,193,0,0,640,192,608,225,3456,4736],\"FLAG\":0,\"BASE\":18}; Module 0; DeviceName Light Dining Room Ambient; FriendlyName1 Right; FriendlyName2 Left","topic":"cmnd/tasmota_2306AE/Backlog","setting":"template","filename":"/data/IoT_Overview.xlsm","selectedSheetName":"Tasmota","selectedRange":"G2:G15","parts":{"id":"721cd8fc244cbd49","type":"array","count":14,"len":1,"index":4},"_msgid":"dfe0bba7bb35cd72"}

```

So the `msg.setting` is still there.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 15:04 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/26 "2024-10-06T15:04:20Z")

</div>

Put the queue in front of the MQTT node.

I don't think you need individual rate limit nodes on each path. Put one in output 1 of the function instead.

---

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [6 October 2024 15:58 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/27 "2024-10-06T15:58:58Z")

</div>

The individual ones are to not flood the MQTT broker.

> [@Colin](#):
>
> Put the queue in front of the MQTT node.

Including the link-in, flush function etc.?

And keep the link-out in parallel to the the queue then? If debug OUT, MQTT and link-out are behind the queue, there would be no flushing. If I put the link-out in parallel, will I not still have the same problem that the flushing is performed after each message rather than after the batch?

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 16:02 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/28 "2024-10-06T16:02:39Z")

</div>

The whole queuing flow. As originally posted, but in front of the MQTT node.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 16:47 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/29 "2024-10-06T16:47:10Z")

</div>

Like this

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/0/5/05224d843274dc35e8b2202758e77b2813454d66.png)

In fact the 1/sec rate limit has to go inside the group. It doesn't need to be a rate limit inside the group, it can just be a delay as it only sees one at a time anyway.

---

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [6 October 2024 19:19 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/30 "2024-10-06T19:19:01Z")

</div>

@Colin , thank you, you solved it!

I apologize if I made this harder for you than necessary, given that the solution was posted earlier but I had the placement wrong. I would have always placed it at the beginning where the flow starts but placing it at the end is far simpler 🙂

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 October 2024 19:24 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/31 "2024-10-06T19:24:40Z")

</div>

I will leave it as an exercise to use the fact that the Delay node will accept `msg.delay` as the delay to impose on the message being sent in. Using that you can make the function just have one output and use one Delay node, with varying delay.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [20 October 2024 19:25 UTC](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182/32 "2024-10-20T19:25:24Z")

</div>

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

[Previous page](https://discourse.nodered.org/t/possible-to-listen-to-debug-console-and-wait-until-no-more-messages/92182.md?page=1)