How would you reject a light from a group of entities that the device is not 'light". E.g.
{{ expand ( area_entities ( 'office' ) ) | selectattr ( 'domain' , 'eq' , 'light' ) | map ( attribute = 'entity_id' ) | list }}
Would list all lights in the ‘office’ but it also includes the lights on other devices E.g. the light on the z-wave Smart Power-Switch as well?
Your question confuses me because lights do not have a device_class.
Are you trying to reject some of the entities from a particular integration? If so you can do this:
{{ expand ( area_entities ( 'office' ) )
| selectattr ( 'domain' , 'eq' , 'light' )
| map ( attribute = 'entity_id' )
| reject('in', integration_entities('zwave_js')) | list }}
But otherwise you’re going to have to clarify what you’re trying to reject from the list because device_class doesn’t make sense in this context.
@CentralCommand Sorry, I was just in the middle of trying to rewrite that.
| reject('in', integration_entities('zwave_js'))
would work, but I was hoping for something a little more generic. I.e. I want to list all light {bulbs, LED strips, ect. } where the device primary use is a light, but exclude all other light entity’s e.g. the light entity on other devices I.e. Smart Power-Switch or z-wave extender, ect…
As that solution would not work if I had z-wave light bulbs.
So I am trying to learn more about blueprinting (BTW thanks @EdwardTFN once again for helping with a month ago) So I am thinking about it from a generic point of view. I.e. A “target selector” & the user selects an area.
Ah. That is a tough one. I can’t really give you a solution for that one as there is no easy answer. I can tell you how I would go about it though.
First thing I would look for is a pattern in all the “bad lights”. Particularly with the attributes. Is there anything in there that all the “bad lights” have which the good ones don’t you can use to filter out? Maybe supported_features?
If that doesn’t work then next I’d look in the device registry. You can find this file in /config/.storage/core.device_registry. Look for the “bad lights” in here. For each device you’ll see a bunch of fields. You can access this information in a template using the devices functions, particularly device_attr. Can you find a pattern in here for things the bad lights have that the good lights don’t? Manufacturer or model perhaps?
After that I’m not sure. That’s kind of the end of the metadata you have available in templates. You might need to rely on a naming pattern or customizing with attributes to separate them.
Tell us more about these devices. Post a screenshot from the Devices view.
I’m familiar with a device that has a switch entity but its prime function is media_player (the switch appears in the Configuration section of the Device view).
I’m unfamiliar with a device that has a light entity but it isn’t its prime function. Does it serve as an indicator light of some sort?
I think it’s a cool feature, they are RGB lights & you can treat them as lights, but the primary use of the device isn’t A Light.
For the ZW117 Range Extender, what’s the function of the light switch? Does it turn on/off the Range Extender or do something else?
Go to Developer Tools > States and post a screenshot of that light entity’s information.
nope, it’s just a light. you can set it up so the light changes depending on conditions like “is the switch turned on”. but you can turn it off so it is always off (same for both extender & switch).
What switch are you referring to? I was under the impression this device is exclusively a range extender.
Thanks for the screenshot. If no other entity has a supported_color_modes attribute then that could be used to exclude it from a selection of lights. However, it’s not a generic way of excluding ‘non primary’ lights. What’s needed here is a means of identifying that this entity is part of the device’s Controls. To my knowledge, that distinction isn’t accessible to templates (unless it’s encoded into the number 32 in supported_features).
I was referring to the smart switch. I haven’t played around with the range extender/s other than to turn the light off, but it doesn’t turn the range extender off (just the light).
… and no, the value of the supported_features attribute doesn’t indicate if the light is a ‘non primary’ part of the device. It simply represents the light’s capabilities.
