Possible to define a named notify that calls a script?

Configuration
1

I was thinking about using the Alert integration to handle repeating notifications when someone leaves a door open. It appears the Alert integration only calls notifiers, not scripts, so I am trying to figure out how to define a named notifier in configuration.yaml that can call my script.chime_tts (it plays a sound file and then a TTS message on the specified media_player targets). I haven’t been able to figure out what “platform” to configure in the named notifier to call a script.

A non-working example of what I’m trying to do in configuration.yaml:

notify:
  - name: local_notify
    platform: script
    service: script.chime.tts

It would be better if the Alert integration supported calling scripts directly, but creating a named notifier that can call a script would be the next best thing. Not sure if it’s possible.

I have a functional workaround using an automation, but I feel like the Alert integration is a cleaner syntax. Even if I get Alert working, it looks like I may still have a challenge of using a single alert notification to support multiple triggering entities (i.e., any of the doors as triggers for the alert with independent interval tracking and templating to define the message based on the triggering entity). That particular limitation is one of my issues with using my automation below. I have to have one defined separately for every door because the data_template section wouldn’t know what entity condition was matched.

Here is my working automation for repeated alerts:

- id: patio-door-left-open-repeat
  alias: Patio door left open - repeat notify
  trigger:
    platform: time_pattern
    minutes: '/1'
  condition:
    condition: state
    entity_id: binary_sensor.patio_door
    state: 'on'
  action:
    - service: script.chime_tts
      data_template:
        entity_id: all
        sound: airplane-cabin-ding-dong.mp3
        message: "We don't live in a barn. Close the patio door."
2 Likes
2

I found an inconvenient flaw using /1 in the time pattern. Because it’s based on the clock rather than when your state changed your first alert will be less than the desired delay (anything from immediate up to the interval). For example, if you use /1 your automation will trigger at every minute of the clock. Your state change in the condition is likely to be somewhere between the 1 minute intervals, so the next interval will see the state change and do your action. In my case, sometimes someone would open the door and immediately be told they have left it open.

Fortunately we have a new feature (I think introduced in 0.114.x) for repeating. This makes for a much better solution. With this feature we can trigger on the actual state change 1 minute ago and then repeat for that interval.

- id: door-left-open-repeat
  alias: Door left open - repeat notify
  mode: parallel
  trigger:
    - platform: state
      entity_id: 
        - binary_sensor.garage_door
        - binary_sensor.patio_door
        - binary_sensor.garage_tilt_single
        - binary_sensor.garage_tilt_double
        - binary_sensor.front_gate_access 
      from: 'off'
      to: 'on'
      for: 
        # 1 minute for house doors, 2 minutes for garage entry, 15 minutes for big garage doors
        minutes: |
          {{ 15 if trigger.to_state.object_id|replace('_tilt_', '') != trigger.to_state.object_id 
             else 2 if trigger.to_state.object_id|replace('.garage_door', '') != trigger.to_state.object_id  
             else 1 }}
  action:
    - repeat:
        while:
          #comparing last_changed instead of current state to avoid multiple active instances of this running if there is a brief off/on during the delays
          - condition: template
            value_template: "{{ trigger.to_state.last_changed == states[trigger.to_state.domain][trigger.to_state.object_id].last_changed }}"
        sequence:
          - event: chime_tts
            event_data_template:
              entity_id: All
              sound: airplane-cabin-ding-dong.mp3
              message: >
                Please close the {{ trigger.to_state.name|replace("Patio Entry", "Patio")|replace("Tilt", "")|replace("Front Entry", "Front door") }}.
          - delay:
              # 1 minute for house doors, 15 minutes for garage doors
              minutes: "{{ 1 if trigger.to_state.object_id|replace('_tilt_', '') == trigger.to_state.object_id  else 15 }}"
2 Likes
3

Thanks for sharing this. I’ve been fighting with the Alert integration for years now - it seems like the cleanest most efficient way to do recurring alerts but its so limited in terms of calling complex notifications and/or running scripts and other actions. I’ve skimmed your new implementation using the repeat but haven’t fully got my head around it but if I’m hoping I can use it to finally move away from Alerts.

My concern about leaving behind Alerts is that they have a handy Acknowledge feature - so I can send an actionable notification and acknowledge the alert effectively silencing the alert unless it resets and trips again. I know I could do something similar with binary sensors and conditions but it won’t be as clean. I suppose I really wish they would take another look at Alerts and give them access to scripts etc.

1 Like
4

I agree that an ack feature would be great to have in my implementation, or a vastly improved feature set for the alert integration to make it viable for my needs. Another feature I’d like to add is a snooze feature for something that gets repeatedly triggered and you are tired of hearing it get triggered (e.g. the front gate when the lawn service is going in and out repeatedly for an hour. No time available to work on it anytime soon, but if you come up with something I’d be interested to hear about it :slight_smile:

1 Like