I have been adding labels to light entities and then using these labels in automations which works pretty damn well.
If I want to toggle or adjust a group of lights I need to add their entities to a helper group and then add that helper entity to the button/card of the dashboard.
It would be awesome if we could use labels in cards when creating dashboards.
Thanks Team, awesome work.
Regards Brad.
Can you clarify your issue?
When I add a button to a dashboard, I am able to turn on lights based on their label without any helpers:
Hey @potelux,
Thanks for the reply, I can see how we could do this with a button card and other cards using the “Tap behaviour”.
If I want to use the Tile card that also allows adjusting brightness/colour I could use the “Tap behaviour” also to add the label, but the tile card needs an entity associated with it.
Using the “Tap behaviour” would only allow the brightness/colour to be preset and not adjustable.
Hope that clarifies, or perhaps I have missed something.
Thanks again 
.
I can’t imagine how this could work the way you want. Labels can be added to anything, not just lights.
What should the tile card with your requested feature do if you would use a label in it that has some lights, a fan, an air quality sensor and a couple automations?
You are trying to make the labels work like groups, but we already have groups. If you just want to group lights, use groups, not labels. Groups are less flexible, but they work like entities, they have a state and so on.
Labels have no state nor other entity specific behavior, this can never work.
What you probably actually want is the ability to make a light group out of lights with a certain label. You should make that as your WTH.
I don’t understand what the problem is. This same argument could be used for the label target on the button card. I can select completely wrong targets there. So what? Who cares if you get an error if you select targets that cannot be reached with the selected action? The user will understand that that gives an error, and as long as a popup or the log file gives a decent clue what went wrong it’s easy to fix. No reason to leave out this functionality if you ask me.
- action: group.set
data:
object_id: outside_lights
entities: >
{{ states.light
| selectattr('entity_id', 'in', label_entities('Outside'))
| map(attribute='entity_id') | list | sort }}
The target selector filters the available entities already.
What I’m saying is not that a user would select incorrect entities through labels. There are no incorrect entities for a tile card. But how the card looks, what features it has depends on what entity it has. How should it know that you only mean to use light entities if you tell it to use a label that has multiple types of entities?
Labels are nice because they are so very flexible. But also because of that they cannot replace the functionality of everything else that structures things in HA.
Mm, yeah, the card itself is a bit of a problem… And something like the mushroom number card only works on entities too.
I guess the solution would be either a light group, or a slider card on an input number helper and an automation with a light :turn on action, the label targetaand the input helper as data and trigger. Group seems the logical way.
Thanks. I learned something from this.
Thanks for the contributions!
If we take the Tile card as an example, which requires an entity to determine its features, I assume this is based on the “domain” (such as light, switch, fan, etc.). A potential solution could be to include a domain selection option. This way, users could add relevant labels specific to the selected domain, which would then apply the appropriate features of the card.
Currently, it seems a bit inefficient that you need to apply labels to a group of lights for use in an automation, but then create a separate group of the same lights (or any other domain, with lights being just an example) for use in a dashboard card. This feels like unnecessary double handling.
Cheers
This doesn’t create a light group, it creates an old style group.
Understood, but you can still use it to control a group of lights. Just thought it was a relevant technique I could share that might help.
If all you want is to turn the lights on and off, then yours is a useful workaround.
If on the other hand, you want to change the brightness as well, then it is not enough, and we need a proper label-defined light group, like I proposed.
Have you actually tried my suggestion? Because it works. Brightness, colors, the whole shebang.
Here is the more-info dialogue opened from a tile card using an old style group of lights.
I’ve just tried it and indeed it works.
The reason I thought it doesn’t, is because the last time I tried it, I had entities from different domains in the group and then it doesn’t show like that. They need to be all the same entity type, interesting.
You don’t need labels to use lights in automation. If you want to control the lights as a group, just create the group. You can steer the group through the automation as well.
Thanks to everyone who has contributed to the discussion! I appreciate all the input, and there’s no disagreement with any of the points made—there are some great suggestions here.
Perhaps my initial WTH could use some clarification. After all, the purpose of WTH is to gather ideas that can improve the user experience of Home Assistant.
Yes, it is possible to create helper groups and add those as entities to automations, dashboards, etc. However, if we want to group entities in this way, what’s the point of using labels? We might as well just stick to using groups.
To illustrate this, let’s consider the example of lights. Suppose we want to group eight lights in a kitchen and then group another four lights above the kitchen island. That’s two helper groups to create, and possibly a third group if we want a general “all kitchen lights” group. After creating the groups, we would add the individual light entities to those groups, and then add the helper entities to our dashboard or automations.
If we want to track how many lights are on, we would also need to exclude the helper groups we created since these groups now count as light entities themselves.
Labels, on the other hand, provide a simpler, more efficient way to handle this. The bulk addition of labels to entities is much more streamlined than creating multiple helper groups and adding entities individually, as shown in the example above.
It would make more sense to have a card where you can select a domain (so that the card displays relevant features for that domain) and be able to control labels—or the entities associated with them—based on the domain selected.
When adding labels to entities, we should ensure that we don’t add the same label across different domains. For example, you wouldn’t use the same label for a fan and a light or a switch, since you can’t adjust the brightness of a fan or a switch, and similarly, you wouldn’t change the speed of a light or switch.
In the Tile card example below, I’ve added a light group helper as the entity (“Lights Entry Door”). I changed the appearance to display “Entry Door,” adjusted the default tap behavior, set the icon tap behavior, and added the light brightness feature. This setup allows me to control everything I need directly from the dashboard—no need to tap for more info to toggle the light or adjust brightness, and I don’t care about changing the color.
When adding the Tile card to a dashboard, if there were an option to select a domain and then add the corresponding label for action, this would be a much more efficient process overall.
Thanks again, and I hope this helps clarify things a bit further. A big thank you to everyone who contributes to this amazing project—both community members and the Home Assistant team! Wishing you all the best for the New Year!
I still think you are missing the point a bit. It’s not just that. Groups have some specific features built it. A group has a state. Label do not have a state. For example, a group can have a state of turned on if all is entities are on, and off if at least one of its entities is off. But it can alternatively be set to be on only when all entities are on and off if at least one entity is off. Other attributes, such as light brightness, is an average of all entities.
It may seem simple that a card would treat a label like a group, but what your demands is that HA in the background creates that group for you on the fly, but makes it not manageable by you and makes it invisible for anything else but the card. But maybe you then would want to use it in automations like the group (for example in triggers)?
If creating a group is in your opinion to difficult and you can see some improvement the, create a WTH for that. I really don’t think it makes sense to copy a group feature characteristics to labels just because the bulk adding labels has better interface.
The whole point of labels is that their are flexible and can be added to anything. So you would just change labels to be groups.
Thinking about it a bit more, maybe you would like a WTH with an idea to make it possible to bulk add entities to a group by using labels (I would even make it use the target selector UI, with its ability to add individual entities, areas, devices and labels).
