I think the OP wants to know how to easily change entities into other domains.
1 Like
Yes and he already provided a solution for switch -> light himself. Otherwise it doesn’t make sense to change the domain of an entity.
1 Like
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.
5 Likes
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.
4 Likes
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…
2 Likes
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.
2 Likes
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…
1 Like
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.
2 Likes
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).
1 Like
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.
1 Like
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…
1 Like
The reason lights and switches are separated has nothing to do with the states they support. There are lots of lights that only support off and on, then there are some that support tunable color temperature, others that support full RGB and yet others have additional effects, they’re still all lights. Obviously if you try to tell a plain white light to change to warm white or a tunable CCT light to change to green that’s not going to work but these less capable lights are still lights, we don’t have separate domains for all of these different kinds of lights despite their varying capabilities and a light plugged into a switch is also a light.
The reason for separating lights and switches is purely organizational. A switch can be a light, but a switch can also be any number of other things and there are many times when it makes sense to apply an action indiscriminately to lights, it is not uncommon to want to turn on or off all the lights in a room, but rare that you want to indiscriminately turn on or off all electrical devices in a room. The reason for separating them is not in question, only the difficulty of designating a switch as a light, or maybe you even want to designate a light as a switch, who knows. If I were designing things from scratch I don’t think I would use separate domains for lights and switches, I would just include a flag so that entities could be tagged as lights from an organizational standpoint and respond to light-specific commands but I’m not designing from scratch so this is moot.
Yes, technically it is not “hard” to add some lines to the configuration yaml to designate a switch as a light switch but that is IMHO a messy hack. It is not easily discoverable, and it results in an unnecessary duplicate entity that adds clutter. This is going outside and grabbing a rock to hold the door shut because nobody bothered to fit a latch connected to a doorknob like some of the other doors have. It could be argued that the house didn’t cost you anything so you can’t complain about the user experience or the need to get creative to find a solution, and “is it really that hard to just go outside and get a rock from the garden?” but that’s not really the point. Blaming the writers of a blueprint rather than acknowledging a flaw in the system is Apple telling users “You’re holding it wrong” when they complained of problems with the iPhone. This is especially silly when this is something I encountered in one of the two default blueprints that come with the system, one could reasonably expect those to be examples of well designed example and not “flawed” blueprints. All things have flaws, that doesn’t mean they lack value and doesn’t have to be taken as negative criticism, it is just room for improvement.
Anyway I’m a relatively new user and I started this thread to bring to light a significant pain point that I have encountered on numerous occasions so far and I believe that many other users are going to hit this same pain point. I did manage to stumble across a couple different workarounds but I’m also professionally a QA engineer/SDET with a background in EE, so not a full fledged software engineer but probably more on the technical side than the average person who says “this cloud stuff sucks” and comes here looking for an alternative. I think HA is very close to being viable for a large group of people who are less technical than engineers but not so non-technical that they need the Apple approach where everything is done for them Apple’s way and they are not allowed to tweak anything even if they want to.
If the argument for basic functionality is “you can just put xyz in the whatever.yaml, this is not a flaw, stop whining and learn to code or go buy Apple/Hue/WeMo/whatever” then it could be argued that there is no need to have a UI at all. The fact that the UI cannot yet do everything that it should be able to do does not speak badly of the UI or of the of the project as a whole, it is simply room for improvement. My argument here is that having a trivial, easily discoverable way of designating a switch as a light, ideally without creating a duplicate entity is a valuable improvement that would ease a significant pain point that almost all users are going to encounter sooner or later. Each of those users is going to have to do as I did and spend time searching for a workaround and/or adding noise to the forums asking how.
5 Likes
Home assistant is built off service calls. Service cals have different attributes. If you feed incorrect attributes to service calls, the system will error. This is the fundamental difference between lights and switches. There are service calls that can handle both lights and switches. The blueprint owner chose not to use that. The blueprint is flawed. Complaining to random people here instead of the blueprint owner is just going to result in people ignoring you.
Ehm… sorry I think there is no complaining going on here?
Just a fundamental discussion about the difference between a light. and a switch. domain and the attached “things” to it.
I dare to bet that 70-90% of all people that use home assistant have a “light” attached to a switch. Hence I think the OP (and me) have a fair point of the ask to “easily” change a switch into a light?!
All arguments:
- there is a yaml way
- It’s a fundamental service call thing
- it’s a blueprint thing
I think those effectively are substitutes of the real ask and also in my opinion “problem” of the simple ask “why can’t I just easily in UI change a switch into a light…?”
1 Like
It’ll always create a new entity because the entire system is built around supported_features and domain. But someone just needs to add UI configuration for light switch integration and you’ll have your wish.