Closed randellhodges closed 1 year ago
I've wondered about this myself but never have gotten around to creating an issue for it. I've been wanting to implement weather alerts from the US National Weather Service as an HA component.
The Wunderground component does this with a sensor.pws_alerts sensor. The state is the number of alerts available, and all of the alert data is crammed into the attributes of that sensor. However, that approach is almost impossible to create automations based on, as the attributes are different depending on the number of alerts. One alert will give you a Description
attribute, while the other gives you a Description_TOR
attribute etc.
The ideal scenario in my head would be for each active alert to be its own entity. When the alert expires or is cancelled, that entity is removed from Home Assistant all together. Entity ID would have to be based on some kind of unique identifier like sensor.weather_alert_tornado_uniqueid
and then tie them all back to the weather alert component using the new device registry. You wouldn't be able to have just a single entity for each alert type, as (atleast in the US) there can be multiple alerts of the same type at the same time.
Simply firing an event wouldn't work, as the information needs persisted somewhere so it can be shown on the frontend (or accessed over the API for alternate frontends/appdaemon/etc).
You'd probably have to get really fancy with templates to do any automating based on that though, so under the current architecture I'm not sure if it's the best route. I don't really think the built-in alert
component is the best either, as it doesn't appear to let you add extra attributes.
I'm definitely interested in hearing what others think.
Good points. I was also thinking, since these apis are poll based, if you created an alert, and the user dismisses it, how do you keep the same alert from being created the next poll interval? Would that mean we have to keep track of what alert was generated (back to the unique id) and which ones the user dismissed?
I remember reading something in one of the various repos about per user alerts and system alerts, etc. I wonder how much of this discussion will tie in with alerting in general?
Adding myself to the discussion, Portuguese weather service (IPMA) also provides notifications.
I've been thinking about adding those notifications using persistent_notification
https://www.home-assistant.io/components/persistent_notification/
I was also thinking, since these apis are poll based, if you created an alert, and the user dismisses it, how do you keep the same alert from being created the next poll interval?
In the case of each alert being a basic sensor.
entity I'd just add something like a dismissed: true
attribute if it's been dismissed/acknowledged, but keep the entity around the entire time the alert is active.
If each alert is a sensor...
I like logging all my sensor input. I am lazy and just map the domain to include, and then exclude the 4 or 5 things I don't want included. One issue with creating all these sensors, since you not allowed to regex the exclude, is, how do I prevent these sensors from being logged?
Polluting the state engine with alerting information (creating new entities, that is) does not sound a good idea to me. IMO those alerts are simply events (or notifications, if you will), and should be handled as such. So in my opinion we miss currently a generic solution for handling the events/notifications coming from entities (e.g. when a phone is ringing, or an e-mail is received) nicely, which could also be useful for those weather alerts (and there are probably a lot of other similar usecases to grant a generic, homeassistant-wide solution). What do you think?
I don't know that events would work well for these as the alerts are persistent (for a period of time atleast) and in the case of the US National Weather Service alerts, the attributes can change after an alert has been issued (things like description, or the expiration time can get moved forward or backward).
Well, obviously there would be some sort of central tracker/handler for those events (let's call it AlertManager here to avoid confusion), to which one could define their ""start_time" and "end_time" or whatever, which could be updated if necessary. Active, tracked alerts/notifications could be then simply shown in the UI or be automated by listening to events on that AlertManager), maybe?
All location based alerts (incl. weather) should become a platform of the geo_location
component.
Would love for hass to consume Dark Sky alerts since the WU API is going away.
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck
The Dark Sky api can also provide weather alerts. I can see benefits of getting this information into HA, but I'm not certain the best approach.
Would this be an extension to the weather component base, giving its components the chance to push alerts, or just let the component implement its own alert? Also, should it create HA alerts, or something special inside the weather ui widget?