@redstone99 Thanks for the latest release, I’ve been running it for about 24 hours and it seems the friendly_name dynamic template has resolved a number of issues. I’ll continue to monitor.
I’ve been thinking about some of the features/capabilities that would be useful next and along the lines of what has been requested from others as well. Here’s some suggestions that I have:
Product Level Features
These are the features I think the overall product needs without yet identifying which component they belong in or how they would be designed:
-
“Staged” alerting. The ability to have an alert fire in one or more stages. These could be further conditions/triggers (e.g. a low temperature alert goes below freezing now, a door open has too much of a temperature drop, etc.), additional time passing since the alert fired (e.g., escalate the group of people notified if the first group didn’t respond or fire a critical notification or phone call now instead of a regular notification), or even an external service triggering further action on the alert. I’m seeing enough overlap here that I think there is a single generic feature that solves the overall problem.
-
Ability to send display information to the UI. I’d like the UI to be displaying current information about an alert (e.g. the current temperature of a low temperature warning). Typically my workflow is: get a notification (e.g. low temperature warning), then remember where in my dashboard that paticular sensor is, and go check it’s current value to know how bad the situation is. Allowing an updating current value to be shown for the alert in the UI would have utility for both my use case and it seems like the open door case.
-
UI grouping/sorting/filtering. The UI would benefit from having the ability to set groups, sorts, and include/exclude filters. This would allow critical alerts to be shown first and other alerts to be put into groups (e.g. snoozed but not acked). Additionally, sorting of alerts to allow most important to be user defined and shown first (e.g. by a priority, last fired time, on/off, etc). Filters would allow different alert2 groups of alerts to be shown in different dashboard areas (e.g. user alerts vs. system level alerts), which could be via tags (like scheduler-card) or other fields.
-
UI icons/filtering. There would be benefit to having different icon and color schemes for different alerts and statuses. I think this still requires some thought., e.g. can an alert itself specify the color it wants to be when alerted, or the icon? Is it better if the icon follows statuses like on/off/snoozed/unacked/etc., or something about the alert itself like a high priority fire alarm that needs immediate response (e.g. red, blinking, special icon, etc.). I’m leaning towards the latter, but theres a lot to think about to not get locked into an implementation too quickly.
-
Handling of unavailable, unknown, and undefined states. Writing in checks for these into conditions becomes tedious, but alerts can fail non-gracefully without checks (e.g. casting to float or int in condition). However, you don’t always want to swallow these (I actually have an alert that explicitly alerts if a critical sensor is in one of those states for too long).
I think 1 through 3 seem to have the most immediate utility from what I’m seeing on the threads and my needs and having used other alerting/monitoring systems.
Possible Implementation for #1 - Staged Alerts
I’ll address #1 and #2 for now as I think they are immensely useful. A possible configuration could be to add a “stage” key items for an alert. I am uncertain if this works broadly for trigger alerts as I can’t conceptualize how you’d implement a stage outside of having a condition except for one particular (useful) use case, a user does not ack a trigger alert within a certain time period (so raise escalation level for example):
Here’s a possible configuration (in this example using a threshold alert):
alert2:
alerts:
- domain: system
generator_name: disk_space_low
generator: "{{ states.sensor|selectattr('entity_id','match','(.*)system_monitor_disk_usage')|map(attribute='entity_id')|list }}"
name: "{{ genRaw }}_disk_space_low"
friendly_name: "{{ state_attr(genRaw,'friendly_name') }} disk space low"
threshold:
value: "{{ states(genRaw)|float }}"
maximum: 80
hysteresis: 5
message: "Usage: {{ states(genRaw) }}%"
escalation_stages:
1:
stage_name: "Over 95% utilization, critically low"
threshold:
value: "{{ states(genRaw)|float }}"
maximum: 95
hysteresis: 5
message: "Usage: {{ states(genRaw) }}%"
notifier: all_admins
2:
stage_name: "Over 95% utilization, response required"
message: "Critically high usage: {{ states(genRaw) }}%"
delay_on_secs: 900
notifier: all_admins_mobile_critical_notification
Where each escalation_stage can fire after the prior stage if the new condition is met. An open question would be if you can fall back “up” the stages as conditions are unmet or you can only progress “down” stages and just exit the entire condition when the original alert condition is met. For simplicity I think the latter is least error prone and most understandable for users and will have most straightforward code.
This solves both my escalation path and I think a second stage condition would solve the door_open, now it’s cold, problem as well with a single design.
I think there could be utility to also allow a service call to change stage but I don’t actually think that’s required for the use cases described given the design above but curious if that’s accurate.
It’s also a little unclear to me at present how stage should be best represented in notifications and the UI. It’s yet another field to try to combine together with the other fields. I don’t know if stage_name is a good idea above, perhaps the stage really just gets writen by the user in “message”. But the UI should be showing what stage you are in, so there’s usefulness in a stage name that the UI shows (to indicate the alert is escalating) - and a requirement from the open_door case. I think there’s utility in both stage_name and message, but some thinking of how they get combined to the user for notifications and UI display.
“Present” Values Display in UI
I’d love it if there was a field, perhaps “display_value” or “display_message” that specified a template that the UI rendered as a current value next to the alert. In my example above that could be the current disk space utilization, so in the UI I know the alert both fired and where the current value is (a value of 81% is different than 94%, but I really want to alert at 80%).
E.g.:
display_message: "Usage: {{ states(genRaw) }}%"
It’s unclear to me if this was overloaded with your circumstances idea, it seemed like it may be?
Implementation in the UI of the above two features will be some display refactoring so it might make sense to think of the UI overall in terms of the other icon/color/sorting/grouping/fitlering items as well (and any other UI features).
Anyway, there are my current thoughts wanted to get them down!