Automation to notify if kids are not in school during school hours

[narsaw]

I am trying to create an automation that would let me know if my kids are not in school during the hours of 8am to 3pm during the week.

I am trying to make it generic enough so that a single automation would work for all three kids.

No errors but its not working, any clues?

It should trigger every time the device_tracker (life360) updates the place attribute.

alias: Kids not in school during school hours
description: ""
trigger:
  - platform: template
    value_template: "{{ state_attr('device_tracker.life360_kid1','place')  }}"
  - platform: template
    value_template: "{{ state_attr('device_tracker.life360_kid2,'place')  }}"
  - platform: template
    value_template: "{{ state_attr('device_tracker.life360_kid3','place')  }}"
condition:
  - condition: state
    entity_id: input_boolean.school_in_session
    state: "on"
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: "on"
  - condition: template
    value_template: "{{state_attr(trigger.entity_id, 'place') != 'School'}}"
  - condition: time
    after:  '08:00'
    before: '15:00'
action:
  - service: notify.mobile_app_parent_iphone
    data:
      title: Home Assistant
      message: >-
        {{ trigger.entity_id.attributes.friendly_name | capitalize }} is not at
        school during school hours
mode: single

[rossk]

@narsaw

No errors but its not working, any clues?

What do the traces say?

[pnbruckner (Phil)]

See:

TRIGGERING ON ATTRIBUTE CHANGES

[finity]

a trigger can only be a state of “true” or “false”. it can’t be a string by itself.

you template is looking for a value of the “place” attribute of that sensor. Which is going to be the name of a place. So unless you have some strange place names they won’t be true or false.

you need to use a comparison to make the trigger become true.

Or use a different trigger.

if you want it to trigger on every change of the device tracker then use a state based trigger:

trigger:
  - platform: state
    entity_id: device_tracker.life360_kid1
    attribute: place
    to:
  - platform: state
    entity_id: device_tracker.life360_kid2
    attribute: place
    to:
  - platform: state
    entity_id: device_tracker.life360_kid3
    attribute: place
    to:

note I haven’t tried this so I’m not 100% sure you can use the attribute in an open ended “to:” test. I think it should work I think but I’m not 100% sure.

[pnbruckner (Phil)]

Remove the to line and it will. See doc link above. It describes this exact scenario.

You might even be able to do it with one trigger listing all three entities.

[finity]

Thanks for pointing that out. I obviously didn’t go to the link.

I guess the open ended “to:” is inherent in the attribute only state test.

That actually makes sense since the “to:” was added to eliminate attribute changes firing the state trigger.

[narsaw]

Thx for the tips @pnbruckner, @finity .

@rossk I normally debug these things extensively and can usually find the issue but when using trigger.entity_id type of codeit makes the process more difficult.

Even in developer tools when debugging automations / script with trigger.entity_id type of code is more difficult.

Anyways I have taken the suggestions and will test and report back for completeness.

[pnbruckner (Phil)]

Some miscellaneous comments…

So I think the trigger can be:

trigger:
  - platform: state
    entity_id:
      - device_tracker.life360_kid1
      - device_tracker.life360_kid2
      - device_tracker.life360_kid3
    attribute: place

This:

  - condition: template
    value_template: "{{state_attr(trigger.entity_id, 'place') != 'School'}}"

Should probably be:

  - condition: template
    value_template: "{{ trigger.to_state.attributes.place != 'School' }}"

In the service call, it might be better to use:

trigger.to_state.name

Although it probably won’t matter in practice, for this automation, it’s probably better to use:

mode: parallel

Regarding testing, I agree with @rossk, you should try looking at the automation’s traces when it doesn’t work as expected. It gives a LOT of information that can help diagnose the problem.

@narsaw

but when using trigger.entity_id type of codeit makes the process more difficult.

Even in developer tools when debugging automations / script with trigger.entity_id type of code is more difficult.

If part of your testing uses the TEMPLATE tab, you can always manually define the trigger variable:

{% set trigger = {
  "entity_id": "device_tracker.life360_kid1",
  "to_state": {
    "state": "home",
    "attributes": {
      "place": "Home",
    },
  },
}
%}
{{ trigger.to_state.attributes.place != "School" }}

[narsaw]

Here is the complete working automation. Thx all for the tips and suggestions.

