Announce: node-red-contrib-boolean-logic

[Per Malmberg]

Hi,

Here's my solution to easily handle boolean logic in Node-RED without the need for multiple inputs or custom Javascript in function-nodes.

https://github.com/PerMalmberg/node-red-contrib-boolean-logic

https://www.npmjs.com/package/node-red-contrib-boolean-logic

Feedback is wanted.

Br,

[Dave C-J]

Hi,

Nice. But seeing as you asked for comments :-)
Generally we like to try and preserve as much of the msg passing through as possible.. ie all the other properties. You generate a new msg in each node.
Ideally the red status should be the ring shape so people who are red/green colour blind can spot the difference more easily.
Not sure the debug node is needed when they all show their output status anyway.
Could the invert not just need another option within the main node ?

[Per Malmberg]

Thanks for the feedback, Dave.

> Generally we like to try and preserve as much of the msg passing through as possible.. ie all the other properties. You generate a new msg in each node.

Yeah, I thought about that but decided to go for this solution as it didn't make sense to modify the payload while keeping the other parts; they'll be out of context when the payload changes.

> Ideally the red status should be the ring shape so people who are red/green colour blind can spot the difference more easily.

Agree, I'll change that.

> Not sure the debug node is needed when they all show their output status anyway

When connected to other nodes in this package it doesn't give much value, as you right point out. The idea is that you can connect it to any part of your schema to see what the value would be when converted to a boolean for debugging purposes. For example, am I getting a 'true' from that MQTT node?

> Could the invert not just need another option within the main node ?

It can indeed.

[Nicholas O'Leary]

> Yeah, I thought about that but decided to go for this solution as it didn't make sense to modify the payload while keeping the other parts; they'll be out of context when the payload changes.

But that means it is impossible to use these nodes with, for example, the HTTP In/Response nodes. You don't know what other properties the user has added. By dropping them you are limiting how useful these nodes are.

Nick

--
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.
For more options, visit https://groups.google.com/d/optout.

[Dave C-J]

Though - if the node is waiting for (say) 3 incoming topics from different places which of those input msgs should supply the extra properties ? Especially if the arrival order is not consistent.

[Dave C-J]

Re debug
Or indeed we already have parsers that do string to Json and such like... So it could be an "anything" to Boolean node (ie have an output) ... Or is that just a case of a one input or gate ;-)

[Per Malmberg]

Yes, also a reason why I chose the current solution.

Nick's use case mixes boolean logic with data-flow. I think it is better to split the flows in two, then merge it all at the end.

[Nicholas O'Leary]

But with no preserved message properties you make it impossible to do any future merge reliably.... you cannot correlate the messages coming out of your node with what was put in. That's fine if your flows are entirely synchronous, but as soon as you have an async element it is entirely possible for messages to over take one another, so you cannot rely on order.

Nick

On Sun, 21 Aug 2016, 22:17 Per Malmberg, <per.ma...@gmail.com> wrote:

Yes, also a reason why I chose the current solution.

Nick's use case mixes boolean logic with data-flow. I think it is better to split the flows in two, then merge it all at the end.

--

[Per Malmberg]

Well, I thought about that too, but didn't see the value in it as all these nodes already converts the input to boolean values. However, if you feel that it would be of value I've got no real objection to it.

A one-input BooleanLogic node is currently not supported - all the operations require at least two operands so it can only be configured with 2 or more inputs. Oh - this is why I didn't merge the Inverter into the BooleanLogic node, it only operates on one value.

[Dave C-J]

Well they could default to 2 inputs but allow the user to set it to 1 if you wanted...
Or hide the numbers input option when invert mode was selected, etc.

Also slightly confusing that 2 is true and "2" is false, but at least it is documented. Guess that's why you need the debug !
But at the end of the day they are your nodes :)

[Per Malmberg]

Haha, ouch. :)

This is why feedback is such a good thing! Ideas only get better with it!

Yes, I've seen that discrepancy too. Guess I could try to parse strings and numbers to make that more consistent. 

I'll sleep on the one-input node thingy...

Cheers!

[Per Malmberg]

v0.0.2 is published.

* Changed status indicators from dot to rings for false-values.

* Reworked the conversion of input values to be consistent between numbers and strings with numeric meaning.

[Guilherme Francescon Cittolin]

Hi Per,

Congratulations for your work, finally I got some time to take a look at your nodes. I have although some suggestions/thoughts to them:

• It would be maybe nice to have and empty/unknown status, so one could easy visualize when a node is cleared with the additional topic, or when the flow is newly deployed. Right now, when the flow is deployed, the status is kept from the last message sent from the previous configuration, which may be a bit confusing

• There's a lot of discussion on the internet about how the XOR operation with 3 or more inputs should behave, either in the "odd parity" or the "1 and only 1" mode. As I could see, you implemented the "1 and ony 1" mode. Strictly speaking, boolean operators perform only between two values, but for the current implementation, it would be nice to have the mode documented (or maybe the two of them implemented? :) )

• I somehow miss the fact that the node sends a result message only when it has all the values. If we want to compare with an electrical circuit or even a PLC, we usually don't have an 'undefined' state, but a 'default' value, in coherence to how a logic system was built or programmed. Imagine interacting with different sources of messages, where you may not be able to read the initial value by the time of a deploy, unlike the gpio's node... I don't know, just want to bring up the idea :)

• At least but not last, I also like the idea that the original message should be preserved. We don't even have an async process that could justify not preserving it, and can potentially make the integration with other nodes more difficult. It would even be more concise when we consider the point above. But that's only my point of view :)

Once more, congratulations for the great job and thanks for sharing your work with the community!

[Per Malmberg]

Hi Guilherme,

Thanks for the feedback.

> It would be maybe nice to have and empty/unknown status

Agreed. Will be added in 0.0.3. I'll publish this shortly.

> XOR.

Yes, you're right about it normally only operating on two operands. The 1 and only 1 function is what I see myself needing in my flows. If you want the odd parity you're welcome to submit a pull request for it.

> I somehow miss the fact that the node sends a result message only when it has all the values

That is how it operates. No value until it has its required number of topics. But based on the rest of your text, I assume you actually want it to use a default value before it has all its input values? 

A 'default' state is not bad idea, but at the same time it would result in the node emitting a value not based on real data. In my use case (an alarm) that would be a bad thing so I want the current behaviour.

> At least but not last, I also like the idea that the original message should be preserved.

If it outputs a default value before it has all its input values, then this is not a problem, its just a matter of modifying the original payload and passing the message on.

So, what would a default value be? True? False? Configurable?

If at all implemented, I think it has to be configurable, and also possible to keep the current behavior.