How to comment out a node?

I am aware of this but it's clunky and not built in.

I don't think an inline clickable toggle (without injects and without flow or global state) of some kind would take much doing. Effort vs benefit is decent.

As for node disable, I expect that probably will be a deploy thing but if possible at runtime then that would be a great benefit.

That's why I propose it to be a built-in node: some kind of gate node with a button to open/close the gate.
After all, more than disabling nodes we're talking about disabling a flow after a given point ... that point could be a special gate node with a button.

Ah miss read. Sorry. Yes. I said something similar on my first post in this thread. If the gate had 2 outputs, the 2nd could provide alternative msg flow path (for debug or emergency situations- off the top of my head).

But yes. Definitely built in and definitely runtime :).

:crossed_fingers:

Ahh but if you are using it for debugging you would have to add the nodes, connect the wires, deploy and then press the tab...but wait, I need to turn off another node...add the node, connect the wire, deploy, press the tab and test.

Or I could disconnect the wire, deploy, test

Or if you can disable the node - open the node, disable it, test.

I'm actually pretty happy disconnecting the wire and testing.

That's fine if it's just one wire. If it links to several or stretches down past others (i.e. not obvious where to reconnect).

It's just not the ideal tbh. I favour a more elegant solution.

What you're saying is akin to deleting a line of code as opposed to commenting it out.

I'm not sure why so many people are ready to accept status quo when we can have more tools in the virtual tool bag.

I can think of several ways to no-op a node.

    1. Stick a no-op function into the wire into the node you want to turn off: payload="";return msg;
    1. Break the wire to the node.
    1. If you want it dashboard switchable function, use a switch or button to set a variable then test the variable in the no-op function or a switch node.
      What I can't think of is, why?

Then use a link node to collect all the wires. To break the link just double-click it and link to a null link that goes nowhere. Or fan-in to a link node, link to a switch then fan-out through another link.

Hi @SteveMann, thanks for the comments but if you see the gif I posted in this thread yesterday you would see I'm not looking for workarounds and it's not like I haven't thought of every one of the workarounds offered by people, it's just that they don't fit.

Untill someone can tell me how to halt flow of messages at runtime

  • without adding some combination of inject & flow or global flags
  • without modifying / deploying (either breaking wire or adding a noop)

...then it doesn't fit.

I don't think a debug switch/gate node is a big ask and I believe it will be well used. A simple and effective node that would simplify many debug / bypass / link-out situations without the need to modify a flow or litter it with injects and context flags.

1 Like

Actually @SteveMann you have given me a thought.

To avoid adding a new node to the default pallet, the link node could be modified (in a none breaking way / backwards compatible) to have a runtime toggle that enables/disables flow of messages. That would satisfy the requirements :thinking:

Ummm, why not just insert the following as the first line of the node you want to disable:

return;

or

return null;

st

Like an enable pin on a chip?

Ummm why not read the thread?

e.g...

Yeah. It would satisfy the runtime aspect of being able to enable/disable flow of messages, be built in & I believe could be implemented with backwards compatibility (e.g. if you import a newer flow JSON into an older node-red, it would simply render as an original link node)

@Steve-Mcl As I've said, we will introduce the ability to disable any node.

It doesn't require any special nodes in your flow. It doesn't require any changes to the structure of your flow when you realise you want to disable something.

It does require a deploy. It may not be exactly what you want, but it is something that will address a number of requests and use cases.

You've said a few times that your proposal would not take much doing.

That simple isn't the case. We have no precedent for having a node in the middle of a flow that has a button or state that can be toggled in the editor without a deploy. The UI design work to get that right is not trivial.

I understand what functionality you want. I'm not ignoring it. But I do have to align it with work we already have underway and work we have planned.

Further down the line we have plans for a flow debugger (after 1.0 ships). I would not want to rush something in now that introduces new UI concepts at this stage of getting to 1.0, particularly when it overlaps with a whole area of functionality we want to focus on later this year.

But it certainly feeds into the bucket of functionality the flow debugger can enabled.

2 Likes

