More flexible alerts

Currently the alert component only allows for the same basic preset message to be sent to a list of targets at specific intervals, without payload or other type of customization possible.

Here are a few use case I’d like to see alert support:

  • Ability to add other notification data to the service call, such as a tag and/or actions for html5. These would be alert specific which means the workaround suggested in the documentation doesn’t apply (or at least isn’t easily doable).
    E.g. the object_id of the alert could be set as the tag, so that a dismiss callback action can be taken directly from the notification to turn_off the alert.
  • Ability to notify only once (or never, or a finite amount of times). For example I might want to get a couple phone calls, but stop after that. This could be indicated by a value of 0 as the last entry of the repeat list.
  • Support templating for the notification data, in particular message. This would allow people to for example include information such as the amount of time the alert has been ongoing, or the value that originally triggered the alert (e.g. battery level or sensor’s temperature). This has been suggested before.
  • Conditions for the notifications. This has been suggested before, and usually discarded with the workaround of including the condition inside the alert trigger. However this isn’t quite correct and doesn’t always work.
    The advantage of an alert is that it can be acknowledged and turned off until turned back on or when the condition occurs again. Folding the “notification condition” into the trigger will cause the alert to behave like if it “forgot” it was turned off even though the relevant condition didn’t change.
    It might be easier to picture with an example: let’s imagine a fictional “beep” alert for a low battery on a sensor. I only want this beep to happen if someone is present. I also want to disable the beep once I know about it. If I include the presence test with the battery level test as a trigger, the alert will start beeping again as soon as I leave and come back, even though the battery level has stayed low.
    Such conditions could also be used to support dynamic repeat interval, by basically setting a low repeat interval and preventing the notification if the conditions aren’t right.
  • Last but not least, customization of all the above for each notification target. The idea is that a single alert needs to provide the information differently for each notification channel. This could probably be accomplished with a clever combination of multiple alerts and groups to toggle and present them together, but why not support this natively.
    Also, we may want to have a different list of notifiers (or at least different payload data) for the done notification (e.g. to dismiss the html5 notifications when that’s supported)

An example of all those things combined would be: I want to send an html5 notification every minute (so that it stays active until the alert is turned off) containing up to date information about the trigger (e.g. battery level or temperature), play an audio message on the speakers every 10 minutes if people are present (the message might be formulated differently than the push notification), place a call after 10 and 30 minutes if no-one is present.

A possible configuration would look like:

  name: Garage Door Alert
  entity_id: binary_sensor.garage_door
  - service: html5
    repeat: 1
      title: "Garage Door Open"
        tag: "garage_door"
         - action: acknowledge
           title: Dismiss      
         - action: close
           title: Close door
      message: "Garage door has been open for {{ relative_time(state.binary_sensor.garage_door.last_changed) }}"
  - service: google_assistant
    repeat: 10
    skip_first: True
    - condition: state
      entity_id: group.all_presence_devices
      state: home
      message: "Warning! Garage door has been open for {{ relative_time(state.binary_sensor.garage_door.last_changed) }}."
  - service: twillio
      - 10
      - 30
      - 0
    skip_first: True
    - condition: state
      state: not_home
      - "+12135550123"
      message: "This is a warning from Home Assistant! The garage door has been open for {{ relative_time(state.binary_sensor.garage_door.last_changed) }}."
  - service: html5
      title: "Garage Door Open"
      message: "Garage door is now closed"
      dismiss: True
        tag: "garage_door"

The component you are looking for is automation.

Sure, this could probably be approximated with multiple automations for each alert, but being in the middle of writing them, it’s not that straightforward.

E.g. the repeat aspect of the notification either requires multiple timers (one for each alert / notification combo) or some clever use of the time trigger.

Maybe it is what the alert component should be: a state with no notifier whatsoever and offload all notification duties to automations. Maybe keep the concept of a repeat that triggers an event that the automation can hook into.

But I think my suggestions also solve most alert notification use cases I can think of and that have been requested before.

The first idea in my head was in the line of @mathieuh post. I wanted to add some stuff here and there, and alert component seemed the way to go.

Of course we have the automation component, but all the friendly stuff and syntactic sugar provided by the alert component disappear when going into the alert.

Does it make sense to create a new event for alert firings? Then we could have automations respond to alert triggers --or even AppDaemon code, for instance. It would be nice if the automation had control over what is happening, but I am not sure if that integrates nicely with automations --e.g. be able to prevent an alert from firing from the automation.

I haven’t seen an easy way to perform an “automation retrigger based on time until some user interaction is done”, which is very nice in alert component. I would love to be able to use the best of both worlds, this autoretrigger with flexibility of automations. Having the simple semantics and clean definition of alerts is a bonus, ofc.

Totally agree with OP

The Alert component could be much better if we could customize the message that gets sent out to notifiers…
For example sensor.last_changed

I stumbled upon this feature request while searching for a reliable method for repeated notifications and want to give my two cents.

In short:

  1. Using automations for repeated notifications is possible, but in practice has several issues in detecting the alert condition reliably.

  2. Customizing the alert message is possible, as the name configuration variable accepts templates. But: The name of the alert is displayed in the UI literally as it is configured, i.e. showing the template definition as the title of the alert entity. :confounded:

At length:

I ran into several problems when using automations for repeated notifications, that I was never able to sort out completely. Especially you need to define rather complex conditions for these automations, just to achieve, that they are sent only once (!) every x minutes. Let alone dynamic notification delays…

To avoid being spammed with notifications when the problematic condition occurs, most examples in this forum suggest using a condition to check, when the notification automation was last triggered. But unfortunately, when doing so, your condition needs to separately catch the special case, that the automation was never triggered since the last restart of HA. In this case it returns a none value. As templates don’t deal well with none values by themselves, dealing with them in a proper way makes the trigger condition even more complex and unreadable.

On the other hand, using templates in alert names also has an ugly pitfall, as mentioned above. While the alert is working fine, showing the duration of the problem in the notification, in the UI the entity is shown as someting like…

Freezer didn’t freeze for the last {{ ( ( as_timestamp(now()) - as_timestamp(states.binary_sensor.binary_sensor.freezer_doesnt_freeze.last_changed) ) / 60 ) | int }} minutes! Please check!

For me this is the total opposite of a friendly name. I have the suspicion, the usage of templates in alert messages was added in a later version of the component and the author wanted to avoid a breaking change by sticking with the name value.

Personally, I don’t need alerts as flexible as automations. The beauty of alerts are their simplicity.

Thus, I’d like to suggest just one change: Please introduce a separate configuration variable for the alert message called alert_message similar to done_message. For backwards compatibility, name may still be used as the alert message if alert_message is omitted.

If it were just me, this could also be implemented as a breaking change, i.e. making the use of alert_message mandatory for alerts. The separation of the name and the message of an alert would make the configuration even more readable and more consistent.

Most of the other HA components use the name variable just as advertised: To show a friendly name in the UI. The alert component should do this as well.


So is there a way to modify the notification to include a title and a message?

Problem I’m having is I want the notification that’s received by tasker to be silent. The only way to do that is to have a blank Title. { "title": "", "message": "Garage"}

I can’t seem to do that with Alert component

Edit, solved it by including a blank title:

    name: Garage
    title: ""
    entity_id: input_boolean.garage_sensor_boolean

I agree that the alert component would be even greater with some improvements.

Allowing for a condition, for example, would avoid a lot of automations.

I hope someone considers improving what is already a great component.


1 Like