Notification with lights 'on' when leaving home zone

Configuration
,
1

I’ve been trying to wrap my head around how Templating works.

There are several things I want to do/check in a similar way but this feels like a good starting “project”.

When ‘person’ changes from Home to Away (or somewhere else) I want to check all lights (except a list of excluded lights) and if one (or more) are on then I want to send a notification about which light(s) are on to the phone.

Sounds easy enough but I’m new to YAML and Templating. I was considering doing this with pyscript but I think it’s time that I start learning a bit more about the dark side of home assistant.

Anyone have something similar that they can share so that I get a running start.

Thx

2

I prefer to put them in a Group i.e. an opt-in approach rather than using an “exclude” list.

There are a number of approaches to finding lights that are “on” demonstrated in this thread

Are you looking to do an actionable notification to turn them off or just an informative notification?

1 Like
3

Yeah you are right, opt-in is a better approach.

Created a group light.all_lights making it easy to check if there’s a light turned on.

But how do I create a list of friendly names to email/notify.

{{ expand('light.all_lights') | selectattr('state', 'eq', 'on') | list }}

returns the correct lights but it’s too much information. I just want the friendly names. Is that possible to filter out or do I have to do that another way?

Actionable notification is definitely the natural continuation to this but that’s something I haven’t looked into yet.

4

In a light group, the entity IDs of its members are stored in the entity_id attribute. The map filter can be used to pull out a specific attribute from an object.

{{ expand(state_attr('light.all_lights', 'entity_id') | select('is_state', 'on')) | map(attribute='name') | list }}

If the end point is to have it printed out, you may want to replace the list at the end with join(', ')

5

That works. Thx. Now I just have to understand why… :joy:

6

Thought it looked easy enough but apparently there is something I don’t understand.
I was expecting that

service: notify.mobile_app_pixel_6a
data:
  message: >-
    Door(s)/Window(s) {{ expand(state_attr('binary_sensor.door_window_sensors',
    'entity_id') | select('is_state', 'open')) | map(attribute='name') | join(',
    ') }} are open.
  data:
    actions:
      - action: URI
        title: Open Door/Window Status
        uri: /dashboard-home/door-window

would work as well but no.
Can someone please help me understand why not?

7

The actual state of all binary sensors is “on” or “off”… things like “Open”, “Closed”, “Detected”, “Clear”, etc are “pretty” states for the display in the front end (and, unfortunately, for use in the “beginner friendly” Device triggers/conditions/actions). When templating you must use the actual state.

8

Oh wow, didn’t expect that.
Where can I find the mapping between actual state and “pretty” state?

9

The front-end state representations are controlled by the binary sensor’s Device Class

10

Thx, now it’s working as intended.