Could it be possible if you could disable some nodes on the current flow, that’s because some times (at least for me) i need to disable things, something like commenting a section.
Thanks
Andrés
You can disable a whole tab (double click on tab name and turn off enabled).
If you want to disable some nodes you just have to unwire that group of nodes.
This was a conscious design choice in that most of the time if you could disable a node (and pass through the input to the output) then the format would be unlikely to be suitable for the next node.
@knolleary @dceejay should we have another category for feature requests? What belongs in the “Development” category?
1 Like
unwiring does the trick, but not for every case, for example, with the dashboard (but i think that this is the wrong place to request this).
Disabling something in the dashboard is completely different to disabling something in the middle of a flow.
(and yes - we have now added the Feature Requests category for these sorts of discussions 
yes, the "request" went in that way, disabling the dashboard nodes without having to delete them
this includes the nodes and flows?
-
No - they can be disabled but that greys them out (disables input from them). Alternatively groups of widgets can be hidden and shown using ui_control node. But individual ones would have to be removed (or moved to another tab)
-
Feature requests is aimed more at ideas for enhancements to the main application and the core nodes. Flows and other nodes should probably be discussed in General.
Thanks for the answers!
Maybe something “global” could be done here … what if, next to every node (even custom nodes – so it would “built-in” NR), we have a small icon indicating that the node is enabled ? Clicking on the icon would disable the node but transfer the msg unchanged. Clicking again would prevent the msg to be transferred, disabling the rest of the branch … Clicking again would enable the node again.
2 Likes
@tilleul its a purposeful choice not to support enable/disable at the individual node level. There are so many edge cases it introduces that, on balance, it isn’t worth doing.
For example, if a disabled node just passes messages through untouched, when you disable a switch node with 10 outputs, which output should the message get passed through to?
I was looking for either node disable or "path" disable.
Deleting the path works but when you have a lot of different inputs to an upstream node then it is too cumbersome so you can either:
-
insert a function node with default to perform no function other than to merge all the upstream nodes (call it a merge node):
Then you can delete the single trace between the merge and the actual functional node downstream. -
Or you can use the switch node for this purpose (again, still requiring a deploy - but that is ok for me) and setting it to "is null" [inactive] or "is not null" [active] on the output.
The advantage of the switch node in a complex flow is that you don't need to remember where to rewire - just select "is not null" rather than rewiring.
If all you need to do is block messages down a wire then use node-red-contrib-simple-gate and you can control it by sending it messages, so it can be from a dashboard switch, from MQTT, via a global context variable (I think, haven't tried that), or a number of other ways.
Or just disable the node in the bottom left corner of its configuration panel.
1 Like
Not sure if the below will warrant its own topic, but my problem needs a way to enable/disable the node programatically (i.e with a "disable" message targetting the node ID?) unless you can suggest a workaround
My use case is that I turn on/off a socket connected to an amplifier.. and I have a eiscp node in another flow which polls the amplifier so I can send commands to it (when on)
I dont want that node to poll when switch is off, as it logs errors into the debug console every few seconds which cannot be turned off/muted
If I could send a message that would target these nodes I could progamatically enable/disable them, which stops the polling.
1 Like
You could use a function node, with global (or simply with a context variable) variables to achieve this, if the global variable is true then the node will work normally, if not then stops.
Do you have control over the polling or does it run continuously?
The polling runs continuously but I'm not sure if is the "node" that does it or the "controller"
What I mean is if I disable the nodes (As per picture) AFTER the controller cannot reach the device, the controller keeps polling and I keep getting errors ..
If I disable the nodes whilst the amp is available, then I can safelly turn off the Amplifier.
so the only option I think I have with the current implementation, is if I can preemptively disable the nodes
I was going to suggest raising an issue on the node's github page to allow the errors to be disabled, but I see there are already issues complaining about this, and no input from the author. It does rather look as if the author has lost interest in this.
You could quite easily hack the code to remove the error, if you look at the relevant file (eiscp-controller.js) in the node's directory in .node_red/node_modules you will see there are a couple of node.error calls. Whichever one is causing the nuisance then you could just comment that out and restart node-red.
