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

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

2 Likes

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 ?

No, unfortunately not yet. As I developed it mainly during work hours, I need to get permission from the superiors.

Our developer team is rather small, so "officially" maintaining open source projects is a matter of resources. But personally, I would really like to share some of the stuff and give it back to the community. My plan is to open-source it as a personal project once that is resolved. :slightly_smiling_face:

4 Likes

Well, after reading this thread and checking out some other pages. I came up with a solution. A simple passthrough subflow-node thingy. It is simply a subflow with one input and one output and passes through any msg object as is and outputs the object to the debug tab.

Here's my solution. Modify as you wish. This'll kinda do the trick for me, I guess.

[
    {
        "id": "c2bcad1.0c3e4d",
        "type": "subflow",
        "name": "Inline Debug",
        "info": "",
        "category": "",
        "in": [
            {
                "x": 160,
                "y": 180,
                "wires": [
                    {
                        "id": "bd6896fe.f4e21"
                    }
                ]
            }
        ],
        "out": [
            {
                "x": 480,
                "y": 180,
                "wires": [
                    {
                        "id": "bd6896fe.f4e21",
                        "port": 0
                    }
                ]
            }
        ],
        "env": [],
        "icon": "node-red/debug.png"
    },
    {
        "id": "bd6896fe.f4e21",
        "type": "function",
        "z": "c2bcad1.0c3e4d",
        "name": "",
        "func": "node.warn(msg);\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "x": 310,
        "y": 180,
        "wires": [
            []
        ]
    },
    {
        "id": "b87aeaf7.af81f",
        "type": "subflow:c2bcad1.0c3e4d",
        "z": "c5627bb2.08bf88",
        "name": "",
        "x": 590,
        "y": 240,
        "wires": [
            [
                "253e234.f55eb5c"
            ]
        ]
    }
]
4 Likes

What a brilliantly simple idea :slight_smile:

I had a quick look at it.

Just one thing though:
How do you turn it off so you don't see the output?

Why:
Well, I get that you need debug nodes when making flows.
But once they are working, getting outputs is introducing overheads which may not be wanted/needed.
Deleting the nodes could be painful.

My way around the problem is using the FAN node.
(yeah, an empty function node could work too. But the advantage with the fan node is that it is green, and you know it isn't simply an empty function node.)

So my flows (where needed) look something like this:

I added some stuff. to enable and disable the output and change the output from the msg object to just the payload. Now I'm having a whole new problem.

And the complete(ish) solution.

Be gentle.

1 Like