In my Home Assistant adventures so far one of the most annoying things I have run into on multiple occasions is the different handling of light entities vs switch entities. The vast majority of my switch entities are in fact controlling lights so it frustrates me when I find blueprints or other things that only work with one or the other. Why is this? Also why can’t I just change the domain from one or the other in the UI? Is this some low level architectural limitation? I get the desire to differentiate between a light and a switch so you can for example turn on all the lights in the room without turning on the fan and the kettle but it is a mystery to me why I can’t just select from a dropdown or check a box that this switch is a light, or why a blueprint that works for one couldn’t work for the other since both lights and switches support the “on” and “off” methods. I’m aware of the “light switch” I can put in the configuration.yaml but that seems like a kludge, instead I’ve been using the option in Tasmota to report a switch as a light. I would have thought that the vast majority of things most people would control with HA are lights. Am I just looking at this the wrong way?
That’s exactly what the light switch you talked about is made for, to use switches with the light domain.
The reason that blueprints don’t work with both is that the author of the blueprints uses services that are only available to lights and the selectors they implement let you only choose lights. They could be rewritten to also be able to use switches, but that would only make sense for on/off lights and you can just convert the switch to a light which is way easier.
No it doesn’t. Read the post above yours.
I think the OP wants to know how to easily change entities into other domains.
Yes and he already provided a solution for switch -> light himself. Otherwise it doesn’t make sense to change the domain of an entity.
That’s the thing, the lightswitch thing works but it feels like a kludge, requires hard coding something in the configuration yaml and results in a duplicate entity that is unnecessary. Would it be difficult to have a checkbox or dropdown in the UI where you edit a device? You can change the icon for example, why not select whether a switch is a light or a switch? Or just allow the user to change the domain where it lets you type the name of the entity ID. We’ve got this really nice clean UI and there’s still so much basic stuff that can’t be done through the UI and it’s inconsistent what can and can’t be done that way. I’m often not sure whether something has not been implemented yet, or is not reasonably feasible to implement or if I’m just taking the wrong approach all together toward whatever I’m trying to accomplish.
There are already multiple kinds of lights, some only support on and off, some are dimmable, some are tuneable CCT and some are full RGB, these are all by default “lights” and it would be great if a switch could be designated as a light more directly. Fortunately Tasmota allows this so there’s a solution for devices that are supported by Tasmota.
Nooo, please not. Then it will get even harder to help people here in the forum, because now you couldn’t even be sure if the climate.xxx entity they are talking about is really a climate entity or it’s actually a temperature sensor that the user renamed to a climate entity.
The switch → light is the only example where changing the domain makes sense and for that they provide the light switch.
The domain is not just a string in the beginning of an entity_id, there are services tied to it and other things going on in the background.
Agree, but it should indeed be more simple to change from switch to light! Because most integration by default present switches and it is a pain in the A to keep track…
Always “checking” nodered domains if switch or light is correctly selected… and if not it doesn’t work…
It is pretty simple:
light:
- platform: switch
name: Christmas Tree Lights
entity_id: switch.christmas_tree_lights
One could make this configurable in the UI, but I think the devs have more important things on their plate, but feel free to open an issue on GitHub.
That’s more an issue of the integration then, I don’t have any switch.xxx entities that are actually lights.
I know it is simple. But it is not a matter of simplicity but of complexity if you have about 100 switch entities to manually build a yaml and maintain, keep track, etc…
What integration presents lights as switches?
Why this question?
Switches are switches untill YOU decide it’s light by connecting a light or lamp to it… thus the question should be:
What integration presents you a light …
To name 2. ESPhome, openzwave.
An yes via additional measures it can be changed.
The reason lights and switches are separated is the same reason every home automation software separates lights from switches. Switches only have an on/off state, lights have a brightness levels, transitions, effects and much much more. Think of lights as dimmers or color dimmers. This is standard across all home automation software.
If the blueprints don’t support lights and switches, then the blueprint itself is flawed. Request that the blueprint provider makes that change or make the change yourself.
Outside of that, the easiest solution to using flawed blueprints is to do what @Burningstone mentioned.
The question because I’ve never seen a light presented as a switch.
A switch with a lamp plugged into it is still a switch, which is probably where you’re getting confused.
I’m not confused. This is about semantics. The main topic in this topic is a switch with a lamp or light connected to it should be able to “easily” converted from a switch to a light domain. (With at least on/off).
You don’t need to convert a switch to a light in most circumstances. You can turn the switch on and off with an automation just as easily as turning on a light.
For the circumstances where you do need to (such as grouping a lamp that is plugged into a switch into a light group) there is the light switch platform, which is just as easy as creating the light group.
There will probably be a UI to do it eventually, but it’s not exactly hard to do in yaml currently.
I never said it was hard. I said it could get complex when having 100 entities which are lights and are connected to switches. It should become more easy to change instead of yamling all entities.
Do you want me to say you are right or 
?
Not at all, I’m just trying to understand where you’re coming from.
If you have 100 switches, it’s still just as easy to turn them on and off as it would be if they were in the light domain, they can be grouped with normal groups (light groups wouldn’t be required as there’s no colour or brightness), and there just doesn’t seem to be a reason for all 100 to be turned into lights.
If say 3 of them did need to be light domain for some reason, then all I’m saying is that it’s not that complicated.
I agree that if you did have to do all 100 it would be a PITA, but I can’t see why that would ever be the case.
1 simple reason… use the “light” domain to really check what lights are on or off in node-red…