So cool! Thanks!
1 Like
Thatās fantastic, thanks so much. While you are in there, a small but very powerful addition would also be to be able to add an optional tag to an alert and for the UI card optionally specify a set of tags for that card to display and if none are specified show all (similar to the Scheduler Card / Component which has an implementation of this for both including/excluding tags in the card: GitHub - nielsfaber/scheduler-card: HA Lovelace card for control of scheduler entities). This allows you to have different cards on dashboards with different alerts shown which is very useful as the system grows (and would be big for me).
Very happy to test the changes and many thanks for your hard work!
I just released Alert2 UI v1.5.2. It should fix the bug with the slider and the 1min refresh and adds a unittest. After upgrading, you can click on the āAlertsā heading at the top of the Lovelace card to show the loaded version and verify itās v1.5.2.
@tman98, can you see if this release fixes the issue you see with an alert firing and not showing up promptly in the UI? They should appear within a second or two. I didnāt find a smoking gun that would explain the behavior youāre seeing, though I fixed a few issues that could plausibly be related. If you see the issue again, let me know the details and what you see in the console. Thereās an assumption I make in the code, that HA groups together contemporaneous entity updates when sending it to the U. I could dig into verifying that assumption if you run into the issue again. It could explain things.
This UI release also reorders the alerts in the Lovelace card. The new ordering lists unackād alerts first, then the ackād alerts. And within each section, itās ordered most recent first. @tman98 or others, let me know if you have thoughts. I can add bright colors highlighting active alerts, but I wanted to put this release out there without that so we can see if the new ordering alone is enough.
Feedback welcome!
-Josh
Adding more optional arguments would be exactly it! I think something along the lines of a data object that is then passed into the notifier would be perfect since thatās how most additional fields are handled in the notifiers Iāve seen. Appreciate the response!
K, will look into adding optional args to report(), maybe I can bundle that with the pattern change Iām working on.
@tman98, I forgot to respond that adding ability to restrict UI card to certain entities, via tags or otherwise, seems like a good idea. It may be a while before I have time to look into it. To make sure Iām understanding, is this so, e.g., if you have multiple HA instances feeding via HA remote into one global instance, that in the global instance you can have multiple alert2 UI cards, either one per HA instance or grouped together?
-J
@redstone99 Great - already downloaded and testing.
Initially, one thing I saw is if I snooze or ack an alert it doesnāt drop down into the Acked, snoozed or disabled section (if its off). Iād expect that if itās on it would stay in the top section but if itās off it would drop down. If I reload it is in the right section.
I think the easiest visible change would actually be just to change the icon and icon color (and can be consistent with other HA look/feel). Let me come back with a few thoughts on that though to be more coherent on it.
One of the use for tags would be what you are saying - I could group alerts from different local instances within the master instance. But we have another use case with my home install, we want to manage a todo list for the family and alert on some critical items if not done. But I also am using alert2 for my system monitoring. I would like those separate on my dashboards, I keep system monitoring on its own page for me and for the family I have a dashboard set up they can see. Iād like only alerts for the family (like the garbage wasnāt taken out) on that dashboard and my system dashboard to have system alerts. Tags would allow me to do just this.
@tman98: The ack issue you just saw and the fired alerts not showing up in the UI issue happens only to alerts forwarded via the remote_homeassistant component, is that right? If so, I think I figured out whatās going on.
Alert2 UI relies on observing sensor.alert2_change_count increment as a signal to update the UI promptly. If it doesnāt see that sensor increment, it wonāt update the UI (until the 60s timer elapses). So any alert2 entity forwarded via remote_homeassistant wonāt cause the sensor to increment, causing the various UI issues youāre seeing.
sensor.alert2_change_count is a performance optimization. The way Lovelace works is that there is a variable, hass that contains the state of every entity. Each Lovelace card gets notified each time something in hass changes, without knowing what specifically changed. So a naive implementation of Alert2 UI would be, on every change to hass, to scan every entity to see if any alert2 entities changed. I was trying to avoid all that computation by letting Alert2 UI just look for changes to that change_count entity.
It sounds like I need to abandon the change_count optimization. I can either do the brute force approach detailed above, or, I could keep a set of known alert2 entities, so at least my brute force scan is limited to those entities. Iām not super excited about the n^2 complexity feel of it, though.
EDIT: Actually, perhaps a better solution is to add an optional config parameter, ui_watch_entities. If youāre using remote_homeassistant, you would set that parameter to the list of entity names corresponding to the sensor.alert2_change_count entities you forward from your remote HA instances. That config parameter could probably a template if you want.
Thoughts?
Josh
I am trying to snooze from an automation like this:
action: alert2.notification_control
data:
enable: "on"
snooze_until: "{{ (now() + timedelta(minutes=30)).strftime('%Y-%m-%d %H:%M:%S') }}"
target:
entity_id: alert2.test_test
The template evaluates to for example 2024-12-04 15:34:48 and this seems to align with what the action takes, but I get an error for: āNotification control call has snooze time specified without timezone info: 2024-12-04 15:34:48 for test_testā
Hi Josh,
Thanks for the UI updates on grouping, itās really getting there and Iām definitely finding it easier to know what is actually a problem to worry about (and using ack to move out of my āworryā group once Iām good with the alert)! So far I think it generally makes sense, but Iāll see after more detailed use.
Hereās my suggestion on making the alerts pop more in the UI. I suggest using some of the existing HA color/icons, e.g. from the Problem class to keep consistency with the HA look/feel:
- For unacked alerts, I think the filled exclamation point in red (similar to the Problem class āonā color). Perhaps the circle red exclamation like the Problem class:
- For acked or snoozed condition alerts that are still active, an outline icon in orange (still thinking which specific icon would be best),. The following are just colors, I think I like orange better as it indicates more of an issue whereas yellow denotes a switch on in HA generally:
- For all past alerts (e.g. acked or disabled and not presently āonā), I think the checkbox in blue standard HA color.
I think the pallete above would match HA themes well and give indications as to which alerts are in which state.
Regarding your change_count optimization. Iām not sure if Iām following the EDIT but I worry that adds a degree of complexity where right now things generally work without needing special config. Iām not yet deep into lovelace programming so wasnāt aware every card got notified on every change - how do other cards generally handle this I wonder as it seems like it might affect a lot of the more complex cards (e.g. auto-entities)? Perhaps there is a pattern in use by those cards?
EDIT: A simple quick less invasive change may be to do your performance optimized scan more frequently, every 5 or 10 seconds. I donāt mind the UI doesnāt immediately react, but 60 seconds is a bit long and creates uncertainty if things are working
EDIT2: Some revisions and pictures added to the icon/color thoughts
Hi @teachingbirds - the snooze request you make should still work despite the error. Iāll get rid of the error entirely - itās more of a debug check from when I was developing the UI code.
J
1 Like
Ah, thank you! I did see that my alert was actually snoozed but I also tried without the templating so I thought that was why.
I just released UI v1.5.3. @tman98 , can you see if it fixes the UI updating issues you were seeing?
Thanks for pointing me at auto-entities. They do brute force scans of all entities, with some throttling. So I did the same thing and removed the dependency on change_count. So it should now work fine with remote_homeassistant. I throttle the scan to at most once per second.
@woodersayer, I took a look at Battery Notes. Since, conceptually, a low battery is a state that persists over time (until the battery is replaced) rather than a momentary event, I think an Alert2 condition alert is a better match than alert2.report() (which fires an event). Battery Notes creates an entity for each device with a boolean attribute battery_low that you can alert off of.
Once I implement patterns, would that be adequate for your use case? If not, what additional functionality would condition alerts need for you? Here are two possible ways of expressing a pattern alert for low batteries. Each create a series of alert entities, one per device. Iām not sure how to avoid the regex/map complexity :
- domain: battery
# Explicitly list the battery notes device names
pattern: [ "device1", "device2", ... ]
name: "{{ patternItem }}_is_low"
condition: "{{ state_attr('sensor.'+patternItem+'_battery_plus', 'battery_low') }}"
# or using a wild-card matching battery-notes entity names
pattern: "{{ states.sensor|selectattr('entity_id', 'match',
'sensor.(.*)_battery_plus')
|map(attribute='entity_id')|list }}"
name: "{{ patternItem|
regex_replace('sensor.(.*)_battery_plus','\\1') }}_is_low"
condition: "{{ state_attr(patternItem, 'battery_low') }}"
In the meantime, Iāll look into adding that extra data arg to report(). Can you give me an example of how youād use it?
-Josh
Thanks @redstone99 - Iāve downloaded the new version and have been testing it, will report back after a few days.
I do have a new issue Iām seeing which is a few alerts I snoozed never unsnooze. Note this was on a local instance not across remote home assistant:
And looking at the details for the low temperature alert, the snooze time period has passed, a while ago.
This has persisted across restarts of home assistant, so something on the server side looks like itās not picking up these old alerts and correcting their state. The only server side log entries related to the low temperature alert are these:
2024-12-09 12:16:27.354 DEBUG (MainThread) [custom_components.alert2.entities] reminder_check for temperature_low_temperature: need_reminder=0 0 0 False
2024-12-09 12:16:27.387 DEBUG (MainThread) [custom_components.alert2.entities] reminder_check for temperature_low_temperature_condition: need_reminder=0 0 0 False
2024-12-09 12:17:19.825 DEBUG (MainThread) [custom_components.alert2.entities] Result cb for name=temperature_low_temperature_condition, self.entity_id=alert2.temperature_low_temperature_condition entity_id=None
EDIT/UPDATE: So far the UI component seems to be updating quickly and on changes on the master remote homeassistant instance, will continue to monitor
@tman98 , thanks for the detailed bug info! Made it easy to find the bug. Iām about to release support for patterns, so was going to include the fix for the snooze bug with that.
-Josh
@redstone99 woops, late reply. I think what youāve laid out for matching would work well! The reason I was looking at the eventing approach was to try and make this generic without having to implement a specific alert for each device. What youāve shared seems similar to using a selector as one would with PromQL and AlertManager which is pretty ideal. I personally think just using regex will be best as thereās ample documentation and functionality is well known. Over all I think the approach you suggested would work well.
In the meantime, Iāll look into adding that extra
dataarg to report(). Can you give me an example of how youād use it?
I feel the most common would be quick and dirty alerting in automations. I could foresee some of this being useful for listening to events but pattern matching would solve that. I think for me this would be a ānice to haveā but Iād rank pattern matching and hot reloading the yaml as higher priority for me since most use cases would be captured.
Appreciating the work youāre doing for the community!