Alert2 - a new alerting component

Hi @tman98 - I just updated HA and see the same. Fix coming.
J

I just released v1.16.1 of the UI, which should make the buttons appear more like they used to.
EDIT: And also released v1.16.2, which adds new default config parameter, persistent_notifier_grouping, to give option to reduce the number of persistent_notification notifications for the same alert.
J

1 Like

That’s great, thanks the buttons look good!

Question, I just saw that ack_required in the UI is now ā€œsemi-deprecatedā€ in favor of ack_required in config. However, these are orthogonal features. I had originally requested ack_required in the UI (and thank you for implementing) to allow old fired alerts (off or event alerts) to be concretely acked in order to fall out of the GUI’s display, despite being off for a longer period of time than the time slider shows. This allows the time slider to control how long ā€œacked, offā€ alerts show - but ā€œunacked, offā€ alerts always show. In this way, I can keep acked, off alerts off the display but I have to positively confirm I’ve seen an alert (via acking) in order to get it to not display. For example, if an alert fires during the night, it could be entirely off the display in the morning and we’d never even knew the alert condition occurred, which for some alerts is a big problem.

This is an entirely separate feature from requiring acking in order to stop reminder messages, which presumably are only occuring for on alerts anyway. Include_old_unacked is really for controlling visibility of off alerts.

There is value in both features.

But I 100% absolutely use the incude_old_unacked feature!

EDIT: I would be supportive of this feature being more granular per alert, and therefore in config per alert and not in the UI. However, to be clear this is definitely not what ack_required is doing - ack_required (to my understanding) is changing the server-side sent notification message sent when an alert is ON. the include_old_unacked feature controls the client-side continued display of alerts when they are OFF even if they have passed the time slider’s time. Two separate features.

I’m currently struggeling to get the syntax for my data fields right, if I want to add (multiple) actions to the notification only if notify_reason == 'Fire' and no actions, if otherwise.

Could someone please provide a working example for this?

@tman98, thanks for speaking up. So ack_required affects both notification and Alert2 Overview card. include_old_unacked affects only the Alert2 Overview card. I’m fine leaving in include_old_unacked for now. The two config fields are so similar it seems possibly confusing to have them as distinct fields, though I acknowledge they support distinct use cases. I updated the README.

@derandiunddasbo - the data field at present must be a dict. It does not at present support a single template string as HA core pull 57105 does. I’m open to adding support for single template strings.

Btw, I just released v1.16.4 which fixes internal errors that arise if a UI alert and a YAML alert both have the same (slugified) name: Issue #31.

Just to provide some context to why one would want this:

One of the things I find quite confusing about the core alert integration is the static configuration of notification data and especially notification actions.

Configured actions are appended to every notification of an alert, regardless of the alert being fired or being resolved. But most of the time, actions for a firing alert don’t make any sense for a resolved alert. For example an acknowledgement action. Most of the time, alert resolve notifications are just for informational purposes and don’t need any actions at all.

And this is the reason why I would like to have the whole actions section of an alert templatable. Thus, I can avoid any actions being appended to a resolve notification.

(Yes, I know, that it’s already possible to ā€œhideā€ actions from a resolve notification with Alert2 by templating the action and title attributes in such a way, that they conditionally become empty strings, but this is a hardly readable and cumbersome configuration and I’m not sure, if hiding actions by defining them as empty strings is a behavior that one can rely on or if this is prone to break in the future.)

I just released v1.17,

Changes

  • data field can now be a single string template that renders to a dictionary. These new semantics are in addition to previous semantics. So data can alternatively still be a dictionary with templates inside it. Also, an alert’s data field can still override parts of a data field set in the defaults section. An example of the new config syntax is:
  alerts:
    - domain: test
      name: foo
      data: >
         {% if notify_reason == "Fire" %} { "a": "some val" }  {% else %} { "a": "other val" } {% endif %}

@derandiunddasbo - give this a spin and let me know how it goes.

-Josh

Yes, this is working fine, thank you for your effort!

