Because domains under selectors etc. is singular it means multiple different blueprints to do the same thing.
I.e. the motion_light.yaml only works for actual lights. it doesn’t work for lights that are controlled by a switch. By simply expanding domain to allow an array in addition to the single, you could put in - switch and - light and then the blueprint would be more useful and you wouldn’t need 2 just to do the same thing.
That’s ugly. Should be a drop down on the entity to change it if anything. And it would be easier if the blueprints just allowed it to include both since they work exactly the same functionally.
A switch and a light are totally different apart from turn on/off, you can’t set a color or brightness for a switch, you can’t have a transition to a value for a switch etc.
some lights allow color and brightness, not all. A switch connected to a light is just a dumb light. Thus I should be able to set in the blueprint (i.e. the one based on motion) to turn on the switch just as easily as a light since there is nothing to the blueprint that would require those advanced light features. Thus the developer of the blueprint should be able to pick which things the user can choose.
Hence why having devices support multiple is so important. It dedupes a ton of these blueprints instantly.
There are also other cases which some people get into on this post
This would be really useful. Like right now I’m working on a blueprint for a zigbee remote and would like to limit the domains to light and switch. Only need to use the turn on and turn off. But the only option to include both lights and switches as options currently is to include every entity which is not ideal.
Under a pure entity selector, you can define a filter, then a domain, and provide a list to the domain, but if your selector is a device, with an entity below that, the domain can only be a single domain.