well this thread was an interesting read LOL
so it sounds like when ya pair a multi-relay board via zigbee - it just picks switch, or light, and there’s not much ya can do about that, except ‘redirecting’ things after the fact with YAML
this is a statement - not a question
(i dont wanna have someone respond with “like i said 1,000,000 times already”)
im just gonna walk away from home assistant if this thread is any indication of how things work around here
have fun with all this everyone!
Yeah I think after trying to answer a lot of questions every day, it’s easy to develop tunnel vision of “how things work” and even rationalize it as “this is how it should work” when it’s in fact nonsensical to a fresh observer. I see it pretty often on old threads: someone asks something very logical that cuts deep into one of HA’s shortcomings, a regular responds with “No, this is fine and makes sense”, and then later, HA releases an update that says “We fixed this nonsense”. Luckily the project main devs seem to consciously go out of their way to avoid this kind of burnout tunnel vision, which is inevitable even when you’re genuinely trying to be helpful.
It’s not tunnel vision. It’s literally how the WHOLE backend is designed. I don’t know how else to explain this to you. Maybe in the future for specific integrations, there will be a way to ‘transform them’. But it’s not something that will happen over night and its certianly not going to be a simple thing that will apply everywhere.
Python and classes inherit from a base class, these classes are RIGID. You cannot just change a base class on the fly. It’s not possible. It HAS to be deleted and recreated and functionality has to be “linked” from one base class type to another. Home assistant has none of this built into it. This is why you have integrations that create new entities on top of existing ones.
This is why we have template entities. The sole purpose of template entities is so that you the user can link functionality of one entity into the functionality of another. You see how complicated templates are right? Now imagine trying to do that automatically without breaking functionality. It’s near impossible.
I know I sound like a broken record and I know the information I’m delivering is not favorable, but it’s the truth. What is being asked here is so far out of reach that you should take matters into your own hands and use the tools that exist right now. Otherwise sitting here discussing “how easy it is”, when it’s not easy is insanity.
Funny Alexa allows you to do it even to HA entities exposed to it without too much trouble 
I of course am giving you a hard time on top of everything else stated on here. I came here looking for a simple way to integrate 2 light switches into a group or a light group so I can have both banks of my garage lights turn on and off together. What I came out with is the endless debate of this should be easy and it’s impossible which is typical end user and dev back and forth.
It’s doable. The main argument in this thread is “I want to change it without making a new entity”. Which is not possible. You can simply make a light entity that references the switch with the light switch integration. Then make a light group, or just make a group with your switches and use homeassitant.turn_on service. This is what is infuriating about this thread. People don’t want to fix their problems, they just want to complain. Either way, this setup will get you what you desire. You’ll end up with 3 lights: light.switch_to_light_1, light.switch_to_light_2, and light.my_grouped_lights.
light:
- platform: switch
name: Switch to Light 1
entity_id: switch.my_switch_that_i_want_to_be_a_light_1
- platform: switch
name: Switch to Light 2
entity_id: switch.my_switch_that_i_want_to_be_a_light_2
- platform: group
name: My Grouped Lights
entities:
- light.switch_to_light_1
- light.switch_to_light_2
Of course, you don’t need to do this if you just want to turn the switches on or off. You can simply create a group and use homeassistant.turn_on. Going this route will net you a single entity, group.my_grouped_lights.
group:
my_grouped_lights:
name: My Grouped Lights
entities:
- switch.my_switch_that_i_want_to_be_a_light_1
- switch.my_switch_that_i_want_to_be_a_light_2
OK, I am going to try to get across what I believe the first poster was trying to say.
Of course we can use the code you mentioned to convert a switch to a light
- platform: switch
name: Switch to Light 1
entity_id: switch.my_switch_that_i_want_to_be_a_light_1
The issue the poster was trying to make is about ease of use.
This yaml entry requires opening an editor and manually adding three lines in the yaml file.
Not a big deal I know, buy can be very time consuming if you have lots of lights connected to on/off switches. (As I do)
What I think was being requested is a change to the ui to allow a check box that would automatically generate the yaml entry.
This would save a LOT of time setting up lights connected to switches.
Yes, I agree. Unfortunately config flow isn’t ready for that but I believe changes are being made to support something like that. Something like that is definitely within the realm of possibility and I wouldn’t be surprised if we see it within the next year. However, understand that it will not replace the current entity, it will be a new entity that references the other entity.
for sure.
Just another step along the road to help the onboarding of new users…
Adding Tuya light switches today via the Tuya Integration and noticed something interesting, the single gang dimable Delta switches default to a light, and the non dimable 2,3 and 4 gang Delta light switch’s all come up as switches.
This threat helped make sense of why, but also raises that an easier way is needed to change between the two to avoid having to manually configure each one.
For now mine might stay as switch’s until I can be bothered to manually use the light template or some yaml code for each one.
As of 2022.4, Switch as X is now available in the UI, you no longer need the yaml configuration listed here.
Keep in mind that this follows the paradigm that I’ve been stressing in this thread. It does not replace your existing switch with a light. It creates a light and hides the switch. Both entities are available for use, but the switch is hidden using the new hidden option introduced in 2022.4.
So, for my full understanding. This switch as X will make a new entity starting with e.g. light. And hide the exisitng switch. Entity? Thus all logics will have to change after that?
If you read the details on ‘hidden’, you’ll see that hidden entities are only hidden from the auto generated dashboards. The entities still exist and can still be used anywhere in HA.
It’s a nice to have. But it sure sounds like a mess in the making. I’d prefer to just use the generic home assistant turn on. The “hide” feature is kinda useful and I think it’ll also hide it from other integrations like Google home without having to explicitly hide it.
Wow, that Switch as X integration is a godsend! Since I started using home-assistant a year ago, half my light switches show up as lights and half show up as switches. (They are imported via the ISY integration with Insteon hardware.) I eventually figured out the difference - Insteon dimmer switches presented as lights while Insteon on/off switches presented as switches. While I recognize they are different, that my hallway lights were a different thing from the office lights just smacked of a broken abstraction somewhere. (Yes, I read all the technical “but they’re different underneath” arguments, but as a new user, that this light and that light are not both lights, but this light and that outlet are both switches just did not match what was sitting there in front of me. Lights and Outlets are different, and yet, the difference in HA split lights in half and grouped half with the outlets. It was infuriating.)
I added the Switch as X integration and now there’s a lovely little dropdown right there in the device “Oh, this is a switch? Do you want it to be a light? Cool, here you go!”
Thank you.
But I have a lot of SONOFF switchs with 3 buttons, like switch.100139cc73_1, switch.100139cc73_2, switch.100139cc73_3 for instance, to use Switch As X I have to convert each one of them one by one. How to make all of them turn to light at once? It doesnt allow something like switch.100139cc73_*, is it possible?
Sorry, you have to do them one by one.
You might be able to make them a group using the Helpers.
Hi, I only came on board with HA two weeks ago, so didn’t know the times before Switch as X, but first thing I did is classify my Tuya switches as lights. Worked happily for a week or so, but now the lights have become unavailable. They disappeared from the Entities list, completely gone.
Funnily enough the switches are still there, working, but I am only exposing the lights to the dashboard.
I am using HomeKit as Frontend as well, and I wonder if it might be crosstalk with HomeKit in some way although I believe that hidden entities, ie the switches, don’t get exposed to HomeKit.
The following post seems also interesting and related to that topic:
https://community.home-assistant.io/t/request-to-add-yaml-option-to-manually-configure-helper-change-device-type-of-a-switch/410412/2
light:
- platform: switch
name: LED Table
entity_id: switch.led_table
Will that principle of defining in the yaml configuration be documented and official at some time or rather becomes obsolete?
It’s a helper entity so yaml shouldn’t go away. That doesn’t mean it won’t. Historically, helpers are available in yaml and ui.