It's a perspective thing. Behind the scenes, the discarding of a msg seems trivial. I didn't wholey consider the UI part to be a large undertaking as we have the inject with a button on it. But if anyone knows it'd be you.

Keep up the good work.

Not sure if anyone is still looking into this but I had a similar need and here is what I came up with to resolve it. It doesn't meet the stated requirements but practically speaking it should work.

It can be dropped anywhere in the flow without editing in multiple places and is completely self contained. No need to define flow or global variables. If you want the gate to default to "Off" on deploy leave the "Inject once" box unchecked. If you prefer it defaults to "On" on deploy, check the box.

The only issue will be if you try to pass a message that consists of the string "switcharoo", since that's the trigger. I would imagine that is most unlikely but if so it should be easy enough to implement an alternative phrase.

I hope this can be of use to someone else.

Flow%20Gate

[{"id":"3259db28.f50004","type":"inject","z":"d0598402.999e3","name":"Toggle Gate","topic":"","payload":"switcharoo","payloadType":"str","repeat":"","crontab":"","once":true,"onceDelay":0.1,"x":590,"y":300,"wires":[["14b0d29a.f9aa4d"]]},{"id":"14b0d29a.f9aa4d","type":"function","z":"d0598402.999e3","name":"Flow Gate","func":"var value = msg.payload;\nvar switchState = context.get(\"toggle\");\n\nswitch (value) {\n case \"switcharoo\":\n if (switchState === true){\n context.set(\"toggle\", false);\n node.status({fill:\"red\",shape:\"ring\",text:\"Off\"});\n }\n else {\n context.set(\"toggle\", true);\n node.status({fill:\"green\",shape:\"dot\",text:\"On\"});\n }\n break;\n default:\n if (switchState === true){\n return msg;\n }\n}","outputs":1,"noerr":0,"x":600,"y":360,"wires":[["9214e554.6a535"]]}]

<self-promotion> At the cost of loading a contributed node, node-red-contrib-simple-gate will give you the same capability with a bit more flexibility. </self-promotion>

1 Like

Hi, i see that there is now the option to deactivate a node (which is very useful for UI-Nodes, because when you just disconnect it, you will still have a placeholder in the dashboard). As far as i know, it is only possible in the node-configuration. Is there also a way to dynamically deactivate single nodes by code for example by msg.payload properties?

First off, welcome to the forum!

No there is no way to disable a node via something in the msg object. And if you did none of the nodes after that would run.

You could put a switch node before the node you want to disable and check something in the msg, then if it exist, bypass the node with a wire bypassing the next node. Otherwise the output of the switch would go to the next node.

Here is an example:

[{"id":"f10dab3c19a367f7","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"f1ad68685a5090d2","type":"inject","z":"f10dab3c19a367f7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":60,"y":120,"wires":[[]]},{"id":"af4995b295c02e2c","type":"inject","z":"f10dab3c19a367f7","name":"Don't skip","props":[{"p":"payload"},{"p":"topic","vt":"str"},{"p":"Skip","v":"No","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":100,"y":240,"wires":[["c5de588e59935b89"]]},{"id":"efc20d9cdf1bfdb8","type":"debug","z":"f10dab3c19a367f7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":390,"y":240,"wires":[]},{"id":"c5de588e59935b89","type":"switch","z":"f10dab3c19a367f7","name":"","property":"Skip","propertyType":"msg","rules":[{"t":"eq","v":"Skip","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":210,"y":300,"wires":[["efc20d9cdf1bfdb8"],["c6a109b1cea45667"]]},{"id":"c6a109b1cea45667","type":"change","z":"f10dab3c19a367f7","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"I wasn't skipped!","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":390,"y":320,"wires":[["efc20d9cdf1bfdb8"]]},{"id":"7b4be5bc3fd2385c","type":"inject","z":"f10dab3c19a367f7","name":"Skip","props":[{"p":"payload"},{"p":"topic","vt":"str"},{"p":"Skip","v":"Skip","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":90,"y":360,"wires":[["c5de588e59935b89"]]}]

Lastly, this thread is over three years old and I’ll be closing it. If you still have issues open a new thread.