Alert2 - a new alerting component

Development
12

Since I’m making suggestions anyway, another great thing is to make the repo a dev container. It greatly adds to the probability of help on the integration too (I might help for example). And also UI config flow for setting up the integration. :slight_smile:

13

I just updated Alert2 to support HACS install as of v1.3.1. As part of that, I had to move the accompanying Alert2 Lovelace card into a separate repository, Alert2 UI. I recommend installing the Lovelace card as well. I updated the instructions in the README in both repositories.

@teachingbirds and @NathanCu, thanks for the suggestion. Let me know what you think.

@teachingbirds, most of an Alert2 yaml config is a (lengthy) list of alert definitions. I didn’t think config flows were built for that kind of thing. I think of the list of Alert2 definitions as of the same flavor as lists of automations or scripts that a HA install typically has. So I wasn’t sure where would be better to put the Alert2 definitions.

Sincerely,
Josh

3 Likes
14

However much I appreciate this addition to our toolbox, I would like to advocate for the inclusion of some of the useful options the old (and admittedly somewhat weird) alert integration features :

  1. the equivalent of the ‘repeat’ option (with variable & multiple times) iso the single fixed notification_frequency_mins
  2. the (message) ‘data’ option, which makes for a much more flexible notification system, especially so when used in a mobile notification context
  3. to a lesser extent : the skip_first & the done_message options

Thanks nonetheless for your very promising contribution, and for eventually considering these FRs :+1:

1 Like
15

@pav, thanks for the suggestions. Can I get your opinion on a couple of details:

  1. For notification frequency management (e.g., the “repeat” parameter), how about config parameters similar to the following:

    • notification_frequency_min | list
      Similar to the existing “repeat”, takes a list of numbers. This list does not cycle but saturates at the last value of the list. Is there any use case in which cycling is useful?
    • reset_when_fires | bool=false
      When an event alert fires or a condition alert goes from off->on, if this parameter is true, the notification repeat logic resets, resulting in an immediate notification. If false, then the logic does not reset and a notification may not be sent until the next time specified in the list.
    • stop_after_gap | bool=true
      After an event or condition alert fires, do notificaitions continue until explicitly ack’d (even after a condition alert turns off) or do they stop once a time interval elapses larger than the current “repeat” value.

    Alternatively, I’m intrigued by the idea of making repeat take a template that evalutes to the next repeat value. I could expose variables in the template eval so you could express whatever logic you wanted.

    In addition to the above, snoozing or disabling notifications is also available.

  2. By default I annotate notification messages with extra information (like how long ago an alert started firing, how many events since last notification, etc). That probably interferes with the special “clear_notification” message that the mobile_app notification platform recognizes. So seems like I should also add parameters:

    • done_message | template
      Message used for notifications that a condition alert has stopped firing.
    • done_message_raw | bool=false
      Whether to annotate done_messages.

I’ll add the data field for notifications. And also the target and trigger fields.
Sincerely,
Josh

1 Like
16

I just redownloaded via Hacs and that works great, thanks for listening to feedback. It will be much easier to keep up with when new releases are coming out.

Would you rather that we make issues in github or continue communicating here? Or a good mix :smiley:

I have noticed some oddities. For example my old alerts are visible in the custom alert-overview, but not my alert2-alert. When I open more-info on an old alert the alert2 more-info opens, and sometimes the regular one is opened on top, and sometimes under it.
Edit: When the alert2 entity fired for the first time it showed up in your card.

I would be nice to add friendly names to the alert2 entities, both the automatic ones and the alerts themselves for better presentation.

It would also be nice to have the notifiers for the alert in the more-info dialog.

I was going to mention the data field for notifications but I see you’re already on top of that. It’s really important for me to be able to make some alerts into critical notifications on my phone for example. And also, be able to have actionable notifications so that we can acknowledge directly from the notification.

17

Agree on all points! Skip first is kind of important I think, since alerts for things like doors left open for example, you dont want an alert everytime someone opens the door to walk through it, but if it’s left open for 2 minutes, then alert. Might of course be possible with conditioning somehow.

18

