Yes - the shift click to move all the wires to a debug node (or passthrough) in one go is the current best solution.
You could always add a MQTT in node listening to the same topic as the MQTT publish node...
apologies... no offence intended ... but uuurgh...
If only the debug node had an output pin so you could drop it in-line.
Joking aside, it would solve the msg cloning (to an extent)
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.
An inline debug node would be a great addition. 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.
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.
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"
]
]
}
]
What a brilliantly simple idea
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.