Function Node switch with a Click tab like Enable on Debug to assist in Troubleshooting

[tree-frog]

I have not seen this, but one may exist somewhere. I'll certainly look. But if anyone knows of such a node please send the link my way.

When I'm debugging, sometimes I need to disconnect wires. That requires wire changes and re-deployment. I was wondering if on the Function Node (or common nodes) to incorporate a top, or internal to the body a switch to pass-through or stop the messages cold. Then a means to enable or disable globally. Kind of like Test phase/ Run Phase.

The main idea being a switch, much like the Enable for Debugging purposes.

This is what it takes, Unhook wires and plop a comment near the spot. Test, then undo the test. Or it may be helpful to have a simple pass/no pass message node that has a switch on it. This way you can see your edit b/c you have this thing stuck in your flow. Then remove it once you've solved the flow logic.

Normally the function node works the same. Color coded to alert that the node is OFF or stopping messages. ON works like a normal Function Node. Maybe a setting to enable this or disable outright so that nobody swtiches them OFF when debugging is completed.

Reasoning, You'd need to have this feature on the common nodes in order to make it useful. Otherwise you'd have to stick these switches all over the place. (not good).

If anyone else has thoughts on this kind of "debugging" feature let me know. Otherwiise, it's just an idea.

Thanks.

[E1cid]

You could just drop in a switch node, name it block, then to restore highlight switch node and press control delete

[Frida]