@redstone99 Somewhat overwhelmed :upside_down_face: by your willingness to cater for my humble requests and by your very well thought-out suggestions concerning their implementation. I hereby offer my own remarks re 1) :

  • notification_frequency_min | list : I also cannot off the top of my head think of any use case for cycling the list
  • reset_when_fires | bool=false : this one has got me puzzled. Mostly so, because I never felt the need for having it NOT reset the repeat logic when firing the alert. But hey, who am I to question the need or usefulness of this option :innocent:
  • stop_after_gap | bool=true : I’ve always been ok with the notification repeating using the last value of the repeat list whilst the alert is still on and unack’d. But again : this is just me … :man_shrugging:

And re 2) I’m sure you’re right about the interference with the command-type pseudo messages of the mobile notifications. The ‘raw’ parameter should take care of that.
I would suggest though to not limit its applicability to the done_message, but have it at the ‘general’ level, i.e. applicable to all messages - because I can imagine use cases where I’d prefer my message to be unadorned with the extra information you standard provide …

Thanks beforehand for such extreme dedication !
Respect & greetz,
Paul

1 Like
19

I think we’re on the same page :wink:
Care to review & shed your light on my most recent reply ?

20

Everything you wrote is on point imo :ok_hand:

21

@pav and @teachingbirds, thanks so much for your feedback.

I just released Alert2 v1.3.2 and the companion Alert UI v1.1.1. Combined change list and comments:

  • Fix UI bugs related to old Alert-1 alerts. The issue of multiple more-info popups, and also listing extra old-style alerts in the overview card. @teachingbirds, let me know if this doesn’t address the bugs you saw.

    Old Alert-1 alerts don’t have enough information to distinguish between an alert being active recently and HA restarting recently. So I made it so that the overview card will show recently active Alert2 alerts, but will only show Alert-1 alerts while they are firing. Just to avoid a flood of Alert-1 alerts showing up when HA restarts. I’m open to a better approach to handling this.

  • Add config support for data, title and trigger parameters. They are passed to the notifier.

  • Add support for done_message

  • Add support for friendly_name - this shows up in the overview card.

  • Add support for annotate_messages. This is a boolean, defaulting to true, whether Alert2 will add extra information to notifications when an alert starts or stops firing. Does not affect reminder notifications.

  • Update README documenting the new options

To followup on your comments:

Posting either here or in an issue is fine with me. Here is good for open discussion, but may get confusing if too many threads are going on in parallel.

@teachingbirds, In your suggestion to include notifiers in the more-info dialog, do you mean just showing for reference purposes which notifier the alert is configured to use?

I distinguish between notifications of an alert starting or stopping to fire, and reminder notifications. I found it handy for reminder notifications to include extra info like “Alert x on for 1hr” and not just repeat the original notification text from when the alert first fired. You can view the original message text when the alert first fired in the more-info dialog. I could document more what kinds of extra info is added. Any thoughts?

@pav, thanks for your comments on reset_when_fires. I realized that what I really wanted was a way to limit notifications and prevent a flood when an alert spasms and turns on&off rapidly (before I can snooze the alert). I’ll look into creating a fall-back parameter limiting max notification rate or something simpler than the reset_when_fires that I had proposed.

NOTE - the currently notification frequency logic does not reset between multiple firings of a single alert. This is I think more complex than it needs to be. I’ll clean it up and simplify to just affect a single alert firing.

I’m considering changing the name of notification_frequency_mins to reminder_frequency_mins, since it really controls reminders specifically. Any reason not to?

Next I’ll work on making notification_frequency_mins take a list, and probably rethink the frequency logic.

-Josh

22

Following up on your feature suggestions I just released Alert2 v1.3.3. Release notes:

  • rename parameter notification_frequency_mins to reminder_frequency_mins

  • reminder_frequency_mins now takes a list of values, similar to the repeat parameter in the old Alert integration. However, reminder_frequency_mins stops at the last entry in the list and does not cycle. It also resets whenever the condition alert turns off, so it no longer controls notifications across multiple firings of an alert.

  • Add throttle_fires_per_mins - Limits notifications for frequently firing alerts.

  • Add on_for_at_least_secs - Limits a condition alert turning on until the underlying condition has been true for at least the specified number of seconds. It’s a form of hysteresis, similar to skip_first in the old Alert integration and on_for in other alert systems.

  • Add annotate_message - Controls whether notifications have extra context information added to them. Useful if need more precise control over notification text.

  • Expand number of options for tracked alerts to mirror the relevant ones available to other event alerts.

  • Update docs

