WTH! 😤 Howto: reference A Device/Area's state (On/Off/unavailable) with A "Target Selector"?

What? How so. You can get all that information from the entity_id…. You don’t need devices for any of that.

You know so much more than I about all of this stuff, but unless I have something fundamentally wrong, A target selector gives the user 3 options, “Area”, “Entity” & “Device”.

The idea behind that is to apply settings to all effected entities/devices. Not a single entity within a device. If you’re trying to filter to a single entity, your logic is flawed.

Why would it be flawed? I would think that if the user chooses the device option, they would be selecting A device that is a light? I realise that some devices may have multiple light entities (&or entities that are not A light) but 9/10 they would be selecting A bulb, (& mainly I just want the one selector to select either A “Area” or A “Entity” but needed to deal with the device option).

Sorry for my ignorance, but I have only been looking at this stuff for about 2 months now. But I very much appreciate you sharing your knowledge with me.

If you can show me a better way of doing this (target at either an area &or A entity), or A better way of how to deal with the device option I would very much appreciate it?

You aren’t sharing your endgoal. You’re asking a question that’s narrow sighted and expecting an answer for it. An area and a device can have more than 1 entity associated with it. The target selector can select multiples of everything. That means you should be tailoring your templates and actions to support more than 1 entity. Otherwise, use a different selector.

How would you suggest that I say that? I thought I did by saying:

I know I am the one wrong here, as no one understood what I was trying to do. Maybe I could have said I want the options of either area &or entity?

I dealt with that,

{{ expand ( area_entities ( lights.area_id ) ) | selectattr ( 'domain' , 'eq' , 'light' ) | selectattr ( 'state' , 'eq' , 'on' ) | list | count > 0 }}

I actually said this in my first post:
https://community.home-assistant.io/t/how-to-check-the-current-on-off-state-from-an-areas-lights-in-a-blueprint-using-selector-target-entity-domain-lights/472256/5?u=defenestrateit

@petro please don’t get annoyed with me, you have been such a huge help, & i very much appreciate your time, but I am still only a novice at this; & thus have some very stupid perceptions.

State what your endgoal is, not “how do I get the state of a device”. What do you plan on doing with the entities on the device?

So your script takes a target with lights. If any of the lights are on then it turns them off. If all of them are off it turns them on.

Sounds like a light group, why not just make one of those?

&

If the light/s are already on they transition @ one speed & if they are off @ another speed.

Because I really like using the Area selector, because it requires less maintenance & is easier to set up, but I also want the option of using the same code to target A single entity as well.

Now realise I started this project to set up a system for my parents, & tho my mum has the technical mind to understand this stuff I doubt she will ever spend the time learning it (she is 78), so I need it to be flexible enough with that in mind. & I am having heaps of fun learning this stuff…

So a template light then? You seem to be fine with making templates. Make one per area that sets it state from the lights in that area. And then you can control all the lights in that room as one light (turn on and off, transition, etc)

If you’re trying to make this easy for a non technical person to use then making scripts is going to be problematic. When you put a script on a dashboard you get a run button. That’s it. It doesn’t tell you whether the lights controlled by that script are on or off, it doesn’t let you adjust the brightness or change the color, etc. All the things a light does. Users who don’t get HA will struggle to interact with this thing. They’ll press what you tell them to press but it won’t make a lot of sense, it’s just memorization.

Additionally the easiest way for a non technical user to make things happen in HA is scenes. You go and adjust the lights and such in your room to the way you want and then you press a button in HA and basically say “memorize the lights in this room for later”. And then you get a button to press which recreates the room the way you had it. A button they made so they get it more. Lights can be put in scenes, scripts can’t.

You may like the selector but consider how the users you’re making this for are likely to interact with it. If they want to change the lights they’ll probably go look for a light.

1 Like

I’m not interested in putting the script on a dashboard, I set things up with a Automation & A script. Each room has a custom made automation, that does lots of things like object detection (with cameras) & motion detection for lights. & this will turn lights off, but to turn lights on (or change the profile) is very generic & just requires A blueprint script to handle thing like light effects & brightness, which is set by a input_select (helper) for each area.

If you look at my first post, it will probably make more sense:
https://community.home-assistant.io/t/how-to-check-the-current-on-off-state-from-an-areas-lights-in-a-blueprint-using-selector-target-entity-domain-lights/472256/5?u=defenestrateit

In my experience as someone who has done this (motion sensors, occupancy sensors, camera motion events, etc control all the lights in my house) there still needs to be a human override button. Which is why the template light is nice, then you can just check if the room is on with a simple is_state(room_light, 'on') and can change all the lights with a light.turn_on/turn_off/toggle with all the template complexity hidden in the template entity instead of repeated in scripts and automations.

And then if a human disagrees with the automation and wants to change it, there’s a light entity right on the dashboard for them to use to change the whole room at once.