- id: '1674831559260'
  alias: Kids not in school during school hours
  description: ''
  trigger:
  - platform: state
    entity_id:
    - device_tracker.life360_kid1
    - device_tracker.life360_kid2
    - device_tracker.life360_kid3
    attribute: place
  condition:
  - condition: state
    entity_id: input_boolean.school_in_session
    state: 'on'
  - condition: time
    after:  '08:00'
    before: '15:00'
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: "on"
  - condition: template
    value_template: '{{ trigger.to_state.attributes.place != ''School'' }}'
  action:
  - service: notify.mobile_app_parent_iphone
    data:
      title: Home Assistant
      message: '{{ trigger.to_state.attributes.friendly_name | capitalize }} is not
        at school during school hours'
      data:
        actions:
        - action: LIFE360
          title: Open Life360
          icon: sfsymbols:mappin.and.ellipse
          uri: life360://
        - action: DISMISS
          title: Dismiss
          icon: sfsymbols:xmark
          destructive: true
  - wait_for_trigger:
    - platform: event
      event_type: mobile_app_notification_action
      event_data:
        action: DISMISS
    - platform: event
      event_type: mobile_app_notification_action
      event_data:
        action: LIFE360
    timeout: 00:01:00
    continue_on_timeout: false
  mode: parallel

[pnbruckner (Phil)]

trigger.to_state.attributes.friendly_name

In general, I recommend:

trigger.to_state.name

First, because it’s less to type (lol!), but second because if the entity doesn’t have a friendly_name attribute, the name state field will “fall back” to the entity ID, rather than causing an error. See State Objects.

Out of curiosity, what is the purpose of the wait_for_trigger step, since nothing comes after it?

[narsaw]

Thx for the practical tip on using trigger.to_state.name

Probably not need but typically when implementing actionable notifications you have to wait for a trigger event from the user (action), example from one of my other automations:

  - choose:
      - conditions:
          - condition: template
            value_template: '{{ wait.trigger.event.data.action == "RE-ENABLE" }}'
        sequence:
          - service: switch.turn_on
            data_template:
              entity_id: "{{trigger.entity_id }}"
    default: []
  - condition: template
    value_template: '{{ wait.trigger.event.data.action == "DISMISS" }}'
  - service: script.turn_on
    data: {}
    target:
      entity_id: script.noop

In this case since I am not check the event (wait.trigger.event.data.action) maybe it can be omitted??

[pnbruckner (Phil)]

I haven’t ever used “actionable notifications”, but I can’t see how a script would have to wait for it, unless you want the script to take some specific action based on it, and/or after it arrives.

[narsaw]

Yes precisely, the automation would take some specific based on user selection. Imagine if no one is home and you are notified the garage is opened, you receive and actionable notification, say for OPEN_CAMS or CLOSE_DOOR, you select close door the automation would proceed to make a service call to cover.close with your garage entity_id or open your cameras for viewing.

Actionable notification via Home Assistant

[pnbruckner (Phil)]

Sorry, I generally know what they are and how and why they’re used. I was just saying I haven’t personally used them.

I was responding to your statements, “… typically when implementing actionable notifications you have to wait for a trigger event from the user (action) … In this case since I am not check the event (wait.trigger.event.data.action) maybe it can be omitted??”

I wasn’t sure what you meant by that. It almost seemed like you weren’t sure if something bad would happen if you didn’t have a wait in the script after a notify service call that had actions.

[JoelConnor]

@pnbruckner

Some miscellaneous comments…

So I think the trigger can be:

trigger:
  - platform: state
    entity_id:
      - device_tracker.life360_kid1
      - device_tracker.life360_kid2
      - device_tracker.life360_kid3
    attribute: place

This:

  - condition: template
    value_template: "{{state_attr(trigger.entity_id, 'place') != 'School'}}"

Should probably be:

  - condition: template
    value_template: "{{ trigger.to_state.attributes.place != 'School' }}"

In the service call, it might be better to use:

trigger.to_state.name

Although it probably won’t matter in practice, for this automation, it’s probably better to use:

mode: parallel

Regarding testing, I agree with @rossk, you should try looking at the automation’s traces when it doesn’t work as expected. It gives a LOT of information that can help diagnose the problem. I seem to have encountered such a problem in tracking my children. I set it up and therefore compiled this detailed instruction below. But it must be an open-source device or access to superuser mode. This community was created so that you can find help here. Now I’m sure my kids don’t skip classes, but they still sometimes have trouble solving problems, so I also found https://paperell.net/ for them, which has online writer that write essays for you help. I tested it personally and can recommend this service. This manual will allow you to keep abreast of your children’s learning process and provide them with additional help if needed.

@narsaw

but when using trigger.entity_id type of codeit makes the process more difficult.

Even in developer tools when debugging automations / script with trigger.entity_id type of code is more difficult.

If part of your testing uses the TEMPLATE tab, you can always manually define the trigger variable:

{% set trigger = {
  "entity_id": "device_tracker.life360_kid1",
  "to_state": {
    "state": "home",
    "attributes": {
      "place": "Home",
    },
  },
}
%}
{{ trigger.to_state.attributes.place != "School" }}

Thanks, this is what helped me.