AND function NODE-RED

I want to create a flow where my underfloor heating pump turns off when all supplies are closed. So, I want, if 9 entities are “false”, that a signal comes in which I can use to turn off the pump. It is important that all 9 entities are also “False” and not that this adds up. So suppose 8 of them are False and one of them goes to True, then this one must drop out.

It seems something simple but I can’t figure it out.

I’m not sure about the last thing with ‘drop out’. otherwise it is easy :wink:

first node reacts on change of all your 9 entities. Likely Event node with regexp matching against entity name.

it will trigger GetEntities node, configured to mach all entities being subject of interest, with condition against their state. This node can work in count mode giving number of collected entities to its output. you can use this result (number) to make further decision

@maxym Thanks for the reply!

It’s still hard to understand what you meant, that’s just me :-). Could you make a flow for clarification?
Now I have it as below but then it is triggered with every “true” of the every singel entity

I cannot see GetEntities node on your screenshot. though it’s good start.

I’ll paste example from my NR once I get to PC

Can be done in one node:

Use Events: state node, with regex to match your entities by id, such as the following that matches switch.t_1 and switch.t_2 etc.

switch\.t\d_\d

Use JSONata in the If condition test:

"on" in $entities().*[$contains(entity_id, /switch.t\d_\d/)].state[$="on"]

This will look at all entities where the id contains a regex to match your entities, filter these entity states for ''True" and offer an array with just the “True” states.

If “True” in [array] this will return true, otherwise false, hence you can use the lower exit which will output only when there are no entities with state “True”

As an added bonus, you can also use JSONata in an output property:

$count($entities().*[$contains(entity_id, /switch.t\d_\d/)].state[$="on"])

which will provide a count of the entities that are “True” (ie the number of values that are ‘on’).

Just change the state values and the regex to match your entities.

There are other ways of doing this of course…

You can also create a group inside home assistant. Add all the supply entities to a group. This will create a new entity. If any entity in the supply group is on, the group entity is on. All entities must be off for the group entity to switch off.

2 Likes

All suggestions above might be good depending on exact usecase and other needs. The one with the HA group seems to be the cleanest one. However is limited to All-sensors-are-ON - Any-sensor-is-off situations. It might fits your need though.

Here is example of using GetEntities node.
It counts persons in Home area, being triggered by state change of any registered person, as well as HA/NR start. IMO it cannot be achieved with person group.
Obviously the lattest condition check can be anything.

You can import the json below into your NR to look into config of particular nodes.

[{"id":"affb329d.8fa8f","type":"switch","z":"bcb4b1c6.803708","name":"zero or more","property":"payload","propertyType":"msg","rules":[{"t":"gt","v":"0","vt":"str"},{"t":"eq","v":"0","vt":"num"}],"checkall":"true","repair":false,"outputs":2,"x":710,"y":220,"wires":[["ee603327.68635","03b1c4e8d2afc79d","1925901bf1f7ce40"],["fcfa14ef.2feb28","03b1c4e8d2afc79d","1925901bf1f7ce40"]]},{"id":"d46b853a.df0c78","type":"server-state-changed","z":"bcb4b1c6.803708","name":"Some person state changed","server":"6cdd0bc8.b8e434","version":5,"outputs":1,"exposeAsEntityConfig":"","entityId":"person\\.*","entityIdType":"regex","outputInitially":true,"stateType":"str","ifState":"","ifStateType":"str","ifStateOperator":"is","outputOnlyOnStateChange":true,"for":"0","forType":"num","forUnits":"minutes","outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"},{"property":"data","propertyType":"msg","value":"","valueType":"eventData"},{"property":"topic","propertyType":"msg","value":"","valueType":"triggerId"}],"x":200,"y":220,"wires":[["ae0f2f18.6cbb7"]]},{"id":"ae0f2f18.6cbb7","type":"ha-get-entities","z":"bcb4b1c6.803708","name":"How many persons in house","server":"6cdd0bc8.b8e434","version":1,"rules":[{"property":"entity_id","logic":"is","value":"person\\.*","valueType":"re"},{"property":"state","logic":"is","value":"home","valueType":"str"}],"outputType":"count","outputEmptyResults":false,"outputLocationType":"msg","outputLocation":"payload","outputResultsCount":1,"x":480,"y":220,"wires":[["affb329d.8fa8f"]]},{"id":"6cdd0bc8.b8e434","type":"server","name":"HA MaXyM","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":"30","areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"numeric","statusMonth":"2-digit","statusDay":"2-digit","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]```

The method is the same as in HA.
You use triggers and conditions.

The conditions here are a current state node with the “if state” field set, which makes it have 2 outputs.
This method can also be used with entities that have different states or values, because the “if state” field can be adjusted to what that specific entity must be to continue the flow.

You never want to approach the algorithm this way :wink:

Was that aimed at my suggestion?
If so, then please explain why?

Yes. The answer is, that complexity of solution grows in linear maner with number of entry variables. Which is indicator of bad design pattern.

Of course it works and it can be accepted as POC. But that’s all.

You may ask your self:

  1. would you like to continue this way if number entities would be 100?
  2. would you like to modify the flow everytime the number of entities changes?

Answering NO on any of those question means that the solution is suboptimal.

Not mentioning that more nodes is more taxing to the system then less nodes… :wink:

  1. If the entities does not follow a standard, so you can identify them all, then it is not an option otherwise.
    If they follow a strict standard, then you might be able to automate the triggers and conditions population routine, but it will still follow the design.

  2. same as 1.

Use switch node …

A switch node where?

If those are apples and tires, then counting them together doesn’t make sense.
But if you are thinking about names of entities, you can list all of them in regexp (for example)

But yes. if every entity is completely different animal, then your schema is the only way. It’s true.

It is the same method you use, you assume certain criteria for the situation and optimize the method based on that, but I can not see those criteria mentioned by the OP.

He mentioned 9 supplies (I suppose valves or so). So I assume they are homogenously represented in HA (by entity of the same type, and likely with numbered names). There is no indicator that would require treating then one-by-one separatelly.

They might be, but also they might not be.
Many users do not set a naming standard when they first start with HA and those “random” names given at first setup is then just kept.
Many HA setups are truly complex due to this thing happening over and over again for new users.

As mentioned above, naming is not a problem, since you might list names in regular expression like ^(sensor.abc|light.def)$. It’s rather domain, or possible states which decide about possible optimizations.

BTW:

Many HA setups are truly complex due to this thing happening over and over again for new users.

Then, like in software development, things deserve refactoring from time to time.

I agree, but the user might accept the complexity and try to use patchwork solutions instead of using the huge chunk of time needed to refactor it all.