(Sorry for another Alert post, but there is too much “noise” in all the other posts.)
Extend Alerts beyond simply triggering Notifications. Make it so that they can do one or all of the following:
Run a Script.
Trigger an Automation with pertinent alert information.
Post an Event on the Event Bus, again with pertinent alert information.
Shouldn’t this be straightforward to do? Isn’t this an obvious feature? Why limit Alerts to just performing notifications?
(My alert responses are generally more nuanced than just sending a notification. Further, I don’t use core notifications directly. I have developed nuanced notification scripts configurable by various field values.)
This kind of already happens, alerts indirectly post a call_service event, based on the notifier they use. They also produce state changes to their related alert entities. Since they post events, they can be used to both trigger and condition automations.
From a few things that have been posted in the arch. discussions, it seems unlikely that Alerts is going to see any major additions or changes… maybe ever, but definitely not until the overhaul of notifications is completed.
Look, I don’t mean to dist anybody with what I am about to say here. People no doubt put there heart and soul into putting these systems together and this doesn’t go unappreciated by me. So please nobody take the following personally:
I have already implemented the solution you referenced above to get around this. It is a completely unnecessary, kludgy work-around. This is a terrible solution to the problem. Hence the word Simple in my post and my desire to avoid all the noise in all the other discussions on Alerts.
It took me a day to figure out how to get this intercept-a-notification-event solution to work. For instance it doesn’t work with all types of notifications and it is undocumented. Further there are certainly use cases where one would not want a formal notification of any kind at all! You can’t implement this solution without having some sort of notification configured which obfuscates the code and makes it confusing to follow two years down the line when you are trying to address a new issue with your alert system. The immense amount of time I burned coming up with this solution was a complete waste of time in a situation that should have been completely straight-forward: e.g. call a Script or trigger an Automation at each timeout.
If the Alert Integration had provided this normal feature my implementation of my alert system would have been done in a heart beat. Instead it turned into a completely unnecessary, whole afternoon research, testing and debugging project.
Home Assistant is supposed to be a power user’s home automation system. It is not supposed to be a hackers puzzle factory. This just turns users away and damages Home Assistant’s reputation.
At the core of Home Assistant are Scripts, Automations, and Events. The Alert Integration should use them. It is that simple. It should tell you how to use them in the documentation and further this should be straightforward to do. These facilities are at the very core of Home Assistant.
As I write this and think about it further there is clearly a canonical way such a system should work as so many other systems do in Home Assistant. When an alert fires it should generate an Alert Trigger and an Automation can trigger on it. Most everything else in Home Assistant works this way. Why is the AlertIntegration an exception?
Btw, I am confused as I thought that this is a Feature Request forum. Why are there extensive discussions of work-arounds in this forum. I wasn’t looking for a work-around. I was posting a feature request because the work-arounds are horrendously bad (although admittedly currently necessary) solutions.
No matter what you think it is or should be, the Alert integration is a notification integration. Triggering automations is not a “normal feature” of notification integrations, at least not currently.
In HA terms, the Alert integration is old. Accomplishing what it does in Automations was annoyingly difficult at the time it was created. To some extent, the integration was created so users could avoid using automations and scripts. Keep in mind this was before:
HA automations had Choose or If/Then actions. Any branching logic had to be done with templates (that were significantly less feature-rich than they are now) and chains of scripts or automations.
Timer entities, Calendar actions, or Calendar event triggers… The tools to delay actions were very limited compared to now.
I think you meant Alert event not Alert Trigger, and I agree that it could be helpful if that was a thing. However, you are mistaken in the belief that Alert is somehow an exception to some rule… very few integrations generate unique event types, many can only be observed in the event bus through core event types like call_service or state_changed… Alert already produces both of these event types.
Because the majority of FR’s will not be addressed any time soon, if ever, and both you as the OP and anyone who stumbles on this thread deserve to be made aware of any known hindrances to it being implemented as well as your available options.
For example and as has been noted in those other “noisy” threads, there are a few posts in the architecture discussions on github from the current code owner of the integration that indicate that no PRs or other submissions (even “Simple extensions”) will be accepted until the larger notification overhaul is complete, if ever…