Stop a flow programatically or easier than deploying a blank flow

[Antonio Ribeiro]

Hey there!

So, I'm new to Node-red but until now I've been finding my way.
But I have 2 questions that I still dont know how to do (and I'm afraid is not possible)

1. Is it possible to stop a flow either programatically or in a easier way other than deleting the nodes and deploying it blank?
2. Is it possbile to close a Sheet tab, I swear I've looked almost everywhere.
   

Sorry if it is too obvious and I couldn't see.

I want to know it cause for a course in my university I'm developing a application that should be easy for
end users to modify and create their own flow and to stop it when necessary (by end users I'm thinking of
a person with almost none computer knowledge e.g. My mother).

Thanks in advance!

[Antonio Ribeiro]

Ah, forgot to say.

I said that I'm afraid it's not possible because of this post:
https://groups.google.com/d/msg/node-red/7UWSV6Z_ars/bmvVF4ej-uoJ

but as this has more than a year, I was hoping it has changed.

Anyway, thanks!

[Antonio Ribeiro]

For the Delete Sheet tab, please ignore.

I have now seen what my eyes didn't see before.

Sorry for the mini flood.

--
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.

--

Antonio Ribeiro

[Julian Knight]

You can either delete the wire going into the node or, you an add a function node that, for example, checks for some variable and only outputs the msg if true;

if ( context.global.keepgoing == true ) {
  return msg;
} else {
  return;
}

[Julian Knight]

Should have said that there was recently a discussion regarding being able to disable nodes. Not sure we really reached a final conclusion though.

[Dave C-J]

It's now on the list ☺ (but not for 0.10.8)

[Dave C-J]

Disabling a node that is....
But that is an edit function.
Not programatically stopping.

[Mike Biddell]

Julian

I have some flows which I dont want to operate after I have gone to bed !! I was thinking I needed a time-between node (which outputs null msg payload between certain times and a normal payload otherwise) , but now I'm wondering whether it could be accomplished with a global function as you have described and using an inject node to set the global false. If so, what is the code in the function to set keepgoing false is it just context.global.keepgoing == false? And would it work???

Cheers

Mike

On Thursday, 11 June 2015 20:55:51 UTC+1, Julian Knight wrote:

[Greg EVA]

In reading this thread, this is pretty much what I was thinking as well.

Antonio's mother, or Mike before bed, or perhaps even someone else could use the inject node as a sort of toggle push button which would exclusive OR the "keepgoing" flag.  Mike, although you could set it, if you XOR it with 1 (or true) then it should just toggle between 0 and 1 without additional lines.

What is missing in this from my perspective is a visual indicator that the flow is being stopped; in this case the TRUE/FALSE state of the "keepgoing" flag.  Is there a way that anyone knows of to be able to stick a node into the flow which would change/update its appearance based on some condition which could accomplish this task?

Cheers,

Greg

[Julian Knight]

Hi Mike, this seems to be a pretty common use case and one of the reasons some people have been asking for more wide-spread access to the context and context.global vars - this is on the roadmap for the next but one release.

I made a little helper node for my own use that sets/gets context.global but you need to be aware that it will be superseded by the roadmap release. See https://github.com/TotallyInformation/node-red-contrib-globalgetset for details. You have to install direct from github.

You don't need that of course and you've got the right code for updating the global variable. Yes, it works. Personally though, I don't like people having to write function nodes to do something that is a fairly common use case. I think we need some kind of block/release node?

[Julian Knight]

Hi Greg, XOR is a good suggestion.

However, again, I'd say that this is too complex for a common use case. We shouldn't need to use code to do a common task, there needs to be a node for that. What I haven't yet got my head around is what that node (or nodes) should look like.

Adding to the complexity is the fact that the NR UI cannot be used as a dashboard so visual indicators are deliberately limited. Not sure what Nick or Dave think about the idea of a block/allow node that has a visual indicator showing which mode it is in?

My thoughts so far (for shooting down) are:

• A stop/go node
• Checks for msg.stopgo. TRUE=go, FALSE=stop
• msg.stopgo could/should be configurable

Doesn't solve the whole problem until we get access to the global variable since you would also need a node to inject the msg.stopgo variable but once global is available programmatically to nodes, it could be updated to allow the use of context.global.something instead of having to use msg.something.

Also, using msg.stopgo would not really permit the use of a visual indicator since you wouldn't know until you received the next msg. An indicator would be more feasible perhaps if using a global variable but still smacks of a dashboard arrangement that I know Nick and Dave want to avoid. I think the best approach would be to have a second output that sent out true/false so you could easily build your own dashboard or just use for debugging.

[Mike Biddell]

Julian

Thanks for that, the global flag function works !!!! I have named it "stop flow" and I have used "inject" to set the flag false between specific times. In this way, you can turn ON and OFF several flows using the same flag. This works well for creating scenarios !!! One scenario I will have is "In bed"/"not in bed", as my system makes weird signalling noises during the day, which would not be welcome at night. To be honest, I am happy with that, but understand your reservation about getting functionality without writing code (if u can describe 5 lines of code as writing LOL). But I suppose it boils down to where you intend to pitch Node. If you want to attract 'novice' users who never intend to write code, then enabling and disabling flows via the palette/gui will probably be needed. But I suspect Dave and Nick will already have thought that balance thru !!!!

Cheers

Mike

[Julian Knight]

Glad you got it done Mike. Would you share the example code on the flows site? I've been meaning to add this to my own automation just have been a bit side-tracked with other business recently. I'm sure that this topic will come up again.

Re a node vs code: I'm afraid I am rather an automation freak - if something may need doing more than once, I'd rather see it done properly so no-one else has to write any code again :-}  5 lines of code is not a lot but it still took time to work out and work through - who else will have to go through the same pain? It isn't difficult to fix, that is one of the great features of NR.

