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.