But to each their own. Whatever works for you.

Ahh sorry I didn’t explain that well. I have two input_selects for each area for lights. One for this blueprint (lights.turn_on) [area] lights blueprint which has the profile (as I call it) Bright, Dim, night-light, adaptive, colour loop, ect. & a second for the custom automation, ([area] lights switch) that has only On, Off, Auto.

If you’re truely trying to handle multiple entities.

Requires >= 2022.11

variables:
  lights: !input lights
  entities: >
    {{ device_entities(lights.device_id | default) + area_entities(lights.area_id | default) + lights.entity_id | default([]) }}
  lights_on: >
    {{ entities | select('is_state', 'on') | list > 0 }}

< 2022.11

variables:
  lights: !input lights
  entities: >
    {{ device_entities(lights.device_id | default) + area_entities(lights.area_id | default) + lights.entity_id | default([]) }}
  lights_on: >
    {{ expand(entities) | selectattr('state', 'eq', 'on') | list > 0 }}
1 Like

:star_struck: :pray: :star_struck: :pray: :star_struck: :pray:
Thank you so much.
I think that is going to take me a few days to digest. But that is awesome about different versions. I noticed something happening to the templating data between 2022.11.0 & 2022.11.2

For anyone that uses this code, there is A “count” filter missing & an error for “lights.entity_id”. It should be:
Requires >= 2022.11

variables:
  lights: !input lights
  entities: >
    {{ device_entities(lights.device_id | default) + area_entities(lights.area_id | default) + [ lights.entity_id ] | default([]) }}
  lights_on: >
    {{ entities | select('is_state', 'on') | list | count > 0 }}

< 2022.11

variables:
  lights: !input lights
  entities: >
    {{ device_entities(lights.device_id | default) + area_entities(lights.area_id | default) + [ lights.entity_id ] | default([]) }}
  lights_on: >
    {{ expand(entities) | selectattr('state', 'eq', 'on') | list | count > 0 }}

@petro you’re my hero! :grin:
But this will thro false positive’s for both device’s & area’s because it is not filtering out entities that aren’t in the “light” domain, So:

variables:
  lights: !input lights
  entities: "{{ device_entities ( lights.device_id | default ) + area_entities ( lights.area_id | default ) + [ lights.entity_id ] | default ( [] ) }}"
  filtered: "{{ expand ( entities ) | selectattr ( 'domain' , 'eq' , 'light' ) | selectattr ( 'state' , 'eq' , 'on' ) | list }}"
  lights_on: "{{ filtered | count > 0 }}"
  transition: "{% if lights_on  %} 90 {% else %} 0 {% endif %}"

@petro If you would be so kind as to critique my work, it would be much appreciated.

looks fine, you did alter lights.entity_id for the worse though. If you need to account for single items…

  light_entities: >
    {% if lights.entity_id is iterable %}
      {{ [ lights.entity_id ] if lights.entity_id is string else lights.entity_id }}
    {% else %}
      []
    {% endif %}
  entities: "{{ device_entities ( lights.device_id | default ) + area_entities ( lights.area_id | default ) + light_entities }}"
  filtered: "{{ entities | select( 'search' , '^light' ) | select('is_state', 'on') | list }}"
  lights_on: "{{ filtered | count > 0 }}"
  transition: "{{ iif(lights_on, 90, 0) }}"
1 Like

So something like:

variables:
  lights: !input lights
  entity: "{% if lights.entity_id is defined %} {{ iif ( lights.entity_id is string , [ lights.entity_id ] , lights.entity_id ) }} {% else %} [''] {% endif %}"
  entities: "{{ device_entities ( lights.device_id | default ) + area_entities ( lights.area_id | default ) + entity }}"
  filtered: "{{ entities | select( 'search' , '^light' ) | select('is_state', 'on') | list }}"
  lights_on: "{{ filtered | count > 0 }}"
  transition: "{{ iif(lights_on, 90, 0) }}"

I couldn’t figure out how to get the “iterable” command to work?

So just for intellectual purposes, & hopefully some day soon; historically/hysterical purposes (Use expand on a value set from a target selector)

:face_with_monocle: How would one deal with multiple Area_id’s?

It’s a test, not a command. Sorry forgot to add defined before hand.

  light_entities: >
    {% if lights.entity_id is defined and light.entity_id is iterable %}
      {{ [ lights.entity_id ] if lights.entity_id is string else lights.entity_id }}
    {% else %}
      []
    {% endif %}
1 Like

Sorry to critique your work, but I would like to fully understand your thinking. (there is a typo for the second “light[s].entity_id”)
1/ What is the point of the “iterable” test? It seems to return true if the variable is a list or string, & returns A error when undefined?
2/ I don’t understand this line?

{{ [ lights.entity_id ] lights.entity_id is string else lights.entity_id }}