Hi @aaroneisele55,
I think you’d be better off using conditions rather than triggers. HA triggers don’t work well with entities in the “unavailable” or “unknown” state. There are two difficulties. First, if the entity enters state “unavailable” on startup because some component isn’t providing it, that could happen before Alert2 starts, and so Alert2 will miss the triggering event.
Second, “unknown” as a state is visible only when an entity does not exist AND the entity is referenced in a {{ states(entity_name) }} expression. It doesn’t look like HA supports referencing “unknown” in the to field of a trigger. So you could probably make it work with a trigger if you triggered on all state changes of the entity and then used a condition to filter for {{ states(..) == "unknown" }}.
I’d suggest instead of triggers, just using a condition spec for your alert, so something like:
condition: "{{ states('sensor.bme280_temperature') in ['unknown','unavailable'] }}"
@cerebrate - Saw your msg. Will make priority an attribute along with supersedes. Will look into your other suggestions once I get past the current set of items I’m working on.
Hi, I’m wondering if you can help. I set up alert2 a few weeks ago and have slowly been adding and tweaking alerts through the UI. Everything seemed to be working fine (although I get an error when reloading alert2 YAML in developer tools). But now, in the UI, the alerts won’t load. They still seem to be there, because they fire. Is there somewhere I can find the logic that I had entered so I can reinstall and start over?
“Internal Server Error” is almost certainly a bug. In your HA logs, there should be some more detailed error information, like a stack trace. Can you post that?
Also, in the Alert2 Overview card, if you click on the “Alerts” header, it should show you the version of the frontend and backend running. Can you post that as well?
The raw json of the alerts configured via the UI is stored in [HA config dir]/.storage/alert2.storage. But I’d like to fix the (likely) bug you ran into.
EDIT - I just released v1.11 of the backend and UI. Not sure if it’ll fix the bug, but you may want to try that.
Hi All,
I’m happy to release Alert2 v1.11 and the corresponding UI.
EDIT - updated UI to v1.11.1
Changes
Make priority be an attribute.
Make supersedes be an attribute, and move superseding graph calculations to front-end, so the UI Overview card shouldn’t flicker
Create new internal alert, alert2.alert2_global_exception. When an HA task has an unhandled exception, this new alert will now fire instead of alert2.alert2_error. It has a default throttle setting of 20x/hr ([20,60]).
Create new internal alert, alert2.alert2_warning, that fires if Alert2 notices the user using notification commands like clear_notification in a message without setting annotate_messages to false. This warning fires once for the lifetime of the HA install.
Allow alert2.alert2_* internal alerts to be configured via UI
UI
Group superseded alerts in Overview card
Add hide_superseded option to not show in the Overview card alerts superseded by a firing alert.
Allow supersedes in create popup dialog to be specified with yaml flow, without quotes.
Improve rendering of supersedes in UI create popup
Improve background task cleanup in UI
@cerebrate - Factoring out the new alert2.alert2_global_exception hopefully is a first step in making it easier to manage lots of dieing tasks in HA components. You can now, for example, set the notifier of just that alert to null to disable notifications, while still getting notifications for other alert2 internal errors.
Stacked generators is interesting. I wonder what the best way to do that would be.
And having supersedes suppress the done_message makes sense.
And you should have less quoting issues with supersedes now. You can write in a UI config: supersedes: { domain: d, name: n }
without minimal quotes.
@ian_p and @tman98 , the hide_superseded in the UI Overview card should prevent you from seeing superseded alerts if the superseding alert is firing.
Hi @cerebrate or others,
I’m considering adding a small delay (1/2 second?) before sending notifications, to solve a kind of race condition in supersedes, but wanted to see if anyone had a better idea. The race applies to alerts turning on or off (e.g., @cerebrate’s comment about done_message).
Say you have two alerts A and B, and A supersedes B. If A is on when B turns on, then we want to suppress B’s notification. If A is off when B turns on, then we want to allow B’s notification.
But what if A and B turn on (or off) at almost the same time? Maybe A and B both reference the same entity, or depend on different entities that themselves have a dependency due to other circumstances.
Whether Alert2 sees A turn on before or after B in that case depends on implementation details within both Alert2 and HA.
On option is for me to group superseding alerts together and call async_track_template_result once for each group. That would help for simple cases where alert A and B reference the same entity.
Or I could instead, when an alert turns on (or off), delay say 1/2 second before sending a notification, to see if a superseding alert also turns on (or off).
I’m inclined to add the delay because it seems a more robust solution, though it does add a small delay to notifications.
I have a quite big HASS installation and i am trying to switch to this integration.
One problem that i have is that I don’t know how to read the state of the alert2 alerts to work with them. My understanding is that 3 main states should be distinguishable [on_unacked, on_acked, off]. And I dont know how to do that.
Hi - thanks for trying out Alert2. For condition alerts, the state is either on or off. You can tell if it’s been acked by checking if the last_ack_time attribute represents a time after the last_on_time attribute. For example:
I am using your cards but I have additional places where I want to handle the state of alerts either automatically or manually but without a display (with physical buttons for example). I might hav a look into your code next time sorry that I was to lazy this time.
By the way: If someone wants the alarms to trigger other actions than just notifications: I wrote a (tiny) integration NotiScript that can forward notifier calls to script calls.
I have today spent many hours because I wanted specific cards end automations where i needed to filter on acked or snoozed alerts. It was a nightmare.
I even tried dynamicall setting labels like alert2_acked
but I ran into problems with that too.
It would help me tremendously if at least acked (but better: acked, snoozed, disabled) would be a boolean attribute. I really didn’t find any other feasible solution.
Hi @sejnub, I’m up for adding boolean attributes if it simplifies things.
To make sure I understand the problem to be solved, can you give me an example or two of the difficulties you ran into with the current attributes? If it was that the templates got messy, maybe post an example of the messy template.
Thanks,
Josh
In other news: I have successfully implemented Alert2 at home, replacing a ton of binary sensors that were not longer necessary, thanks to Alert2’s management of templates itself. It works perfectly!
Is it possible to use a template for the reminder messages?
The use case is that when the alert first fires, I include the value of the variable that caused it to trigger - in this case the temp of my freezer is too warm. I’ve then configured a reminder every 60 mins, but I just get the name of the alert that is still active. It would be nice to see the temp of the freezer as well, without having to go to the gui.
