Dynamic notification - works, but gets wiped out

Looking for advice. I have read through the existing threads on this topic, and none of them address this concern.

I have an automation intended to notify everyone at home when one of the family members has returned and needs help getting inside. This notification is not useful to people not currently at home, so I want to limit recipients to only devices which are.

I can set a template target in notify.notify, and it works as long as I stay in the editor, although it is a bit verbose:

{% for device in dict(states.device_tracker|groupby('state'))['home'] %}
    {% if loop.last and loop.length > 1 %} and 
    {% elif not loop.first and loop.length > 1 %}, 
    {% endif %}
    {{ device.name }}
{% endfor %} 

The problem I’m running into is that the moment I leave the editor after verifying that it works, Target is set to null and the automation never works again. Does anyone know why that is, or how I can get it to keep the target? I’m willing to use a notify group if it can be dynamic, but I have yet to see a good example of that.

Your template does not return a list of entity ids. Try this.

{% for device in states.device_tracker if device.state == 'home' %}
  {{ device.entity_id }}
{%- endfor %}

A for loop does not return a list, just a list-shaped group of strings… you would need to use a namespace() to extract an actual list from the loop.

Since there isn’t a direct link between notification services and device trackers, I think the best way to do this is to set up a notifier group for each Person entity in the household, making sure the names match. Then use a Repeat For Each action.

  for_each: >
    {{ states.person | selectattr('state', 'eq' ,'home')
    | map(attribute = 'name' ) | list | lower }}
    - service: notify.{{ repeat.item }}
        message: Someone needs help getting inside

Using notifier groups has the additional advantage of making updating a lot easier when someone gets a new phone or if you decide to try a different notification integration. You can just update the notifier used in the group, not every automation or script.

This has been a small journey. Thank you both for your time, but I think I’m going to drop this project for the time being. It seems that companion app entities and notification services really do need some love soon.

Things I had to learn the hard way:

  1. That note in the documentation about single-string Jinja statements needing quotes isn’t entirely accurate. They need to be quoted any time they’re used in a target. That’s what was causing the statements to get wiped out when I left the editor.
  2. “there isn’t a direct link between notification services and device trackers” - this statement was far more important than I realized at first. Every avenue we have as a result is inference at best, static at worst, and doesn’t exactly meet the criteria. The device tracker has the location, but can’t be used to notify the device and vice versa, so without a common identification attribute between them, it is impossible to tie the two functions together.
  3. While users also have a location and a list of associated devices, the device list is again the device tracker list, and not the mobile_app list and thus also does not help without a common attribute
  4. Notification groups do appear to respond to the group set and reload services, so if we get a linked attribute at a later date, the path I went the furthest with, to add and remove the devices from a notification group through automations when their location changes to and from home, may work. A better solution would be for the notification groups to support a Jinja template and update on state change so no automation is required.
  5. Device Tracker does not have an attribute indicating what integration the device came from, which would be valuable for filtering by device type. As it stands, I’m trying to notify every device on my internal network because Unifi creates device trackers for each object it is aware of.

Thank you again for your time, and best wishes.