[{"id":"d36b8a7049cbe378","type":"inject","z":"1c60aaeefa9a7d6f","name":"open","props":[{"p":"topic","vt":"str"},{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"control","payload":"open","payloadType":"str","x":150,"y":440,"wires":[["6c909f35f78e2bb1"]]},{"id":"6c909f35f78e2bb1","type":"gate","z":"1c60aaeefa9a7d6f","name":"","controlTopic":"control","defaultState":"open","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","defaultCmd":"default","statusCmd":"status","persist":false,"storeName":"memoryOnly","x":410,"y":480,"wires":[["3f2619add1cb3c37"]]},{"id":"c4b424bb2bc203b7","type":"inject","z":"1c60aaeefa9a7d6f","name":"Your signal","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":160,"y":480,"wires":[["6c909f35f78e2bb1"]]},{"id":"9fe592e4e0e47582","type":"inject","z":"1c60aaeefa9a7d6f","name":"close","props":[{"p":"topic","vt":"str"},{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"control","payload":"close","payloadType":"str","x":150,"y":520,"wires":[["6c909f35f78e2bb1"]]},{"id":"3f2619add1cb3c37","type":"debug","z":"1c60aaeefa9a7d6f","name":"debug 259","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":690,"y":480,"wires":[]}]

Mayby something like this?

[tree-frog]

yes, and NO.

The concept is something applied to the default nodes or all nodes, The concept needs further refinement.

Lets just say for the moment DISABLE. That's close and doable but you have to re-deploy. If you could change the state without re-deploying could benefit. At least while in debug phase. But this is not necessarily "Disabling" the node. It's putting its output in a blocking state. Maybe parts of the message... just payload...

Changing the state of the node vs. adding logic for that purpose in a lot of places is unhandy.

[Steve-Mcl]

Have you tried the node-red debugger plug-in where you can add debug break points in your flow and see what messages are queued up at the paused node?

[mudwalker]

Possibly being a bit 'nit-picky' here, but the Node says for V2.x NR. Assume OK for V3.0.x

[drmibell]

Since you asked mainly about the function node, you could use a (more or less) single line of code at the start of the function, if (global.get('debug')) { return null } and use a change node to set the global debug variable. This flow is an example.

[{"id":"ec86eab9dad42599","type":"function","z":"878b3ee804243e9b","name":"","func":"if (global.get('debug')) { return null }\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":400,"y":560,"wires":[["81422b5e0ca2b0b8"]]},{"id":"df59cf95fd27af18","type":"inject","z":"878b3ee804243e9b","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":260,"y":560,"wires":[["ec86eab9dad42599"]]},{"id":"81422b5e0ca2b0b8","type":"debug","z":"878b3ee804243e9b","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":550,"y":560,"wires":[]},{"id":"b437c11da7968ff8","type":"inject","z":"878b3ee804243e9b","name":"debugging on","props":[{"p":"debug","v":"true","vt":"bool"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":270,"y":460,"wires":[["8fd718962fcd7b57"]]},{"id":"8fd718962fcd7b57","type":"change","z":"878b3ee804243e9b","name":"","rules":[{"t":"set","p":"debug","pt":"global","to":"debug","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":470,"y":480,"wires":[[]]},{"id":"4153d41cd4606a4f","type":"inject","z":"878b3ee804243e9b","name":"debugging off","props":[{"p":"debug","v":"false","vt":"bool"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":270,"y":500,"wires":[["8fd718962fcd7b57"]]}]

If you want a visual indication in the editor, you could set the status on the function node.

[tree-frog]

I'd like to avoid adding external programming to switch off/on messages. In order to allow for this, it would need to be part of something already present. To Enable/Disable at any point in your flow. Like a switch available on common nodes (or all nodes) such that you can stop the flow.

[Colin]

If you allocated hot keys to the Enable/Disable selected nodes action then you would just have to select the node (or nodes) and hit the key to disable it, thereby blocking messages at that point.

[tree-frog]

@Colin ,
Would you need to re-deploy? I’m sure you would. That’s kind of what I had in mind. But very much like the debug node switch to enable/disable node messages.

As I think about it, the switch approach may be not the best. A deploy is not necessary for debug nodes because they don’t affect flow logic. Disabling is an intentional thing which should require intentional action, not unintentional, thus confusing results.

I’m anxious to try this approach. Thanks!

[knolleary]

I could imagine adding a third state to the enable/disable toggle to turn it into a ghost node. The problem with disabling the node (for this specific scenario) is that it breaks the flow. A ghost node would act like a no-op node - messages pass through untouched.

This would still require a deploy - we can't add/remove nodes from the flow with going through a deploy cycle.

[tree-frog]

Yes, that would be the closest to a reasonable solution. Rendering a nodes output disabled may need to be deliberate, thus requiring a deploy.

[dceejay]

The issue always was that most nodes act on the msg.payload - so just making them pass thru would then pass though something that the next node in the chain wasn't expecting and would break most flows so is not something I could imagine being applied in the general case to all nodes.

[tree-frog]

I agree. I was thinking about this as counter productive to the intent. It seems disabling seems like the best method. Removing wires doesn’t allow you to readily see the edits, thus making it difficult to put it all back.

[tree-frog]

UPDATE:
I used combinations that I thought should work. I did check
ctrl-alt-d, Nothing
ctrl-7, Nothing,
ctrl-q, Actually works.

Can you consider giving a list of key-combinations that are NOT USED and DO WORK so it's not try all combinations until something works? Trying to find a hotkeys that you can apply which are not currently used and do actually work takes a bit of patience and time. Thanks!

I’m having some trouble with hot keys and disabling the nodes. I added the hot key in “hot keys”, but it didn’t work even when I restarted NR. Linux Mint and latest beta of NR. Google Chromium browser.

[jbudd]

most nodes act on the msg.payload - so just making them pass thru would then pass though something that the next node in the chain wasn't expecting

I could imagine adding a third state to the enable/disable toggle to turn it into a ghost node.

I don't fully understand the discussion here so I apologise if this is stupid.

Could something be added to junctions to allow them to block message flow?
Or a near duplicate to the junction - a "stop light". Maybe it would print the message in the debug panel and then discard it, so no queueing ability.

You can insert a junction into an existing wire and you can remove and reconnect.

Deploy when you insert/remove but a runtime switch to pass or block messages. cf enable/disable the debug node (which now flags for deploy but doesn't require it. I think this is new behaviour from NR v2?)

[Colin]

@jbudd

Could something be added to junctions to allow them to block message flow?

It is possible to Disable junctions using Disable Selected Nodes. Then they do not pass messages. It is necessary to deploy to do that though.

[quote="jbudd, post:17, topic:77504"]
cf enable/disable the debug node (which now flags for deploy but doesn't require it.
[/quote]]

I believe that disabling a debug node, without deploying, just suppresses the message in the browser, it does not affect the running flows. To block messages in the server needs a change to be made on the server, not just in the browser.