@pav and @teachingbirds, I think I’ve covered perhaps all of your suggestions at this point. Let me know what you think and if there’s anything else you think would benefit from change or addition.

EDIT - I renamed on_for_at_least_secs to delay_on_secs since it seems like a better name. Minor release v.1.3.4.

-Josh

1 Like
23

Hi @redstone99. It looks like you fulfilled all our wishes and then some. I adapted all my alert instances, and converted the last of the older ones to use Alert2, using the new extra parameters.
It is a bit early to vouch for the correct functioning of it all, but knowing you :slight_smile: I’m confident there will be no complaints …
Thanks for a very useful Alert2 integration and especially for bringing it to near perfection in such short time. It - and you - deserve to be highlighted in Hass’s next months’ release notes. My vote you have !
Cheers

1 Like
24

Hi Josh. One thing I forgot until now to bring up : I noticed that Alert2 creates a bunch of alert2.alert2_* entities. Are these purely for the integration’s internal use, or are they supposed to be useful to us as well ? Just asking, because I personally up to now fail to see their usefulness to me.
And because I am on a mission to reduce my DB size, and some of these entities sometimes are massive (one of them currently containing some 11 MB), I would like to do away with them/prevent their creation - of course only if you do not need them yourself …
Thoughts ?

25

Hi Paul,
I’m so glad you’re finding Alerg2 useful. And I’m all for keeping the DB footprint small. I realize that alerts using delay_on_secs will update the DB whenever the condition becomes true, even if the alert doesn’t actually turn on. I should probably change that so DB update doesn’t happen until the alert actually turns on. That’ll help some with DB size.

The alert2.alert2_* entities are used to notify you of issues with Alert2 itself, like a YAML config error, an error evaluating a template, a notifier not being available, and a few other error conditions. I wouldn’t expect them to be very active or to take up much DB space. If you want to prevent them from taking up any space you could exclude them from being recorded in the DB by adding the following to your config YAML:

recorder:
  exclude:
    entities:
      - alert2.alert2_undeclared_event
      - alert2.alert2_unhandled_exception
      ... and so on ...

I can make the change to delay_on_secs alerts and see if it helps you. Or, if you’re up for digging a bit deeper…
It be helpful to know which alert2 entities are taking up space in your DB. Would you be up for running a SQL query for recent alert2 entities and telling me what you see? In particular, whether most of the activity for you is in the delayed_on_secs entities or something else. The following SQL query will show alert2 DB activity in the last 24 hours, showing just entity name:

select states_meta.entity_id, DATETIME(states.last_updated_ts, 'unixepoch', 'localtime') AS "states.last_updated_ts", states.last_changed_ts, states.attributes_id FROM states LEFT JOIN states_meta ON states.metadata_id = states_meta.metadata_id WHERE states_meta.entity_id LIKE "alert2.%" AND states.last_updated_ts > strftime('%s', 'now','-24 hours') ORDER BY states.last_updated_ts;

You could paste that into the SQLite Web addon, or on the command-line, it’d be something like the following (you may need to stop HA first):

$ sqlite home-assistant_v2.db
sqlite> select states_meta.entity_id, DATETIME(states.last_updated_ts, 'unixepoch', 'localtime') AS "states.last_updated_ts", states.last_changed_ts, states.attributes_id FROM states LEFT JOIN states_meta ON states.metadata_id = states_meta.metadata_id WHERE states_meta.entity_id LIKE "alert2.%" AND states.last_updated_ts > strftime('%s', 'now','-24 hours') ORDER BY states.last_updated_ts;

EDIT - added recorder YAML suggestion above.

Josh

26

