Feature request: Attach debug node to the IN connector on a node

As in the image, be able to attach a debug node to the input of the mqtt out node. To see what's coming in to that node.

As it stands now, I'd have to insert a dummy node before the mqtt node that would just pass through messages so that I could see what was going through there by attaching to THAT node's output node before it gets to the mqtt node.

image

Is there a reason for not having the input to that node be send to both a debug node as well as the mqtt out node?

mqtt

I can see what you mean, but would like to point out that if there is a signal going into a node's input pin, it has to come from somewhere.

So really all you do is put a debug node on the previous node's output.

It can be a pain if you have, say, five or ten wires to a node and want to debug what it is seeing. Often the easiest way is to insert a do-nothiing node as you can drag all the inputs across to it in one go. It would be nice to be able to do something like that requested here, but I am having difficulty seeing exactly how you would represent it in the editor.

I know how to do that. The point of this request is to implement a method so I don't have to do that.

As in the image(Can you guys see the image in the post?), there are 6 inputs to the mqtt node. To do what you suggest, I would have to make 6 additional connections from all the connected nodes to a debug node. I don't want to have to do that every time this situation arises.

Yes - the shift click to move all the wires to a debug node (or passthrough) in one go is the current best solution.

1 Like

This is what I imagined it would look like

You could always add a MQTT in node listening to the same topic as the MQTT publish node...

mqtt

1 Like

apologies... no offence intended ... but uuurgh...

1 Like

If only the debug node had an output pin so you could drop it in-line. :smiley:

2 Likes

Joking aside, it would solve the msg cloning (to an extent)

We jest, but it's actually quite a good idea (I've seen the v1.0.0 post).
Why not??

1 Like

That would require moving sometimes multiple connections from one node to another multiple times as you add and remove the debug nodes to the project. That can add to the chances of something going wrong. A missed, lost. or miswired connection as you move things around.

Shift-click will drag them all at once so nothing will be dropped

To be honest, I didn't know about the shift-click thing. Which helps, but makes me wonder about how many other features aren't well known. I would have moved each connection one at a time.

This is a genuine problem. There are lots of features that get added and mentioned in release notes/blog posts. But for new users who haven't followed each release of the project, it can be hard to discover them all.

For 1.0 I plan to recreate a whole series of short videos around the various features of the editor, but for now, you may want to read through the Editor Guide, such as the page on wiring.

2 Likes

An inline debug node would be a great addition. :+1: That would increase flow readability a lot, and messages won't have to be cloned. However, where should the disable button be placed?

The topic of proper (inline) debugging and logging - especially in larger projects - is an ongoing issue at work, too.
For now, we are using a custom node with one input and one output. It uses Winston to create proper log files AND has an option to send the log event object to the debug side bar, to provide some kind of inline logging.

1 Like

Is that shared with the community ?

Is that shared with the community ?