Alert2 has a built-in alert, alert2.alert2_error, which notifies if Alert2 has a problem itself or if it sees another part of HA crash. By default those notifications go to persistent_notification. You can configure the behavior in your config. See the config section of the docs.
In your specific case, it looks like one of your HA components using a ScrapeCoordinator crashed. Is there a stack trace in your HA logs? I can take a look if you send it.
I could add a config flag to tell Alert2 to not notify when other parts of HA crash, but it seems like a good thing to know about.
Wow, fantastic response. I actually didn’t see the obvious error with the scraping until you pointed it out. I am now searching to see what that issue is. Just an fyi the persistent notification was up to 80 messages since I posted. Maybe a feature to restrict duplicate notification messages might be worth while. Maybe re-display the message with a recurrence count.
Thanks
Hi - the setting throttle_fires_per_mins will limit notifications and then optionally send a summary when the throttling has ended. And of course you can snooze/disable notifications for a particular alert.
With the persistent_notification notifier in particular, I just took a look and it seems possible to dismiss a specific notification and recreate it, so it should be possible to do something like what you suggest. However, the alert2_error alert fires on a number of different problem conditions, so if you did consolidate a bunch of alert2_error notifications into a single persistent notification with a number displayed, it might hide conditions you care about.
First off I cleared up the error I was having.
Secondly, I am thinking that if there is some form of a unique ID (UID) for the alert that is generating the notification since there are different alerts that are triggered then the counts can be specific to the UID for that alert. It won’t prevent different alerts but it will prevent alerts for the same condition to be repeated.
Just thoughts
Thanks!
Hi All,
I just released Alert2 and Alert2 UI v1.10.1. The main change is support for genIdx and genPrevDomainName in generators to make it easier to set up a generator of staged alerts. So for example you can you say:
The above creates three alerts for progressively lower free disk space. Each alert supersedes the previous alert and each alert has a higher priority than the previous alert.
v1.10.1 also fixed a few bugs related to rendering config fields in the create popup.
@ian_p , want to give it a shot and let you know how it goes?
@pcwii , your idea is interesting. The single alert alert2.alert2_error fires for many different kinds of errors. So I’m not sure how to coallesce that particular alert in a way that doesn’t hide the variety of problems that might be going on. For other kinds of alerts, I can totally see each one taking up at most a single line in persistent_notification.
Hey Josh, was away for a while but back and trying out the new versions!
Question, I’m having problems with supersedes. I want an alert to supersede another alert, both are generators.
I tried supersedes in a few different formats (YAML map and YAML flow), and none seem to work - I included all my various attempts inline in the conf code below. Here’s a version, where I want the freezing alert to supersede the low temp alert. I’m still using genRaw back from when other vars didn’t resolve I’ll try changing that back at some point.
But I can’t get the freezing alert to even be read for some reason.
I keep getting errors like this:
2025-03-06 08:47:29.557 ERROR (MainThread) [custom_components.alert2.util] unhandled_exception with stack Traceback for <Task finished name='Task-114165' coro=<AlertGenerator.async_update_rez() done, defined at /config/custom_components/alert2/entities.py:508> exception=UnboundLocalError("cannot access local variable 'err' where it is not associated with a value")> (most recent call last):
File "/config/custom_components/alert2/entities.py", line 575, in async_update_rez
report(DOMAIN, 'error', f'{self.name} Supersedes template trying to parse {sStr} returned err {err}')
UnboundLocalError: cannot access local variable 'err' where it is not associated with a value
- domain: temperature
generator_name: low_fridge_temperature
generator: "{% from 'entity_name_state.jinja' import expand_with_remote -%}{{ expand_with_remote('sensor.fridge_temperature_alert_group') }}"
name: "{{ genRaw }}_is_low"
friendly_name: "{{ state_attr(genRaw,'friendly_name') }} is low temp"
condition: "{{ states(genRaw) != 'undefined' and states(genRaw) != 'unavailable' and states(genRaw)|float < states('input_number.fridge_low_temperature_alert_value')|float }}"
delay_on_secs: 900
message: "Low temp of {{ states(genRaw)|float }}"
display_msg: "Temp: {{ states(genRaw)|float | round(1) }}"
notifier: nowhere_group
- domain: temperature
generator_name: below_freezing_fridge_temperature
generator: "{% from 'entity_name_state.jinja' import expand_with_remote -%}{{ expand_with_remote('sensor.fridge_temperature_alert_group') }}"
name: "{{ genRaw }}_is_below_freezing"
friendly_name: "{{ state_attr(genRaw,'friendly_name') }} is below freezing"
condition: "{{ states(genRaw) != 'undefined' and states(genRaw) != 'unavailable' and states(genRaw)|float <= 33 }}"
delay_on_secs: 600
supersedes: { domain: temperature, name: "{{ genRaw }}_is_low" } <-- ONE TRY
supersedes: "{ domain: temperature, name: {{ genRaw }}_is_low }" <- ANOTHER TRY
supersedes: <- YET ANOTHER TRY
- domain: temperature
name: "{{ genRaw }}_is_low"
message: "Below freezing temp of {{ states(genRaw)|float }}"
display_msg: "Temp: {{ states(genRaw)|float | round(1) }}"
reminder_frequency_mins: 60
@tman98 - confirmed. Your YAML has an error, but there’s a bug in the error reporting logic for supersedes.
The issue is that when using a template with supersedes, the template must produce the entire contents of supersedes, not just a part of a dictionary. I’m updating the docs to say:
“When using a template, the value of the supersedes field must be a string that, after template evaluation, cotnains a dictionary (or list of dictionaries) literal.”
# OK
supersedes: "{ 'domain': 'test', 'name': '{{genElem}}_is_low' }"
# Also OK
supersedes: "{{ { 'domain':'test', 'name': genElem + '_is_low' } }}"
# Not yet supported - YAML dictionary mixed with template
supersedes: { domain : test, name: '{{ genElem }}_is_low' }
Hi Josh,
Is the priority implemented yet, because when I have it in my config, I get an error logged and the generated entities are not created? If I comment out the priority key then it loads without errors.
@redstone99 Nice one! Thanks I’ll use that new syntax.
I think there’s some upcoming UI work you’re considering - still lobbying for (at least configurable) not having un-acked alerts disappear if they are beyond the time window as that bit me again last night.
And for supersedes for my usages I’d actually not want to see the prior alert showing in the UI if the superseding alert is on (or maybe hidden behind an expand/collapse concept if you don’t want to lose it entirely?).
And a question on display_msg. Where does that evaluate, server-side or UI side? With Remote Home Assistant I have alert2 entries created on a different instance than where they are displayed so trying to figure out where the template is getting evaluated. For some reason right now they don’t seem to push through to the end UI.
Hi @tman98, I’m not sure how to get display_msg working with remote_homeassistant without changing remote_homeassistant. display_msg is neither a state nor an attribute and so does not get picked up by RH forwarding logic.
display_msg can change value frequently and is not necessarily related to any change in alert status, Making it an attribute would mean a DB write on every update, increasing DB size, and also it would update last_changed, which seems like could obscure interesting changes in actual alert status.
Instead, I use web sockets to communicate display_msg to the Lovelace UI. display_msg is evaluated in the server.
If someone were to change RH, one possibility may be to have it forward along the state_info -> unrecorded_attributes from an entity.
It also occurs to me that priority may also not work with RH for similar reasons, though that may be easier to get working since it doesn’t change as often and is more of a static field.
My first try with alert2 and, despite adding friendly name for created alert, the friendly name is not added to the entity, instead an attribute named friendly_name2 was added. As a result, entity does not display friendly name anywhere, and (since entities created by this integration have no unique ID) their actual friendly name (or the icon!) cannot be edited either.
Then i attempted to reload using developer tools as instructed, and everything went to shit.
Too buggy. Hard stop for me.
Bonus gripe: when the notification is sent, the name of the alert is in the text of the notification (rather than it being the title, for example) and this cannot be overridden in any way. WTF.
I really was looking forward to this helping me delete a bunch of binary sensors that were redundant if I have alert conditions. Alas, I was wrong.
Hi @Rudd-O , I’m sorry Alert2 didn’t work well for you. Thanks for taking the time to report the problems you ran into. I’m so used to the way it works that getting fresh eyes on it is super valuable.
Can you tell me what happened when you reloaded via developer tools? Reloading shouldn’t make anything worse. It just recreates the Alert2 entities.
Did you try setting annotate_messages to false? If you do that, then you can set done_message to “clear_notification” and the HA companion app shouldn’t get confused. Setting annotate_messages to false prevents Alert2 from inserting the alert name in the message.
It’d be nice if Alert2 somehow warned you if you’re notifying the mobile app and don’t have annotate_message set to false. Maybe I’ll fire alert2.alert2_error once in that case if I can detect it.
Re friendly_name and also unique_ids, I’d coincidentally recently been thinking about getting those working (it’s not trivial). EDIT: Have you tried the Alert2 UI Overview card? friendly_name works for entities displayed there (using the friendly_name2 hack).
If you’re up for it, I’d appreciate your continued feedback!
Josh
