Disable node
1,652 views
Skip to first unread message
Marcel Timmers
May 19, 2015, 3:40:37 PM5/19/15
to node...@googlegroups.com
Is there a simple way to disable / pass-through / inactivate a node or nodes?
thanks in advanced
Julian Knight
May 19, 2015, 3:54:43 PM5/19/15
to node...@googlegroups.com
The easiest way is to rewire it and change the deploy button to only deploy the changed flow which saves you the time of reloading NR.
There is no way to actually temporarily deactivate a node.
There is no way to actually temporarily deactivate a node.
Shem Jamieson
May 20, 2015, 9:23:42 AM5/20/15
to node...@googlegroups.com
As Julian says the answer is no (apart from rewiring). I think it has been discussed a few times here. One of the problems is it could be confusing having disabled flows etc.
Adam S
May 20, 2015, 9:30:13 AM5/20/15
to node...@googlegroups.com
I was actually thinking of posting something similar to this. It would be very helpful in some cases to be able to disable flows instead of exporting, saving the text, deleting, testing, then finally importing again. I second this feature request.
Dave C-J
May 20, 2015, 10:06:29 AM5/20/15
to node...@googlegroups.com
As node is event driven you just need to break any input connection and that part of the flow won't run. You can also start node-red with a flow file name as a parameter, so easy to swap flows.
Adam S
May 20, 2015, 10:14:30 AM5/20/15
to node...@googlegroups.com
Never thought of that, guess that would work too. Still, for ease of use I think we should have some sort of disable attribute.
Marcel Timmers
May 27, 2015, 2:06:27 PM5/27/15
to node...@googlegroups.com
hmmm, that's a bummer,
I worked for many years with Reason (https://www.propellerheads.se/reason) , I know Reason is for a completely different purpose, its for music production, but the idea is the same.
Wire (virtual)devices and program(events) in a sequence, its very common when producing to disable/enable virtual devices
Wire (virtual)devices and program(events) in a sequence, its very common when producing to disable/enable virtual devices
my 2 cents
Julian Knight
May 27, 2015, 5:03:20 PM5/27/15
to node...@googlegroups.com
I must admit that I think the complexity worth the effort. I would suggest two options if it were to be considered:
- Disable but passthrough - makes the node "transparent" and passes the message straight through.
- Disable with no passthrough - simply blocks any messages.
Each would need some kind of status indicator in the UI. You would also need a way of changing state - right mouse button menu + keyboard shortcut?
I would think the hardest part though would be that the underlying core processing of NR would need changing to make this work. After all, this would have to work for every node type without changing the node definitions themselves. A complex change I'm imagining though better done sooner rather than later as it is unlikely to get easier to do.
Nicholas O'Leary
May 27, 2015, 5:16:30 PM5/27/15
to Node-RED Mailing LIst
Putting aside the debate of whether we should/shouldnt do it, the hard work is very much the UI side of things.
Providing an intuitive way to enable/disable nodes and make it obvious what state they are in, especially if there are multiple types of 'disabled' would need some careful design work. Personally, not a fan of right-mouse button menu - doesn't translate well to touch UIs.
Then there is the question of API - do we provide an API to enable/disable individual nodes or is it a property of the nodes that gets applied when you do a deploy.
The runtime changes would be fairly trivial - the message routing layer would handle everything without individual node implementations have to concern themselves.
Anyway, nothing insurmountable, if it were something we were considering... I'll admit, I'm not as opposed to the idea as I once was.
Nick
--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Julian Knight
May 27, 2015, 5:56:00 PM5/27/15
to node...@googlegroups.com
Putting aside the debate of whether we should/shouldnt do it, the hard work is very much the UI side of things.
> Well, it isn't MY hard work! :}
Providing an intuitive way to enable/disable nodes and make it obvious what state they are in, especially if there are multiple types of 'disabled' would need some careful design work. Personally, not a fan of right-mouse button menu - doesn't translate well to touch UIs.
> Certainly don't deny that it requires some careful design. Helpful to experimentation and rapid development though. It would be really nice to be able to build a flow with several "train tracks", optional branches, where one could quickly turn on/off each branch on need. Particularly useful if one were to use NR as an ETL or analysis type tool.
> Personally I've found rmb to translate well to press and hold in touch terms - but then I'm hardly your average user. I'm sure there must be other ways.
Then there is the question of API - do we provide an API to enable/disable individual nodes or is it a property of the nodes that gets applied when you do a deploy.
> Well this is only my opinion of course but I'd be inclined to leave it as a deploy as long as it could work with a changed nodes only deploy so you didn't have to wait for a full restart. I'm guessing that would slightly simplify things?
Anyway, nothing insurmountable, if it were something we were considering... I'll admit, I'm not as opposed to the idea as I once was.
:)
I've come across many other open source developments that have possible enhancement lists with voting - any possibility of that? Not suggesting that the inmates should rule the asylum, simply something that might influence development choices from time to time. That way, people could see the longer list of enhancements being considered along with some order and could vote for things to be moved up the priority list (or even donate money to pay for developer time? don't know if that would be considered given the origins and overall IBM ownership though). Still, food for thought.
I've come across many other open source developments that have possible enhancement lists with voting - any possibility of that? Not suggesting that the inmates should rule the asylum, simply something that might influence development choices from time to time. That way, people could see the longer list of enhancements being considered along with some order and could vote for things to be moved up the priority list (or even donate money to pay for developer time? don't know if that would be considered given the origins and overall IBM ownership though). Still, food for thought.
Max Hadley
May 27, 2015, 6:25:51 PM5/27/15
to node...@googlegroups.com
Personally I don't feel a great need for this feature, but if it were to be considered, I think it would be more natural to disable a wire, rather than a node. The state could be easily shown in the UI, by changing to a dashed line style, and the meaning of a disabled wire is pretty clear, no?
Dave C-J
May 27, 2015, 6:33:29 PM5/27/15
to node...@googlegroups.com
My first reaction to that is... Yeah. That is why I love these discussions... Would fit with my mental model of temporarily disconnecting a wire (but without breaking it). Needs more thinking about but would seem a valid alternative approach.
Nicholas O'Leary
May 27, 2015, 6:36:12 PM5/27/15
to node...@googlegroups.com
One downside... it wouldn't handle the pass-through scenario, if that were a scenario we wanted to cater for.
N
On Wed, 27 May 2015 23:33 Dave C-J <dce...@gmail.com> wrote:
My first reaction to that is... Yeah. That is why I love these discussions... Would fit with my mental model of temporarily disconnecting a wire (but without breaking it). Needs more thinking about but would seem a valid alternative approach.
--
Dave C-J
May 27, 2015, 7:38:37 PM5/27/15
to node...@googlegroups.com
Disable I can understand. Not sure about pass thru. What would that mean for a switch node ? Or http request, or file read... Or even most functions...? I think there are more cases where it wouldn't work and would be more confusing that not.
Julian Knight
May 28, 2015, 5:49:20 AM5/28/15
to node...@googlegroups.com
Well to me, it seems natural as a node is "merely" a process you do to a msg. So having a disable/passthrough simply means turning off the process but not blocking the msg flow.
However, you are certainly right that passthrough may not make sense for every type of node. For things like HTTP request and file read, passthrough would be equivalent to block since it is the node itself that creates the msg and by definition, passthrough means not executing the contained code. Not too confusing I think as long as the description of block and passthrough are clear. Again, I think function nodes would be ideal candidates since their purpose is to have an effect on msg as it passes through.
However, where there are multiple outputs is where things get more complex. How would that be handled? I guess it wouldn't be possible to do passthrough then without some serious side effects. The logical extension of the way I've described the effect would be equivalent of having a single output wired to multiple downstream nodes (e.g. the same msg goes to all connected nodes). I can't think of many cases where that would actually work since the whole point of multiple outputs is to send them different output.
I can also see the logic of thinking about disabling wires though to me that seems to move away from the core idea of NR which seems to be that nodes accept a msg, do something and pass 1 or more msg's downstream. That's to say that it is the nodes that do everything, the wires merely connect nodes. But that is probably just my warped way of looking at things :} Certainly, as Nick says, disabling wires would preclude being able to just turn off a node's processing without blocking the flow. However, it certainly would meet the other requirement of simply blocking the flow - though it wouldn't allow you to block a source node so you would not be able, for example, be able to stop an HTTP/websocket/MQTT listener - blocking the downstream wire would not be the same since the listener node would still be processing - possibly not what you want.
However, you are certainly right that passthrough may not make sense for every type of node. For things like HTTP request and file read, passthrough would be equivalent to block since it is the node itself that creates the msg and by definition, passthrough means not executing the contained code. Not too confusing I think as long as the description of block and passthrough are clear. Again, I think function nodes would be ideal candidates since their purpose is to have an effect on msg as it passes through.
However, where there are multiple outputs is where things get more complex. How would that be handled? I guess it wouldn't be possible to do passthrough then without some serious side effects. The logical extension of the way I've described the effect would be equivalent of having a single output wired to multiple downstream nodes (e.g. the same msg goes to all connected nodes). I can't think of many cases where that would actually work since the whole point of multiple outputs is to send them different output.
I can also see the logic of thinking about disabling wires though to me that seems to move away from the core idea of NR which seems to be that nodes accept a msg, do something and pass 1 or more msg's downstream. That's to say that it is the nodes that do everything, the wires merely connect nodes. But that is probably just my warped way of looking at things :} Certainly, as Nick says, disabling wires would preclude being able to just turn off a node's processing without blocking the flow. However, it certainly would meet the other requirement of simply blocking the flow - though it wouldn't allow you to block a source node so you would not be able, for example, be able to stop an HTTP/websocket/MQTT listener - blocking the downstream wire would not be the same since the listener node would still be processing - possibly not what you want.
Greg EVA
May 28, 2015, 10:05:23 AM5/28/15
to node...@googlegroups.com
My couple Euro cents...
I agree that having multiple disabled states could be confusing.
Why not just keep it to one disabled/enabled state.
Then have "what happens" be dependant on where the node is in the flow. If it is triggering (input) the flow, then disable would obviously mean that the node would no longer fire the flow (no connections, etc.). If it is inside of the flow, then the 'msg' would just be passed straight through.
Although the unwiring example is obvious, I came across something yesterday where this would have been helpful. I had a node which was doing some general processing of sorts that would be done to various values coming through the flow. This node was also wired to multiple outputs (debug, MQTT push, MySql insert, IBM Bluemix, as some examples). I wanted to take this node temporarily out of the flow, so I removed the wires, but all of a sudden the guides of what the heck was going on were all gone and I had to think about it again in order to rewire everything. Just being able to disable that node without changing the wiring would have allowed me to do my testing and then re-enable it.
In my case, the term "Bypass" might be better than disable... as this is really what I was wanting to happen. Visually... the connection points on the node could be pulled off of the rectagle, and a wire going over and around the node could connect the two connection dots. This would also show that the node was no longer in the flow (and it may for example have a reduced opacity). I guess a trick would be what happens with multiple output nodes.
I agree that having multiple disabled states could be confusing.
Why not just keep it to one disabled/enabled state.
Then have "what happens" be dependant on where the node is in the flow. If it is triggering (input) the flow, then disable would obviously mean that the node would no longer fire the flow (no connections, etc.). If it is inside of the flow, then the 'msg' would just be passed straight through.
Although the unwiring example is obvious, I came across something yesterday where this would have been helpful. I had a node which was doing some general processing of sorts that would be done to various values coming through the flow. This node was also wired to multiple outputs (debug, MQTT push, MySql insert, IBM Bluemix, as some examples). I wanted to take this node temporarily out of the flow, so I removed the wires, but all of a sudden the guides of what the heck was going on were all gone and I had to think about it again in order to rewire everything. Just being able to disable that node without changing the wiring would have allowed me to do my testing and then re-enable it.
In my case, the term "Bypass" might be better than disable... as this is really what I was wanting to happen. Visually... the connection points on the node could be pulled off of the rectagle, and a wire going over and around the node could connect the two connection dots. This would also show that the node was no longer in the flow (and it may for example have a reduced opacity). I guess a trick would be what happens with multiple output nodes.
Dave C-J
May 28, 2015, 10:44:14 AM5/28/15
to node...@googlegroups.com
Disable I can see no problem, and yes I take Julian's point about wanting to disable an actual input node rather than it's output (wire) - but I guess I'm still not quite "getting" bypass/passthru... when I look at any of my flows I think there may be possibly one or two nodes (out of lots) that could be bypassed and still have the flow do something almost useful... or continue to work enough to not make debug worse. Maybe if I was just adding something to the payload or another property and then wasn't using it later... err...
The only core node that I can think of for which bypass may work would be the delay one ?
For the occasional function editing the first line to be return msg; would have the same effect. (I know it's not visual - but you can always edit the name also)
Not saying it's not valid - but I'm still not seeing the use case for the bypass piece of this.
Julian Knight
May 28, 2015, 6:05:07 PM5/28/15
to node...@googlegroups.com
Well I can see that we are not convincing you Dave. I can certainly agree that the need is a relatively rare one, Greg's example not withstanding.
But Greg's example is certainly a good one. Having to do lots of rewiring is always going to be painful and could lead to errors. Certainly it costs time and effort. The bypass seems a pretty simple addition if the block is accepted. Keeping it simple and making every output get the input without changes.
I think both Greg and myself are thinking of similar use cases here - general processing. Such as you would do when working on ETL type processing. I can think of several places in my home hub flows alone where being able to bypass a node would be helpful at least during development. When doing repeatable ETL, this would be even more common. It would also be very useful in testing. Ensuring that downstream nodes such as templates can cope if a processing node fails to process the msg - maybe because the input was unexpected. All without the pain of rewiring.
One possible compromise if the implementation was considered too difficult would be to retain just the idea of a disable/block. In that case, we could draw a new wire over the top of the node. Not as many benefits and it wouldn't help Greg's case but it would at least hit the majority of uses.
But Greg's example is certainly a good one. Having to do lots of rewiring is always going to be painful and could lead to errors. Certainly it costs time and effort. The bypass seems a pretty simple addition if the block is accepted. Keeping it simple and making every output get the input without changes.
I think both Greg and myself are thinking of similar use cases here - general processing. Such as you would do when working on ETL type processing. I can think of several places in my home hub flows alone where being able to bypass a node would be helpful at least during development. When doing repeatable ETL, this would be even more common. It would also be very useful in testing. Ensuring that downstream nodes such as templates can cope if a processing node fails to process the msg - maybe because the input was unexpected. All without the pain of rewiring.
One possible compromise if the implementation was considered too difficult would be to retain just the idea of a disable/block. In that case, we could draw a new wire over the top of the node. Not as many benefits and it wouldn't help Greg's case but it would at least hit the majority of uses.
Dave C-J
May 28, 2015, 7:34:07 PM5/28/15
to node...@googlegroups.com
Can someone post a fragment of a flow that can demonstrate the utility of this ?
As you said if you want a simple bypass then just wire over the top, and disconnect the input side of the node where there is only one wire to replace rather than the multiple outputs.
I do get the block/disable idea.
Greg EVA
May 29, 2015, 11:02:39 AM5/29/15
to node...@googlegroups.com
@Julian - you are bang on with what I am thinking. Adding/removing wires, especially when things start to get complex is a good way to start breaking things and introducing problems where you thought you had things working well.
@Dave - Here are two examples.
https://dl.dropboxusercontent.com/u/79298132/NodeRED_Bypass_Example1.png
https://dl.dropboxusercontent.com/u/79298132/NodeRED_Bypass_Example2.png
@Dave - Here are two examples.
https://dl.dropboxusercontent.com/u/79298132/NodeRED_Bypass_Example1.png
https://dl.dropboxusercontent.com/u/79298132/NodeRED_Bypass_Example2.png
I hadn't thought about just wiring over the node.... this is actually a pretty good idea. Except that it doesn't work to wire from an input to output node. And the idea to wire around the node from the nodes before or after the node you wish to bypass still requires rewiring, and there could be multiple wires on both sides (as in my first example).
--
http://nodered.org
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/Ds_bnwjKXo0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.
Nicholas O'Leary
May 29, 2015, 11:12:44 AM5/29/15
to Node-RED Mailing LIst
Greg - may be helpful to describe those two examples a bit... and why disabling those nodes in these examples would be a useful thing.
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
Dave C-J
May 29, 2015, 11:43:01 AM5/29/15
to node...@googlegroups.com
So, in the second example if you bypass prepare msg - surely emoncms will barf ? So wouldn't it be better to just disable the emoncms one... and add another debug to output of prepare msg so you can see what is going on while you mess with it ?
I can see it could work in the first case as the name implies you are only dropping messages anyway and not changing them - but it's pretty rare that you are not modifying the payload. You could of course have two of those nodes side by side (as you do on the inputs), one for the output of each function, and then they would only have one wire in each :-).... Or the GetTotalEnergy node could output two messages (the one it gets in and the result - see http://nodered.org/docs/writing-functions.html multiple messages) - and then it wouldn't have a bypass wire to worry about...
Slight change of topic - we do have a Report by Exception node - that only outputs the payload if it has changed...
Julian Knight
May 29, 2015, 4:05:50 PM5/29/15
to node...@googlegroups.com
For example - drat! Why does the Google Groups web interface insist on inserting images at the top of the post!!
Also note an example of the formatting error in the comment node that I was referring to in another post.
Greg EVA
Jun 1, 2015, 5:06:43 AM6/1/15
to node...@googlegroups.com
@Nick - Valid point about the examples.... I was providing the requested flow screenshots however. ;-)
Example 1: There is a fair amount of stuff happening before this "Pass If Changed" node in preparing the data and payload. I put this node here to ensure the data was really changing before passing it along as I was getting data being republished despite it bieng the same values. Then I came back at one point and was wondering why the data was not being updated, and so would have like to "bypass" this node to see if it wasn't the one blocking the flow. It was, and in fact all was well, just nothing was changing.
Example 2: Prepare MSG function actually combines and adds a bunch of stuff to the msg to prepare it nicely for what EmonCMS is looking for. DEL extraneous is meant to get rid of msg properties which EmonCMS doesn't care about. I was having problems getting the data formatted correctly, and getting it to send data appropriately to EmonCMS. Being able to bypass these nodes while debugging would have quickly allowed me to be sure about what part of the msg and payload were being changed where without having to add 3 or 4 extra debug nodes (which is what I ended up doing).
@Dave - The question for me is not about EmonCMS, and trying to address each possibility with an alternative option, as there are surely many! The idea for me is a suggestion and conversation around something that I would find helpful and yet comprehensive.
I know there are deep Node-RED design principles at play here... so I will let you guys figure that part out!
@Julian - That is an interesting flow, and approach with the dummy node. I like it. Thanks for sharing.
Example 1: There is a fair amount of stuff happening before this "Pass If Changed" node in preparing the data and payload. I put this node here to ensure the data was really changing before passing it along as I was getting data being republished despite it bieng the same values. Then I came back at one point and was wondering why the data was not being updated, and so would have like to "bypass" this node to see if it wasn't the one blocking the flow. It was, and in fact all was well, just nothing was changing.
Example 2: Prepare MSG function actually combines and adds a bunch of stuff to the msg to prepare it nicely for what EmonCMS is looking for. DEL extraneous is meant to get rid of msg properties which EmonCMS doesn't care about. I was having problems getting the data formatted correctly, and getting it to send data appropriately to EmonCMS. Being able to bypass these nodes while debugging would have quickly allowed me to be sure about what part of the msg and payload were being changed where without having to add 3 or 4 extra debug nodes (which is what I ended up doing).
@Dave - The question for me is not about EmonCMS, and trying to address each possibility with an alternative option, as there are surely many! The idea for me is a suggestion and conversation around something that I would find helpful and yet comprehensive.
I know there are deep Node-RED design principles at play here... so I will let you guys figure that part out!
@Julian - That is an interesting flow, and approach with the dummy node. I like it. Thanks for sharing.
Greg EVA
Jun 1, 2015, 5:08:09 AM6/1/15
to node...@googlegroups.com
The node you are seeing in the examples are the RBE node...
Julian Knight
Jun 1, 2015, 4:37:48 PM6/1/15
to node...@googlegroups.com
No problem, I meant to mention that I use the timestamp contrib node as it seems light and innocuous.
On Monday, 1 June 2015 10:06:43 UTC+1, Greg EVA wrote:
@Nick - Valid point about the examples.... I was providing the requested flow screenshots however. ;-)
...
Reply all
Reply to author
Forward
0 new messages