I'd also love to see NR more accessible to non-programmers but that is only my opinion.

[Mike Biddell]

Julian

I've shared the flow and made u famous too !!!! Errr I hope I've done it correctly, it's the first one I've done. If u think it needs changing, give me a shout.

Key words are "inhibit flow time between"

Mike

[Greg EVA]

Although I can totaly understand the guys desire to keep N-R from dashboard type functionality, I can't help but think that it is an obvious requirement of any form of programming/automation tool to be able to see parts that are disabled and to temporarily disable them.  Extremely generally, I am thinking about REMming out a line of code with //, or using a comment block with /* */ or <!-- -->.  Visual or not visual; I think there is an obvious need to be able to say "hey, I still want this here, but just skip over this stuff for right now".

So here we come back to the whole disable/bypass node idea, and the global context.

Have a good weekend all!

[Mike Biddell]

Julian

reflecting upon what you said above about creating nodes rather than writing functions..... the functionality could be achieved with two nodes.

1) an 'inhibit flow' node. This would require an add global flag button, a pull down to select the global from amongst those you have added and a select true/false pull down. So if you selected the 'nighttime' global and 'true', there would be no flow if nighttime == true. The only outputs would be message payload or no message payload.

2) A 'Set flag' node. This would have a pull down to set the globals as added using above node and a pull down for True or False. The output would be a message payload of the flagname and a topic of true or false. This could be driven by any logic on its input, email, inject (time) etc.

These two nodes would implement a massive extra dollop of power to node and implement (effectively), scenarios and states, as large numbers of flows could be enabled and disabled using this methodology.

Mike

[Dave C-J]

Greg,

the ability to disable a node is on the to do list, and yes, one reason we haven't "just done it" is we are considering options for the visualisation so it is obvious what is going on.

However this "disabling" is an edit level function... it won't be accessible at runtime... those are the other ideas being discussed here.

[Julian Knight]

I don't want to set hares running (again) so I think we can agree that things are going in the right direction.

On the roadmap:

• Ability to enable/disable a node at the admin ui
• Access to global vars generically not just from a function node (retained between executions of Node-Red)
  
• Access to context vars generically not just from a function node (retained between executions of a specific node instance)
• Set "flag" capability will be available via the change node when the global & context vars are more widely available

If you want to do some of this right now:

• Enable/disable: you have to delete the inbound wire
• Access to global vars: you need a function node or you can temporarily use the globalgetset node from my github repo
• Access to context vars: only from function nodes
• Set flags: only from function nodes (or my temporary repo)
  

That leaves the idea of an inhibit node as something of interest. You can use Mikes example flow for now but is there interest in a node to support this? I think if it were done now it would require rework when the extended global/context stuff is made available but I'd be happy to put something together if people felt it was a reasonable approach? I don't think it would take long as it is very simple logic.

The status/dashboard question is a bit more tricky and I don't think I've really got my head around the consequences so I'm more than happy to defer to Nick/Dave that it shouldn't be included in the admin ui. It would be an interesting discussion however to think about what a generic operations dashboard might look like! If indeed it were possible.

[Nicholas O'Leary]

Hi Julian, I think that's a reasonable summary.

Once the Switch node can access the shared context, it can be used to block/inhibit a flow based on some condition, so I don't think a separate node is needed.

Nick

--