I'm working with Node-RED in a containerised cloud environment where all
stdout/stderr is collected by Fluent Bit and shipped to Elasticsearch/Kibana.
This means the debug node's "Also send to console" option is essential for us —
it's the only way debug output reaches our centralised logging.
The problem is that every time a developer drags a new debug node onto the canvas,
"Also send to console" defaults to OFF. They have to remember to tick it every time.
In practice, they forget, deploy, and then wonder why nothing shows up in Kibana.
I'd love to see a way to configure debug node defaults via settings.js, something like:
debugNodeDefaults: {
console: true
}
This would only affect newly created debug nodes in the editor — existing flows would
keep their saved values, so there are no breaking changes.
I found a related discussion here:
That thread touched on remembering sidebar filter settings, and @zenofmud suggested
a settings.js option for "display complete msg" as default. My request is similar but
focused on the "console" property.
I understand this touches a broader design question — how to allow operators to set
defaults for any node property. Happy to help shape that if there's interest.
For now we work around it by patching 21-debug.html during our Docker build, which
works but is fragile across upgrades.
I think your suggestion potentially has merit and I've taken the liberty of moving it to the Feature Requests category as I think that's where it needs to be in order to get the right eyes on it.
I would vote for this feature on the debug node. For me it is the Complete Message output that I would like to make the default.
The concept of being able to set defaults on any node type also sounds appealing, if it can be implemented in a way that is compatible with existing 3rd party nodes.
I agree with the basic sentiment of this. It would be useful to override some node property defaults for certain situations. I think there are several next level questions it throws up.
Should it be per user (IE held in browser session) - or per server instance (held in settings.js) - I tend to agree with settings.js as it seems like it would be something you want to set for a "house style" way of working.
If implemented should it try to be generic - or node specific ? - I would prefer generic - but that would require some discipline re naming of properties - indeed it may require exact matching to the type and internal property names (which are visible via the node info tab). But in either case I suspect would require the node to "opt-in" - ie be re-written/patched - to expose the relevant properties to be overridden and then that would need to be documented somehow/somewhere.
Not saying it can't be done - and yes I can see it's usefulness - but I wouldn't want to just fix it for the debug node.
It's doable today. Use the alias node solution that I describe. It works but it's fragile because it's not standard and second each node is slightly different to modify. I've aliased five nodes and each was different on how to do it - if that were to be standardised, then it would be much simpler.
These are browser side solution, the server side only sees the original nodes with the altered settings. Alias nodes only exist in the editor but need to be installed on each reload of the browser - a downside.
IMHO a browser only solution has the advantage that nothing needs doing on the server, it just works out of the box. So folks don't have to use aliases or altered nodes. Have a server side solution might also make share flows more difficult since not only need the right node packages be install but also the correct settings. That of course depends on how these these settings are implemented but something to be aware of.
But hey, bake your own cake in space, I've got a solution that works for me.
Hi yes - sorry I should have said I had seen your alias concept. Must admit I didn't quite get whether it overrode the existing node - or added another aliased one that had the new defaults. IE does it fill up the palette with yet more nodes ?
To my limited brain I think I would prefer a solution (space)baked into the core, and into any nodes that wanted to. But yes a lot depends on the implementation and if it can be backwards compatible flow-wise etc. All to be debated, thought about and implemented.
I'm liking the ideas there Dave. Sounds like a really good extension to Node-RED. And I agree, it should be in settings.js ideally.
Nodes can already make use of custom properties in settings.js so perhaps using the node-name as a key? Or even better, the package (npm) name with the node-names at the next level then the settings names at the 3rd level. This should then be fairly easy to hook into the node runtime in a fairly standard way? In fact, does it need ANY core changes at all? Since nodes can already do this with RED.settings. Perhaps all it needs is a common set of conventions?
It does do that, the idea being that both the original node and the new alias node are available to the user. The alias node, when dragged into the workspace, is replaced with the original but using the new ("alias") settings. This means that alias nodes don't make it to the server, only the original node with the new settings. This then also allows copy & paste solution of having default values.
This concept only works for attributes configurable in the editor, so any settings.js settings can not be overridden in this way.
Concerning the filling up of the palette with nodes - well then do less with Node-RED and then you'll need less nodes I think this issue is a more general issue. How else should new nodes be represented in NR? If this is an issue (i.e. the over population of the palette), then alias nodes are the smallest part of the problem, perhaps the 5500+ node packages are more the problem!
Yes - but no... the server side can see all the settings - but only some are passed through to the client/editor side - which is where the defaults for a new node are generally set when you drag on a node - so need to be overridden there... I think... happy to be wrong..
Was thinking like a separate key area in settings.js
eg something like
I install them and then collapse their category in the palette and after that only use the Cmd-Mouse click menu to select them from there. (In the screencast, I add a switch node that stops after the first match, a debug node that sends the complete msg to the debug panel and a debug node that only has a message counter.)
So I don't really care about the palette, I rarely drag & drop nodes anymore....
So the old or original default values are replaced? So in the case of my switch node that stops after the first match, if I ever wanted to the old behaviour, I would never to reset it in the workspace?
So all my debug nodes would go to the console? Unless I deactivate it in the debug node?
I'd prefer to have a alias node so that I would have a choice and not a "one size fits all" solution.
Haven't thought about the switch - but debug - yes - the node will now have the console option ticked when dragged on - you can then toggle it off - likewise the view complete msg is set as default - and you have to manually change it to be msg.payload...
I'm not sure what you expect default to mean then. I would expect to use the default most of the time and to change it when needed.... If you indeed use two modes about 50/50 then yes maybe two nodes, one for each, would suit better. But hey
Just to make the point, I've updated the alias nodes flow and added an alias for the debug node that debugs to the console and the panel - so the node required in this case.
so ideally they don't want the "old default" option... so an alias wouldn't suit them.
(and I'm not trying to stop your alias's working - in theory we could have changed defaults and/or alias's on top if there was a reason to - eg a 3rd party node author declined to implement.
Sure, I guess they can wait another six months before a solution is actually implemented. Not my problem. Just saying that they can continue use the current situation or have two nodes (as debug nodes) and one is what they want and the other is the original - just in case there is a case where they don't want to debug to console - "no will neveeeeeeeer haaaaapppppeeeeeennnnnn ever ... promise".
I think this issue is a more general issue. How else should new nodes be represented in NR? If this is an issue (i.e. the over population of the palette), then alias nodes are the smallest part of the problem, perhaps the 5500+ node packages are more the problem!
