I created a new binary sensor group helper, Dummy Occupied, using the UI and end up with a binary_sensor.dummy_occupied. I try to use a script to update that group and end up with a new group, group.dummy_occupied, as well as the existing group, binary_sensor.dummy_occupied.
To make matters worse, the group.dummy_occupied is un-managed. I can’t modify it or delete it in the UI and it doesn’t exist in YAML. The only way I have found to actually remove it is to stop Home Assistant and edit core.entity_registry.
Here is the Dummy Occupied group using Developer Tools States after creating it.
Here is the action I used to set the members. I could have added name and icon. According to Group Integration, I need to have an object_id. Based on my testing, I can’t specify the domain and it defaults to group. The UI uses the binary_sensor domain.
You can’t. Those actions only work with old style groups.
Possibly there is a third-party integration that can do it. Or maybe it is possible using PyScript, or something else that can access HASS at a lower level.
Maybe the most Home Assistant approach would be to create an old school group using group.set and then use the UI to create a binary_sensor template that sets its state to the state of the group. This should allow me to have the correct domain, area and labels.
This assumes they don’t drop support for group.set.
Why does it specifically need to be a group at all? Just make a binary sensor template entity, whose state is based on a variation of the same template you are attempting to use to create a group. Simple.
May or may not also want to check out this very similar thread about creating light groups through scripts/automation, which of course also isn’t possible but has some other suggested workarounds.
That is a fair question but since my template would be based on a domain for the trigger instead of a finite list of entities, I figure it would be regenerated a lot more often even if it does need to be. While this may not be an issue for a single template it becomes more of an issue when it is a pattern repeated often.
That sounds like a Template binary sensor Helper that observes other binary sensors… where does the group come into play?
Alternatively, you may want to check out Spooks label management actions. With them, Labels can now cover most, if not all, of the situations that used to be the purview of groups.
The group defines the list of relevant entities that is dynamically derived. I could use the old group directly but I don’t have a way to add area, labels or device class to it. I can add name and icon to the old group though.
Things get more complicated with sensor groups since you can perform aggregate functions on the states with new groups but not old groups. Hiding the old sensor group behind a template allows me to apply some aggregate functionality to the old group.
I think I am heading down the correct path for a repeatable pattern but @Mayhem_SWE brings up a very relevant question about should I. Sometimes you need to pick your head up and make sure what you are doing makes sense. I did start down the pure template route and wasn’t sure how well that scales. Especially when you are using these groups on mobile dashboards and they are being “updated” frequently because they are responding to too many state change events. Even events that don’t impact the current state of the template.
I did a little experimenting with Python Script and was able to update the new group with hass.states.set(entityId, state, attributes) but this didn’t really modify the member list of the new group.
Before I ran the Python Script, I could see the entity_id attribute had a list of existing members.
After I ran the Python Script, I could see the entity_id attribute had a list of new members. Thing looked promising.
Changing the state of one of the new members didn’t change the state of the group.
Changing the state of one of the old members did change the state of the group and reset the entity_id attribute.
It appears the list of members for a new group are store separately and the entity_id attribute is not the true list of members.
An interesting note though, the Jinja2 function expanddid use the entity_id attribute.
All that does is artificially change the state/attribute, primarily so that you can test things like automation triggers and such. It doesn’t actually modify anything, and the next time a “real” state update is sent from wherever the artificial value will be overwritten.
The group.set and a template to wrap the old group did work but I decided not to use it.
I like the idea of using defined groups with a limited number of events that can change its state versus templates that refresh any time there is a domain event.
This just feels more scalable since each area needs a group for motion detectors, light detectors and switches/lights. With multiple bedrooms, bathrooms, outdoor areas, and other rooms, the number of groups and templates grows fast.
Each of these becomes a point of failure for automations. I do like clever solutions but I like my automations to work reliably even more. Keeping it simple and reliable is more important. Walking into a dark room and running through a list of possibilities as to why the lights didn’t come on gets old really fast.
I have decided to use manually maintained new groups since the reality is how often do we change the devices in any area.
