@chris28 - thanks for the example, that helps me understand. Adding per-notifier specializations is interesting. One could imagine allowing other fields, like data to be specialized as well. I wonder if that’d be useful for run-a-script notifiers ala Notiscript.
Anyone else have any thoughts?
-J
Hi @redstone99
First of all, thanks for developing this integration. I’ve been looking for a better way to handle alerts and I thinkt his might be it. Until now, my alerts have been automations, but it tends to lead to automation overload - I have one automation to tell me when the garage door is open, another to tell me when it’s been left open for more than 5 minutes, another to tell me when it’s closed… and the old alerts integration wasn’t flexible enough to cover all my cases.
I do have a question or two about ack’ing alerts. I can see a couple of different scenarios.
(1) Critical things that need investigation when the alert goes off, even if the alert is cancelled. For example, I’m setting up a new water leak sensor (the reason I’m looking into doing alerts better). If that triggers, I need to find out why, even if it later dries up by itself. For this, it certainly makes sense to keep the alert “active” in some sense even when the alert condition is no longer active, so requiring that the alert gets ack’d and continuing to show it in the UI makes perfect sense.
(2) For other things, when the alert condition no longer applies, that should be enough to cancel the alert completely. In these situations, I don’t see the need to have an extra step to ack the alert. For example, if my garage door is left open, I want an alert - a notification with repeated reminders. But when I close the door, a simple notification that it’s now closed is fine. I don’t want to have to go and separately acknowledge the (now irrelevant) alert. In fact, for this one at the moment I have my automations set up to alert me whenever the garage door opens (it’s useful to know when people come home), and when it closes I get a second notification that cancels the first one and then cancels itself too after a 2 minute countdown. Once it’s confirmed closed, I basically don’t care any more that the garage door was open and all the notifications can go away.
I can see a similar use case for low battery alerts. Once I change the battery, the situation is dealt with and the alert and all associated notifications can go away.
Do you have any thoughts about this, or any plans to have alerts that don’t require acks, or get treated as ack’d once no longer alerting?
Hi @Neuron4576, good questions. The behavior of ack hasn’t been as developed as other areas of Alert2. Right now, ack’ing doesn’t really affect the alert behavior either in terms of notifications or persistence in the UI.
One could imagine changing that and adding a two new alert config options:
ack_necessary - if true, an unacked alert will persist in the Alert2 Overview card and reminder notifications will continue to be sentack_message - notification message to send when alert is acked. Can be used to dismiss notifications in the mobile companion app (eg via “clear_notification” message)Another option is to make the alert continue firing until it is acked, using condition_on. So you’d say something like:
- domain: test
name: leak
condition_on: "{{ states('leak sensor') == 'leak' }}"
manual_off: true
So the alert would continue firing even after the leak condition resolved. You’d then have to have some automation button or something to tell the alert to turn off. I’m not sure keeping the alert firing in this case is the cleanest approach semantically, but it’s possible today.
Thoughts?
-Josh
I think I like the first option, but other people might have different use cases.
I could also imagine putting an “ack” button in the alert to trigger the ack action.
One thing I’m a little unsure about is the difference between ack, snooze, and just doing nothing. I actually thought that ack’ing stops the notification altogether, including the notification when the alert condition is resolved (at least that’s what I observed testing it, but I may have set it up wrong). What are the intended semantics? In my mind it’s currently like this:
Ack = “I’ve seen the alert and I’ll deal with it. You can stop notifying me now”
Snooze = “I’ve seen the alert and I’ll deal with it later, but remind me in case I forget”
Do nothing = “I might not have seen the alert. Keep sending reminders”
The way I do things this seems dangerous because I would have a tendancy to ack alerts and then forget. So I would probably want to never ack things until after the condition that triggered the alert has gone away. Or I would want ack’d alerts to remind me periodically until the condition is off. With that in mind, I guess it could be like this:
Ack = “keep reminding me until the alert condition is off, or if it’s already off stop all notifications now”
Snooze = “keep reminding me until the alert condition is off AND I’ve ack’d the alert”
But again, this would only be for certain alerts where I want to be sure I know about it even if it self-heals.
Hi @Neuron4576, you’re right re ack stopping notifications.
Here’s how I think of the semantics:
Ack = “human has addressed the issue”
Snooze = “temporarily stop notifications” (with or without acking)
The proposed ack_necessary flag would continue notifications until an alert is acked, even if the underlying condition has turned off.
So for important alerts that need attention even if the underlying condition turns off (self-heals), you’d set ack_necessary. And then my recommendation is to only ack once you’ve dealt with the situation. You’d use “snooze” to take a temporary break from notifications.
Would those semantics work for you?
J
Hello @Neuron4576
I created a Feature Request for the alert2 add-on.
From what I read in your comments, I think you want to achieve something similar to what I had in mind.
Please take a look and let me know if you think our ideas match:
-Glean
Hi All,
I just released Alert2 v1.15 and a corresponding update to the UI.
This release mostly focuses on the behavior of ack, most-notably adding a new field, ack_required.
ack_required alert config field. If it is truthy, then unacked alerts will continue to get notifications until acked, even if they have stopped firing. Works with event alerts as well. Affects display of the alert in the Overview card.ack_reminder_message to allow customizing the notification message sent when ack_required is used.ack_reminders_only config field. When set, even after a condition alert is acked, you will still get a notification when it stops firing. (default behavior is that acking an alert prevents the done notification).reminder_frequency_mins now may be set for event alerts that use ack_required to control notification frequency.data field templates now have access to alert_entity_id, alert_domain and alert_name variables. This should make it easier on iOS companion app to implement an “Ack” button in notifications and pass through the alert entity id to the event handler.low_priority_color, medium_priority_color, high_priority_color, and off_color to customize alert badge colors.ack_required will persist in the Alert Overview card. This means include_old_unacked is probably obsolete now.data dictionary in yaml display.@cerebrate - I finally had time to do ack_reminders_only.
I adopted and adapted part of @tman98 's outstanding PR for the UI color changes. Thanks, @tman98!
-Josh
Hi All,
I’m considering changing the way templates are handled in data fields, to simplify quoting. Currently, as an example, you’d have to quote like this:
defaults:
data:
actions: "[{
'action': '"alert2.{{ alert_entity_id }}.ack"',
'title': 'Acknowledge',
'timeout': '{{ states("input_number.my_timeout") }}'
}]"
The extra quoting is partly because nested fields in data aren’t checked for templates. Partly it is also to support templates producing numbers as well as strings. In the above example, the “timeout” template produces a number. To support this, alert2 does a python literal eval on template results in data fields.
I propose getting rid of that eval and adding support for templates in nested data fields. With these changes you could more simply say:
defaults:
data:
actions:
- action: 'alert2.{{ alert_entity_id }}.ack'
title: Acknowledge
timeout: 30 # <-- numbers no longer supports templates
This change would assume that any field using a template produces a string. So producing numbers (and bools) would no longer be supported. We could add a mechanism to allow this back in if people want it.
Thoughts?
Josh
Hey @redstone99 – this is definitely an improvement, and a lot easier to understand.
It’s not worth losing strings, but supporting bools and numbers for templates would make defaults a lot more helpful in my case. I’m using defaults to create a template per error priority level, so if I can’t use a template, I just need to copy-pasta around.
As an alternative/extension, having a conditional default would be really cool. Something like:
alert2:
defaults:
- conditions:
# something to describe when alert.priority == "high"
default:
notifier: ...
data: ...
- conditions:
# something to describe when alert.priority == "medium"
default:
notifier: ...
data: ...
Hi @toddhgardner - the restriction I’m talking about for numbers and bool would only apply to fields nested within data, such as the “timeout” field in the above example.
Can you give me an example of your use case for numeric/bool templates in defaults or data fields?
Re conditional default, I’ve toyed with a related idea, of having “tagged” defaults. So you could have multiple sets of defaults, each with it’s own tag, and then, in an alert definition, you could say which tagged default you want to apply.
@redstone99 Here was what I originally tried to do:
alert2:
defaults:
priority: "low"
reminder_frequency_mins: |
{% if priority == 'high' %}
30
{% elif priority == 'medium' %}
60
{% else %}
240
{% endif %}
notifier: |
{% if priority == 'high' %}
p1_critical
{% elif priority == 'medium'%}
p2_warning
{% else %}
p3_info
{% endif %}
icon: |
{% if priority == 'high' %}
mdi:alert-box-outline
{% elif priority == 'medium'%}
mdi:alert-outline
{% else %}
mdi:information-outline
{% endif %}
annotate_messages: false
data:
tag: "{{ alert_entity_id }}"
url: "/1-alerting/status'"
actions:
- action: 'alert2.{{ alert_entity_id }}.ack'
title: 'Acknowledge'
destructive: true
icon: 'sfsymbols:bell.slash.fill'
- action: 'alert2.snooze'
title: 'Snooze 2 Hours'
icon: 'sfsymbols:bell.slash.fill'
I also wanted to use my own values for “priority”, like p1, p2, p3. That way, I could sort alerts by the priority field in my UI. Instead, I just put that in the alert title.
I see. It’s a good motivating example for tagged defaults.
In your example, the only templates used in a data field produce strings (for “tag” and “action”). The only non-string value, for “destructive” doesn’t use a template. The change I’m proposing would still allow you to write “tag” and “action” as you have. You just wouldn’t be able to use a template in “destructive”.
Alerts in the Alert2 Overview UI card that are in the same state (eg firing) are already sorted by priority low/medium/high. Where you looking for behavior beyond that?
reminder_frequency_mins is a number that I hoped to template as well. But honestly it would be less repeatitive more me with conditional defaults instead of templated ones.
I’m not using the Alert2 UI – I have my own alerting dashboard.
Ah, so not in the data fields. Ok.
Do you want to be able to use templates for reminder_frequency_mins in the defaults section of the config or in individual alert definitions? If the later, can you give me an example use case?
-J
@redstone99 in the defaults – i want to keep individual alert configs as small as possible and have them inherit settings based on their priority.
Hi Al,
I just released Alert2 v1.16:
data dictionary templates have changed. First, you can now specify templates in nested sub-dictionaries. Second, templates will now always produce string values, which simplifies the syntax and removes the need for extra quotes. So now you can say: data:
entity_id: "{{ alert_entity_id }}"
actions:
- action: "{% if ....%}...{% endif %}"
data dictionary fields, you’ll get a one-time warning notification of this change.data fields. We can figure out a way to support bool/numeric templates in data fields if people want it.hysteresis, maximum, and minimum.throttle_fires_per_mins in your defaults or for the alert2_error alert.@toddhgardner - I like the idea of conditional or tagged defaults. It may be a while before I have time to implement that. The back-end changes are relatively straight-forward (I think). We’d need to think through how it would be supported in the Alert2 Manager card.
-J
Another noob question. Exactly where and what do I do (either in yaml or UI) to quiet down alert2.alert2_global_exception.
Got something Zigbee related acting up quite often and until I get it fixed would like to not get alerts.
Thanks!
Hi,
There’s some documentation about internal error config here. The quick answer is something like:
alert2:
tracked:
- domain: alert2
name: global_exception
# to limit messages
throttle_fires_per_mins: [ 5, 60 ]
# OR to completely disable messages
notifier: null
-Josh
Hey so great to see some of my PR starting to make it’s way into the main branch! I was away all summer just getting back now. I’ll see if this fall I can try to get the tests working to try to get some of the rest of my PR tested (and see where we are in main vs. some of the changes I made). Looks like some good work has been going on overall!