{% set clickAction = "/lovelace/haus-mehr?anchor=haus-mehr-ema" %}
{% if notify_reason != "StopFiring" %}
  {% set actions = [
    { "action": "/ack_ema_alarmierung", "title": "Stummschalten" }
  ] %}
{% else %}
  {% set actions = [] %}
{% endif %}
{% if actions | count > 0 %}
  {{ {"clickAction": clickAction, "actions": actions} | tojson }}
{% else %}
  {{ {"clickAction": clickAction} | tojson }}
{% endif %}
1 Like

Hi All - I just released v1.17.1.

Changes

  • Make notify_reason and var alert_entity_id, alert_domain and alert_name available in templates for config fields related to notifications. This includes message, done_message, reminder_message, ack_reminder_message, target, title, notifier, done_notifier, summary_notifier and data.

Also, v1.17.1 of the Alert2 UI fixes a bug relating to processing of active old Alert1-style alerts.
-Josh

Hi,

I’m trying to get Alert Ack working via Notification Actions, but without success.
The example from the documentation says:

    - domain: ....
      ...
      data:
        actions:
          - action: "alert2.development2 ack"
            title: Ack
        my_entity_id: "{{ alert_entity_id }}"

I don’t have in my home assistant a service called alert2.development2, is that something special? It did’t work either. I tried using the alert2.ack service I found using the developer tools. But it’s not working.

my config:

alert2:
  defaults:
    # throttle notifications for any alert that fires
    # more than 10x in 60 minutes
    throttle_fires_per_mins: [10, 60]
    notifier: mobile_app_hoppyb
    summary_notifier: mobile_app_hoppyb

  alerts:
    # Anchor
    - name: anchor_dragging
      domain: snowdrop
      friendly_name: Anchor Alarm
      condition: "{{ states('sensor.snowdrop_anchor_alarm') == 'emergency'}}"
      ack_required: true
      reminder_frequency_mins: 1
      notifier: mobile_app_hoppyb
      message: "Anchor is dragging! 😱"
      done_message: "All good, watching šŸ¤—"
      reminder_message: "Anchor is still dragging 🤨"
      data:
        push:
          sound:
            name: default
            critical: 1
            volume: 1
        actions:
          - action: alert2.ack
            title: Stop Alarm
        my_entity_id: "{{ alert_entity_id }}"

my_entity_id sounds a bit fishy.

PS: In this case, I’m using critical alerts, which works fine. But in this case, the done_message should not use the ā€œcriticalā€ flag. Is there any way that I can configure this?

Hello again,

I figured it out. I thought Alert2 would do this all by itsef, but I was obviously wrong.

I added an Automation to actually handle the actions that come back from the mobile-app.

For my added note I will make a Feature Request in your repository.

Thanks for Alert2

Thanks for the contribution correcting the error in Recipes!
Josh

Question: Is it performance wise smart to use now() in conditions? Are they then checked every millisecond? I want to be alerted when the clothes are dry, so I store the date the drying is done (to survive reboots) and then I check in a condition for this

(now()-states('input_datetime.waschmaschine_last_changed')|as_datetime()|as_local()>timedelta(days=1))

It’s 100% safe.

No. See: Templating - Home Assistant

  • Using now() will cause templates to be refreshed at the start of every new minute.
1 Like

Thanks and another question - how could I get the display message in a template / automation? The sourcecode does some magic with call backs, and I just dont see how that works. (fingers crossed I did not overlook it in the docs)

I’m not sure I follow exactly. Do you want to display the alert message exactly as it was at the point of the alert being sent or do you just want to show the current state of that template on a dashboard?

I do have a external Geek Magic Display that i want to feed with the alerts to (work in progress here. I compile MQTT messages with a template to do so (which also feeds the dashboard).

Either way is fine, preferably the latter - ā€œshow the current state of that template on a dashboardā€

I would make a template sensor on the HA side.

idk if I cant find it, but is there a way to disable one of the alert2 entries without deleting it or having to snooze notifications for X hours?

Sorry, I was not precise. I am in a template. The message is not stored in the attributes, so in the below code how would I get it (to be used in a automation)?

{%if state_attr('alert2.gws_heizungs_storung','has_display_msg') %}
... how to get it now?
{%endif%}