Hi Josh. Thanks for coming back to me on this ‘issue’. I had already adjusted my recorder settings to exclude most of these entities - more in an attempt to keep a tidy ship, and not so much because of an urgent need. I even think that establishing the space taken up in the DB would not amount to much, because 1) I have not been using Alert2 for more than a couple of weeks now, 2) I have a rather limited number of use cases for it, and 3) my alerts are such that I don’t expect them to fire frequently. So you might say that I am a bit nitpicking :smirk:

The following is definitely in no way meant as criticism, but merely offered as ‘food for thought’ :

  • this is the only integration I know of that packages its issues in multiple & real entities, iso just ‘logging’ them in the standard logs (the latter which has always worked for me)
  • at least to me, their usefulness seems limited to the creation/debugging stadium of the alerts, and of limited or no interest once these are up & running
  • they seem to be overly long-lived & never reset : I have some of them with info from 2 weeks ago, and thus totally irrelevant …

Anyway, no big deal and not worth losing any sleep over it. Still very happy with a much improved Alert integration :+1:

27

Hi Paul,
Thanks for the thoughtful feedback. I can definitely clean up the internal alerts and make them optional - let me know what you think of the suggestion below. And you raise an interesting point about event alerts being long-lived (see below).

My thinking for internal alerts was that, if for some reason Alert2 itself runs into a problem, you may no longer receive alerts for things you actually care about. So in a sense, alert2 failing is as serious as the most serious condition you might alert on. But that’s just an opinion, so how about I collapse the internal entities down to a single one and make it optional with a flag:

  • alert_on_internal_errors - If false, internal errors will just be logged and no internal alert entity will be created. If true, then a single internal alert entity, alert2.alert2_internal_error will be created for tracking and notifying on any internal errors.

The internal alerts (eg an assert failed) are event-based alerts. They indicate an event at a point in time rather than a condition being true or false, so they don’t have a notion of turning on or off. So there isn’t a sense in which an event alert ever “resets” in the way that a condition alert turns off. Would it help if I make it clearer in the UI which alerts are event alerts?

Thanks again for taking the time to give feedback! It’s valuable to get fresh, thoughtful eyes on Alert2 to keep improving it.

-Josh

28

Hi Josh, you keep surprising me, not only for paying such close attention to my ramblings :slight_smile: , but also for proposing well thought-out changes/improvements that surpass my own suggestions.
Just to say that the combination of collapsing the internal entities into a single one, and the addition of the parameter governing its creation would leave me wishless (at least for now, haha).

Btw, talking about the alerts : I must admit that sometimes they leave me bewildered as to their origin and/or meaning. E.g. I had one the other day “Err reported: {‘domain’: ‘alert2’, ‘name’: ‘assert’, ‘message’: ‘Printer_Powered, not notifying but remaining time is 0’}”. Cryptic to me, as I have no clue as to the what or why …

29

Hi Paul, I just released Alert2 v1.3.5. It consolidates all the internal alert entities to a single one, alert2.error, and provides an option to omit even that entity. The weird alert you saw was an unnecessary notification - I fixed the bug. I also somewhat improved the message for alert2.error to request that people file an issue or notify the Alert2 maintainer. My goal is that any alert should be clear and informative, so let me know if you see any confusing things going forward.
-Josh

30

And just released v1.3.6. The main change is to add unittests (yay!) and also allow specifying literal entity names in condition and threshold value parameters. So in an alert, instead of writing:

condition: "{{ states('binary_sensor.my_sensor') }}"

you can now alternatively just write:

condition: binary_sensor.my_sensor

and similarly with the value field of a threshold.

EDIT: I updated the latest release to 1.3.7.1 to support the new HA 2024.10.
HA 2024.10 changes how messages to notifiers are interpreted, making it no longer necessary to wrap messages in “{% raw %}”.

-Josh

1 Like
31

v1.4 is out with support for template notifiers! You can now dynamically specify who gets notified and how. I updated the docs with details and examples.

Also, I opened up the discussions section of the github repo, which might be a good place for discussing specific feature requests. Or here.

Feedback or suggestions welcome!
-Josh

1 Like