Alert2 - a new alerting component

Development
324

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

325

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
326

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.

327

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?

328

@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.

329

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.)

330

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

331

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