Introduce boolean logic with node-red-contrib-bool-gate

[Nicolas Frbezar]

I want to introduce you the node-red-contrib-bool-gate.

This node can be used to implement a boolean logic in your flow.

You can check an example on the Import settings, so feel free to take a look at it.

Link : https://www.npmjs.com/package/node-red-contrib-bool-gate

If this node seems good to you, i wiil work on a enhancement, to make the node refresh flow and global data from himself

[Colin Law]

The nand column in the first table in the readme seems to have a mistake in it.

Does it generate an output message as soon as it has sufficient input
messages to know the answer?

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> 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.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/155365c0-d6d2-4d5f-8616-13fa6e19bf94%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nicolas Frbezar]

Yes, in fact, when the flow is launched, the node will start by evaluate each of his rules the first time (in case there is some flow or global properties) and he will send a message true, like the and gate send a message false when launching. I though it was better to do by this way. 

[Colin Law]

I don't think it should send any message until it is sure of the
answer. So for example if the rule is topic A payload > 0 AND topic B
payload > 0 then it should not send a message until it has values for
topic A and B. However if the rule is topic A payload > 0 OR topic B
payload > 0 then if a message for topic A is received first and the
payload is > 0 then it can send a message immediately as the value for
topic B is irrelevant, however if the value for A is not > 0 then it
must wait for a B value to be sure what the answer is.

Colin

> https://groups.google.com/d/msgid/node-red/a7b9858b-4f93-4c33-9cff-9af9f9387a9f%40googlegroups.com.

[Nicolas Frbezar]

Yes, maybe you're right for this case, but imagine rules are only checking flow or global properties, so it will not able to send message, even if he have to. Or maybe adding a checkbox on the node to authorize or not.

That make me think about one thing : like i said, when we used flow or global properties, there is no check anymore, so we are stuck in this node. Maybe i can add a cron on the node, or something like this to fix that (i asked on the slack about the context's change notification and currently, it's not in there roadmap, so we have to check differently). 

[steve rickus]

I wondered about that as well... I would think that if AND is true, then NAND would be false.

But the bigger question I see, and I think you are asking, is what happens when a condition cannot be determined? In pure logic, that may not be an issue -- but in the node-red implementation, there are really 3 condition states: true, false, and undefined

Perhaps if the outcome grid could be updated to include the "undefined" values, the logical outcome in each case would become clearer. Although i doubt any one set of decisions will be acceptable in all situations, at least the edge cases will be better documented.

--

Steve

[Colin Law]

I would not bother with allowing context values, there is no
significant advantage to the user that I can see and goes against the
conventions of node-red. I would limit it to values passed in via
messages.

Colin

> https://groups.google.com/d/msgid/node-red/2860c9dc-0752-4a36-9b31-a38ae45c96d4%40googlegroups.com.

[Colin Law]

I don't think there is a need for an undefined output. Consider the
join node for example, it waits until it has all the data it needs and
then passes on the result. For this node the undefined state will
presumably only happen at startup until it has received the first full
set of data, thereafter it will update its result each time it gets a
new input.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> 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.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/f2a68315-e987-439a-b29e-66286a06f48f%40googlegroups.com.

[steve rickus]

I disagree -- several core nodes already allow setting/getting/checking/updating the flow and global context variables (i.e. change, switch, function, debug).

In fact, I think this is one of the most useful features of the gate node, at least as I would use it. I just want to do things like:

* stop msgs from passing through by flipping a switch on a dashboard (e.g. check the flow context)

* only allow msgs into a flow once all the initial conditions have been populated (e.g. check node context)

* disable dashboard tabs by stopping ui_control msgs unless proper login/access has been set (e.g. in global context)

* discard any msg that is missing certain fields, or has data outside expected ranges (e.g. msg.payload had invalid data)

Requiring change nodes that pull flow/global context values into the msg is certainly possible, but seems messy since those can be checked directly from within the rules (unless there will be async issues with context vars stored outside of node-red).

[steve rickus]

I was really only thinking about the undefined state on the input side, so i guess we are in violent agreement ;*)

