If you look at the device class of the binary sensor ON is always a sort of an UNSAFE situation. If a binary sensor is part of a Binary Sensor Group Helper and becomes unavailable the Binary Sensor Group Helper should be considered as an ON=UNSAFE situation.
At the moment this is considered as a SAFE/OK due to the behavior of “All Entities” in “Group Options”
Present Behavior:
If “all entities” is enabled, the group’s state is on only if all members are on.
If “all entities” is disabled, the group’s state is on if ANY member is ON.
I would like to propose the following minor change:
If “all entities” is enabled, the group’s state is on only if all members are on.
If “all entities” is disabled, the group’s state is off only if ALL member are OFF.
With this change the Binary Sensor Group Helper becomes ON=UNSAFE when the status of all members can not be verified as OFF,
We can most likely solve this in the legacy textual YAML file style with a template binary sensor like a variation of the example in this topic from @pin7of9 but think the way forward is utilising the UI.
True when you expect that all binary_sensors in your group will always have a value “ON” or “OFF”! But we are not living in a perfect sensor world and a sensor can also become “Unknown” or “Unavailable” for various reasons; WiFi, battery, tampering, reloading Template Entities, etc
And we need to decide what to do when an underlying binary sensors become “Unknown” or “Unavailable”. Should this result for the “Binary Sensor Group Helper” in a “SAFE” or “UNSAFE” situation?
For me this is clear: How can you determine it is “SAFE” situation when you do not have knowledge of all binary_sensors? So we need to check that ALL member are OFF.
ALL Off is logically equivalent to ANY On. If nothing is On (Any on), then everything is off.
This has nothing to do with things being unavailable or not. If you want information about the entities being unavailable, you should adjust your phrasing to make more sense in regards to this feature request.
Safe and Unsafe are not concepts in Home Assistant. So none of that jargon really makes any sense here.
The statement “If nothing is On (Any on), then everything is off.” is not always a correct statement however the statement “if everything is off (ALL OFF), then nothing is On” is always a correct statement.
The UNSAFE and SAFE comes from the device class = safety; I used this class in a small sunscreen project where conditions like wind, rain, lux are translated into a binary sensor were ON equals UNSAFE & CLOSE and OFF equals SAFE & OPEN. These binary sensors are grouped into a Binary Sensor Group Helper. This will simplify an automation.
No my thread but I think I have a way to explain it with a few examples:
You have binary sensors named A, B and C respectively and a group with all three.
A
B
C
Group Type
Group Result
on
on
off
ANY ON
on
off
off
off
ANY ON
off
off
UNAVAILABLE
off
ANY ON
off
on
on
off
ALL OFF logic instead of any on but with inverted output
on
off
off
off
ALL OFF logic instead of any on but with inverted output
off
off
UNAVAILABLE
off
ALL OFF logic instead of any on but with inverted output
If you want to incorporate unavailable into groups, the the feature request should be about that. Not about this any on/all off conversation that is going on.
If you incorporated unavailable into groups, the table would look like this for any on and all off…
A
B
C
Group Type
Group Result
on
on
off
ANY ON
on
off
off
off
ANY ON
off
off
unavailable
off
ANY ON
unavailable
on
on
off
ALL OFF
on
off
off
off
ALL OFF
off
off
unavailable
off
ALL OFF
unavailable
and because it’s a binary sensor (meaing 2 states), your only options are on, off, and unavailable/unknown. A 3rd state will not be an option because it does not exist for the binary_sesnor domain/platform.
Imagine having a light group consisting of all lights in the house (a pretty common scenario). Now imagine one of of those lights is a bit flaky (at the very edge of a zigbee mesh or uses an unreliable Tuya cloud connection).
Imagine also a very common scenario where you have an automation which turns all lights off when you leave the house or go to sleep.
Current behaviour: All lights turn off except the one which is unavailable.
Your proposed behaviour: None of the lights turn off.
I’m no expert, but if this FR is implemented, it would cause an uproar as people would have to segment their groups according to integration at the very least. Worst case scenario, it would make groups so unreliable that users would be discouraged from using them.
Neither am I but T&E can already give the answer (tested with the group option - all entities = on):
This proposal will only give better information of the group; if one of the sensors is flaky it will “show” also on your dashboard.
if one sensor is flaky you can still turn the group off and on in a automation (but the toggle option is not available, this is correct because the definition is Toggles one or more lights, from on to off, or, off to on, based on their current state, because the current situation of the group is “unknown” it is clueless what to do)
if the situation your group sensor itself is an extra condition (under “And if (optional)”) and you experience flaky sensors you need to add “unknown” to this condition or improve the situation of this sensor.
you will still be able to toggle this group on your dashboard.
So I dare to say, after some testing, that the statement " Your proposed behaviour: None of the lights turn off." is not correct, it will work (unless you try to toggle in an automation). It will give even more information so you might want to take sooner action on a flaky situation like improve your Zigbee mesh network or avoid Tuya cloud connection (I have working some Tuya products fine under zigbee2mqtt).
This would be a massive breaking change and would likely never make it’s way into core. Especially when you can make a template entity behave this way. Groups are typically rigid and are meant for a general audience, not one-off cases. That’s what templates are for.
Outside that, OP has yet to make the original post clearer, which makes this even less likely for the community to vote for it.
If the group members are either “OFF” or (1 at least) “UNAVALABLE” / “UNKOWN” can we tell for sure that the group sensor should be “OFF” or its class equivalent: closed, locked?
It seem to me when I read the RTFM again and again we realised this is not correct and solutions were already implemented for:
Media player groups: Otherwise, the group state is on if at least one group member is not off, unavailable or unknown.
Sensor groups: If ignore_non_numeric is false then group state will be unavailable if one member is unavailable or does not have a numeric state.
Most likely my FR should have taken this kind of angle, but to be honest I was not expecting to find it under integrations.
Just to be complete: In case you want to include unavailable group members so they will also result in the group sensor status “ON” in stead off “OFF” you need to create the following template sensor in the UI:
Thanks to @123 for her/his original solution, I only added ‘on’ to it.
BTW If you create this template sensor in the UI it is way more flexible (and provide more information) than if done in a file.
@123 you are completely right there are more variables to tweak a template sensor inside a YAML file so I should have said “ease of configuration for NOOBS like me”
Because it is a binary sensor I have no need for additional variables and I wanted to stick to the standard.
Why did I choose for the UI and not an YAML file?
Using the UI gives a lot of advantages for NOOBS like me :
All work can be done directly inside HA
No need to add the template to the “configuration.yaml” (deliberate giving this bad advise, prefer myself to use packages and keep the configuration file lean and mean)
No need to “restart HA” (which is an overkill advise, but often done; “reloading template entities” is sufficient, perhaps not everybody sees this option)
The binary sensor will be directly available.
The underlying information (which sensors are involved) are visible:
To be complete: Yes, there are also disadvantages; with a file you can easier keep a project together, cut and paste, share and not to forget have more variables available for a sensor.
Again, I was very happy I found your solution to my problem because I never would have come up with the syntax to solve it myself.
: