Why the hack do I need to create light groups for my floors and areas manually and need to maintain them if I add or remove lights?
Now thatās a good idea.
If it was possible to use a template under the entities option, that would bring you pretty close.
What is it you want to use the group for that cannot be done by targeting a service at the area?
One issue is that there are a few integrations that put things in the light domain that users might not want to be controlled/monitored with their other lighting. These include things like display screens and indicator lights. There is a similar (though more prevalent) issue in the switch domain for ārestartā, ādo not disturbā, and other virtual switches. And there is a similar issue involving the Area cards and temperature and humidity sensorsā¦ an Area card of my kitchen says it is 7Ā°C because it averages the air temp, the fridge, and the freezerā¦ and thereās no way to opt sensors out except to move them to a different Area.
Personally, I prefer the current āopt-inā setup over having the system automatically create a group that I then have to manually opt entities out of. Itās possible that having something like device classes in these two domains could help, but you can do a lot with a few templates to combine entities based on Area and/or Labels.
1 Like
Actually nobody will be forced to use these automatically created light groups and define its own?
A toggle on the light group switches off all lights if at least on is switched on! With a service you toggle all lights and that is what you mostly donāt want!
1 Like
Thereās a group setting to invert that behaviour, but you need to choose: Either the groupās state is on if at least one light is on (in which case itās off only if all are off), or if all lights are on (in which case the group is off when at least one is off).
No thanks, I donāt want to have several extra light groups created automatically.
I get your point, using light groups is nice for toggling and other use cases, but setting them up manually is not that hard. And for example now during Christmas I enjoy the fact that my Christmas tree lamps are not in the group of lights in my living room, as I do not want them to be controlled together.
You can already target areas in automations as the target of a ālight turn onā action. But not floors, for no reason that is immediately apparent to me (except just the fact nobody has implemented it yet). And you also cannot use such targets for front end elements like buttons or light cards.
So rather than automatically add light groups, I would argue for increasing the usability of targets.
2 Likes
@Didgeridrew thatās true, one might need an way to opt out certain secondary lights that should not be part of that group. There is at least the option to opt out by not adding the device to the area. But even in case you have other reasons to put it in the area and have no other opt out (yet), no one is forced to use this group, if it disturbs other things?! If you run a setup without such lights it would be just an improvement that you can use.
The Magic Areas integration does this exactly.
Thanks @panoptican, seems to do the job.
agreed, but unfortunately HAās native Groups are 99% useless. If native Groups had these features no one would need to make hacks/workarounds for different types of groupsā¦
While I donāt begrudge you your desire for updates to Groups, I just donāt see templating as a hack or workaroundā¦ itās a powerful tool that is invaluable to achieve the custom, flexible, and efficient automations and āadministrationsā that many HA users want.
2 Likes
All the features I proposed are needed to make Groups valuable all need serious coding skills to make happen - way beyond a simple template to expanding the Groups. All the features should all be built-into the UI anyway.
- trigger on what value just changed (not just if the group is on/off) ā¦ hard
- trigger on if two or more values are on/off/#/etcā¦ hard
- groups based on rules, labels, etcā¦ impossible
- etc, etc
ā¦ Groups are totally not needed IF they had built out the functionality for Labels - but they didnt.
and Notification Groups are another outlier.
Templates should be the exception, not the ruleā¦ but in HA, 90% of anything beyond basic stuff requires templates. Add to that dashboards requiring a combination of YAML, CSS, HTML, Markdown, and JINJAā¦ so, master 5 ālanguagesā even to do even some pretty basic stuff like formatting the text of a card or changing an icon.
My point isā¦ there are a lot of very basic, simple things in HA that require a ton of work or complex coding to make happenā¦ and the learning curve is very high due to the sheer amount of difference/exceptions/outliers in darn near every facet of HA : notifications, templates, dashboards, etc ,etcā¦ nothing is unified or standardized.