But I think we both want it spelled out, what happens during the startup phase before all the conditions can be determined...

[Colin Law]

Global and flow context variables are evil, though others are entirely
within their rights to disagree with me on that.

Google 'why you should avoid global variables' to get insight into
why, in particular the top answer in [1] is interesting. There may
well be occasions when they are necessary in node red, but I have not
had to use one yet, nor do I feel that I have had to add significant
complexity to achieve this.

[1] https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> 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.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/22878341-7136-4f26-b8e3-b46241cc1b6b%40googlegroups.com.

[Julian Knight]

I do disagree!! ;-)

"Global" in the context of Node-RED is NOT the same as global in the context of JavaScript/Node.JS. NR's global variables are not global at all as far as Node.JS is concerned, you are not "polluting" Node's global namespace when using them so you are not creating the kinds of issues you referenced. 

NR's variables are constrained nicely within the application. 

Of course, you should still prefer the order: (1) context, (2) flow, (3) global in order to further constrain the naming but unless you have a truly MASSIVE set of flows, you are really unlikely to cause yourself issues even when using global variables.

[Colin Law]

My point of view is that a node is equivalent to a method or function
in a classical language. Therefore the behaviour of a node should be
entirely determined by the messages passed to it (plus data from any
external interfaces if it interfaces to hardware or some other
external system). This makes it easier to understand the function of
a node. In addition it means the node can be tested in relative
isolation. Using flow or global context means that the behaviour of
a node is determined by other parts of the node-red flows in ways that
are not obvious from looking at the flow. It can make the whole flow
difficult to debug when something is not behaving as expected as an
error in one node or in flow logic can have the side effect of causing
errors in parts of the flow not apparently related to where the bug
actually is. Apologies to anyone who is offended by that long and
rambling sentence, my English teacher would have had a fit over it.

I know many will consider my ideas over-zealous but I really do think
that beginners in particular should be discouraged from dropping into
casual use of flow and context variables, the use of which may often
seem to be the the easiest way to achieve an end. Often it will bite
them in the long run.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> 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.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/113dbfb0-ee0d-4f6d-9014-4a6b549da51a%40googlegroups.com.

[Julian Knight]

What you say is true of course but rather religious perhaps.

The truth is that many flows require more than just the msg and while it is possible to feed everything through the input msg, you would likely do so in many cases by taking data from the memory stores (context, flow, global) anyway.

The way to avoid such confusion without creating yourself mind-bending logic twists is simply to document your flows well. Use descriptive names, comment nodes and, with v17.4, port labels. Comment nodes are a great way to label up flow segments and document global and flow variables.

The point of the memory stores is to allow non-flow related information to be held and used. So anything that transcends a specific execution of a specific node instance. Flags, accumulations, reference data and many more things are able to use these and it will be harder for beginners and experienced folk alike to get things done without them.

So I agree that it is generally best to minimise their use and that does take some extra thought sometimes but lets not be religious about such things, rather be balanced in their use.

[Julian Knight]

And just to be clear for everyone. I fully recognise that things are more difficult when working with a "production" system supported and developed by multiple people. In that case, these issues are multiplied.

[Colin Law]

On 23 July 2017 at 11:37, Julian Knight <j.kni...@gmail.com> wrote:
> What you say is true of course but rather religious perhaps.

Discussions are often more interesting if a point is made in a rather
more extreme way than the one pontificating may actually believe :)

> ...

> So I agree that it is generally best to minimise their use and that does
> take some extra thought sometimes but lets not be religious about such
> things, rather be balanced in their use.

in fact I think that is not much away from my final point that users

"should be discouraged from dropping into casual use of flow and
context variables, the use of which may often seem to be the the

easiest way to achieve an end", which I have to admit is a little way
away from my initial suggestion that they are evil.

I think I had better apologise to Nicolas for hijacking his thread. Sorry.

Colin

> https://groups.google.com/d/msgid/node-red/4c0dd45d-d24a-4e92-bb8e-af90ed8baa8a%40googlegroups.com.

[Nicolas Frbezar]

No, you don't have to, that was really interresting :)