or just use home_assistant.turn_on with the area…
How do you have them implemented, typically you can change what home assistant see’s them as.
This was mentioned up higher in the thread but may have got lost in some of the chatter… if I have an entity not showing up as the ideal domain for other platforms like HomeKit I simply make it a template light or template switch or template fan when I first add the device and quietly ignore the “incorrect one” and use the one that makes it appear properly in the other software… and I never think about it again…
And then that is what I expose to HomeKit/use in automations etc.
I just added the devices through ZHA and Z-Wave JS standard discovery. I was not aware you could do anything else with those integrations. There doesn’t appear to be anywhere in the UI to adjust how they are seen by HA?
@Bartem I get what you’re saying and could setup these virtual devices as you describe. My point is this seems a workaround for something that could easily be improved making everyones life easier. I already feel like I have entity bloat and I am not even half way done with what I plan to to with HA.
In my case I have two relays. A zigbee one by Sonoff and a Z-wave one by Fibaro. Both are just relays with no ability to dim or change colour temperature or anything else. The both just do on/off yet one shows up in HA as a light and the other a switch. I honestly don’t see the issue with changing the type. Sure you could mess things up, but IMO editing yaml files is even more risky for the wider audience HA wants to attract.
1 Like
This wouldn’t be done through discovery, this would be a manual entry depending on how you integrate it into home assistant.
Also, if you read the entire thread, you’ll see the technical limitations described above. The TL:DR is: Home assistant is built around entities and their abilities. These abilities differ based on the domain. The domain and abilities are setup through the integration. This cannot be changed after the fact without adjusting the base entities and changing it would be a logistical nightmare after it’s already set up. If the code doesn’t exist to make the device into a specific domain, then you can’t just simply switch it over.
To put this into perspective, even apple, who has 100x the number of developers don’t have a solution for this in homekit. Yet here you are expecting a much smaller platform, home assistant, to solve the problem. Oddly enough, home assistant solved the problem with template entities and the Light Switch integration.
Yaml is much more robust than the UI at this point in time. Yaml in home assistant is 8 years old. The only risks that come with integrating via yaml are incorrect configurations, which the software warns about. The UI integration process is about 2.5 years old and it’s constantly updating. The developers are slowly but surely converting yaml integrations into the UI. However there are 1900 integrations at this time and in the past 2.5 years, we’ve only converted roughly 300. At the current rate, you won’t see all integrations moved to the UI for 13 years assuming no new integrations are added. Currently, about 1-5 new integrations are added each release. As you can tell, this is already snowballing.
Lastly, the likelihood of utility integrations moving into the UI is extremely low due to the complexity of the configurations. Templates and Light Switch are classified as utility integrations. Personally, I wouldn’t hold your breath for this to change.
You can always create a feature request for this ability as well. Just make sure you vote for it. But keep in mind feature requests aren’t guaranteed to make it into the product.
It is. For as thought-out as HA seems to be in other respects, the light-vs-switch distinction is the original sin that mankind will be paying the price for for eternity, I’m afraid. Whether a switch controls a light or something else is entirely up to the whim of the user (I can plug a lamp into a switched outlet: switch-to-light, or I can screw a 2-prong outlet into a light socket: light-to-switch), and the user shouldn’t have to exclude/include a device or hand-edit config files when they do so. All that should matter to the underlying code is whether the actuator/switch is binary, continuous, multichannel, etc. What the user is controlling with it is up to the user.
The only rationale I’ve heard for keeping them distinct is because a user might want to turn on all of the lights for a room when they walk in, but why do lights get special treatment? What if the user wants to turn on all of the fans? Or all of the water fountains? Or anything else which might be controlled by switches? We already have groups which allow this, which would give even more flexibility. Nowadays, tags are all the rage in UIs, but, functionally, they’re the same thing as groups, so the devs could present them as tags (so we could have automations like turn_on for everything where area=='Den", tags.contains(“light”), tags.contains(“LED”), tags.contains(“freestanding”)).
1 Like
Everything you are saying can be done currently. That’s my problem with this entire thread. Everyone comes here without knowing about features of HA because they found some blueprint that doesn’t work the way they want. The blueprint only accepts lights and not switches. They see the domain as the problem instead of the true problem: The blueprint is poorly written.
homeassisnant.turn_on does exactly what you want it to do. It does not care about domain, it simply turns on your entity. Period.
Yep, that’s what the homeassistant.turn_on service is for.
The rationale behind it has been described by me, multiple times in this thread. It’s done this way for the systems sake, not the user. It’s so HA can manage the entity and know what to do with it. The separated domain service calls light.turn_on and switch.turn_on accept different attributes than each other. This is a way to distinguish between them and provide different attributes to either service. Again, if you are just trying to turn on the device, use the homeassistant.turn_on service which does not care about domain.
You can target areas, and filter said area to only target lights.
service: homeassistant.turn_on
target:
area_id: den
target only den lights
service: light.turn_on
target:
area_id: den
target only den lights that contain LED (there’s about 10 different ways to do this one). Also a little more complicated but you can just copy and past this and change ‘LED’ to anything.
service: light.turn_on
target:
entity_id: >
{{ expand(area_entities('den')) | selectattr('domain','eq','light') | selectattr('name','search','LED') | map(attribute='entity_id') | list }}
target only den lights that contain LED and freestanding (there’s about 10 different ways to do this one)
service: light.turn_on
target:
entity_id: >
{{ expand(area_entities('den')) | selectattr('domain','eq','light') | selectattr('name','search','LED') | selectattr('name','search','freestanding') | map(attribute='entity_id') | list }}
6 Likes
I fully expect this to be in a future HA release as “doh, another thing we’ve fixed to make your life better”. They recently added ability to change entity device class from the UI, so this is right up that alley. If anything, since it would allow Z-Wave JS and HomeKit to play nice without having to hardcode every new light switch you add to your Z-Wave network.
Again for the umpteenth time, this will never change. The foundation of entities is built on classes and you can’t just change the class of an entity. Period.
I don’t agree. There is already a way to change Zigbee devices’ exposed entity domains through the configuration.yaml. So only a matter of time until that’s moved into the UI along with everything else they’ve been moving. In the quest for better usability and less hard coding, I’m certain it’ll happen 
That’s only built into the onboarding process of zigbee. 100% unrelated to the topic at hand, but it’s clear you don’t understand the code so this conversation will go nowhere.
It’s not part of the onboarding, it’s modification after the fact. Thankfully the developers don’t seem too committed to any one architectural structure of the project too much, especially when it stands in the way of usability.
my guy, it’s handled in config flow, that’s the onboarding process.
It’s literally only possible in zigbee, and it’s due to how zigbee as a hardware works. It does not translate to other integrations. I don’t know how else to explain this to you without you looking at the code.
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!
1 Like
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.
1 Like
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.
1 Like
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.
1 Like