Hi All- I just posted a new thread to discuss some potential Alert2 changes to make it easier to handle unknown/unavailable status in alert config. Let me know if you have any thoughts.
-Josh
Hi All, I just released Alert2 v1.19.3.
Changes
- Reduce logging - an alert firing now produces one warning message (instead of three) and an info message.
- Make
alert_entity_idavailable to most template config fields, includingdisplay_msg - Doc updates
-Josh
True. So basically I would be happy with info. I started using templates in the priority field, as superseds seemed complicated to me (to just bump the prio) Window open= info. Window open longer than 10 minutes = low. Raining outside= medium. And high is reserved for the leak sensors and such.
What I sometimes dislike is the sorting indeed. The lowest battery should go first. I would have used a formula to map prio of batteries, maybe not that end user friendly.
Maybe letās put this on pause
Hi All, Iām thinking of making it so that non-admin users can ack/unack and snooze alerts. Let me know if you have concerns.
-Josh
Hi All,
I just released v1.19.5 of Alert2 and the UI.
Changes
- For
global_exceptionandunhandled_exceptionevents, downgrade some logging to INFO instead of WARNING/ERROR and reduce redundant logging - Add type checking on alert2.report service calls
- No longer require admin permission to ack/unack or snooze alerts via the UI.
@hobex46 - At the moment, priority templates are only allowed with generators and are only evaluated when the generator creates an alert. I could imagine making priority more easily accomodate your use case. Making priority take a tracked template that evals to a number would probably work. For backwards compatibility weād say low=1.0, medium=2.0, high=3.0, or something like that. And then say that badge color by default uses the priority rounded down - so 1.5 would be badged in the color for ālowā. There may be some care required in thinking through what are the semantics when an alert changes priority dynamically, but off the top of my head I donāt think there are any gotchas.
-J
Hi All,
I just released Alert2 v1.20.1.
Changes
generatorcan now create event alerts (it used to only be compatible with condition alerts)- The
entity_idfield inside astatetrigger now accepts templates, if used within a generator. That template is evaluated once when the alert is created (i.e., it does not track changes).
So you can now say:
alert2:
alerts:
- domain: test
name: "{{ genElem }}"
generator: [ 't1' ]
trigger:
- trigger: state
entity_id: "sensor.foo_{{ genElem }}"
The implementation applies a preprocessing step to triggers when used with generators. The preprocessing looks for āentity_idā in state triggers and renders any templates there, then passes the result to the standard HA trigger setup code.
-J
And I also released v1.20.2 of the UI that fixes input fields that broke as a result of HA migration from ha-textfield to ha-input. HA is internally migrating from material design to web-awesome and changing internal APIs along the way. I use those apis, so we may see some issues as they move. I was using HA internal APIs because I wanted to benefit from the features that HA internal input fields have without having to reimplement myself. But HA apparently doesn't want people relying on the internal APIs so maybe I need to bite the bullet and switch away from the internal APIs on the front-end. Anyone want to offer a PR 
?
Josh
And I just released UI v1.20.3, which fixes radio buttons to be compatible with HA 2026.6. As part of HA's move from mdc to WebAwesome, they're changing up some of HA's internal UI components. Expect a bit more churn like this to come until the transition is complete :(.
HA officially doesn't support custom components using internal HA UI components. Unfortunately, there isn't really an easy alternative if you want a similar look & feel and not have to deal with conflicts in UI framework versions (eg by importing my own version of Web Awesome).
J
...and I'm back after a long period of being distracted by other things.
So, I'm futzing around with one of my minor issues - wanting to be able to ack, unack, and snooze alerts by voice, when Alexa via HA Cloud doesn't support alert2.* entities - with a little bit of help from Copilot.
It seems like something that can be made possible using some proxy entities of standard types it does support; I'm trying to ensure that those are as convenient as possible, by making them only exist when globally enabled and do all their operations via the "real" Alert2 entities so they automatically pick up any changes/fixes made to the base code.
@redstone99 Would you be interested in seeing this as a PR? (I promise it's not vibe-coded slop; I review every line and test it thoroughly before submitting.)
Hi @cerebrate - good to hear from you. I don't know much about Alexa, but is it possible to make the HA Alexa integration knowledgeable of Alert2 entities? Then you wouldn't need to proxy them.
Looking at the Alex integration source code, I came across this line, where it looks like "Alert" entities are registered. What if Alert2, during startup, called a similar:
@ENTITY_ADAPTERS.register(alert2.DOMAIN)
class Alert2Capabilities(AlexaEntity):
Without digging deeper, I can't tell if that registration needs to happen when Alexa integration starts up, or if it's fine if Alert2 does it later. Or maybe there's a way to make sure Alert2 initializes before Alexa.
In any case, if it's feasible, I think it'd be better to make Alexa understand Alert2 than do a proxy mechanism.
Though happy to take a look at code if you want.
Josh
Good to be back!
I had looked at that before I went down my previous route, actually when trying to figure out why I couldn't enable alert2s for voice in the HA settings. I could be wrong and I'm willing to be told so, but here's why I didn't think it was really suitable --
The Alexa integration relies on matching up Home Assistant entities with particular types of device that Alexa already understands: for alerts, automations, and groups, as you'll see right below that line, it uses the generic thing-that-can-be-turned-on-and-off support, which requires that the entity supporting it have that switchlike behavior in HA that alerts, automations, and groups all do, acting kind of like the more complex switches and input_booleans.
But alert2s don't, because they're significantly more complex objects than alerts. And, I'd argue, they shouldn't, because if they did that'd mean modifying Alert2 in ways that both break backwards compatibility with existing alert2 behavior, and it would mean picking one switchable thing out of all current and future alert2 behavior for Alexa to support and writing off the others.
(Looking at the other types of devices Alexa understands, there aren't really one or a combo that seem to fit well with possible Alert2 usages.)
The proxy technique I'm currently testing, contrariwise, lets me expose current alert state and both ack/unack and snooze/unsnooze alerts independently without losing access to the current alert state. And I don't think there's a way to do that under the other model.
On another note, since I don't use either HA's inbuilt Assist (which does accept alert2 entities, although I don't know how well it handles them) or any of the other voice assistant support integrations, I don't know how hard it would be to make them all support a native alert2 entity, but I suspect the answer is that they'd all need an extension or patch of their own, possibly one pushed upstream.
But an extra good thing about proxying features through HA base entity types, in this case, is that it automatically works with all of them...
ETA: While it's not quite PR-ready yet, if you want to look at the code in the interim, it's at cerebrate/hass-alert2 at cerebrate-alexa-voice-alert-controls
They'd need to properly instantiate and create binary sensor entities with proper device classes. Whatever this is doing is not the proper way. hass-alert2/custom_components/alert2/binary_sensor.py at b26bb204c4e218def1d13c22904508ecb8c9d121 Ā· cerebrate/hass-alert2 Ā· GitHub
EDIT: That looks like it's just creating a startup binary sensor... You'd need to actually create binary sensors for every alert. That's what alexa uses to handle announcements/alert devices.
Ah, that's because you're looking at the wrong code. binary_sensor.py is a longstanding bit of code that does HA startup detection to avoid, I believe, triggering a bunch of false alerts because their parent entities aren't ready yet.
If you want to look at the proxy entities, you'll find them in entities.py, line 2419 et seq. (hass-alert2/custom_components/alert2/entities.py at b26bb204c4e218def1d13c22904508ecb8c9d121 Ā· cerebrate/hass-alert2 Ā· GitHub), a base class and three subentity implementations, a binary sensor and two switches per alert.
No, Iām looking at the right place. Binary sensors are what cause āalertsā to be usable in Alexa. Your code needs to create a binary sensor. Itās not, so you arenāt getting the functionality you want.
With all due respect, as the writer of the code in question and the one who is running it on his Home Assistant instance at this moment, I think perhaps I'm the authority on how it works.
And, well:
Behold! Binary sensors (and switches), just like I said it created!
(Now, there are problems with this code - and specifically the binary sensor entities, even - which I'm working on locally with unpushed fixes. It's not PR-ready, like I said.
But please do me the kindness of (a) not assuming that I'm some vibe-coding idiot who somehow forgot to create binary sensors in his binary-sensor-providing project and (b) reading the damn code, specifically line 2478 et seq. which define a derived class of a BinarySensorEntity to create a binary sensor, just like the Home Assistant developer docs tell you to do.)
Well, you arenāt following any of the standard practices for integrations. If your platforms are all in a flat entities file without a async setup or platform setup, youāre going to have issues.
Here are the supported device classes for alexa and binary sensors:
You'll also need to ensure are using nabu casa or have alexa smart home skill installed with proactive events enabled.
The async setup is over in __init__.py where it usually is.
And, to be fair, I'm doing a PR here. It's bad form to go around refactoring a bunch of the original author's code unless it's genuinely buggy, y'know?
Good catch on the device class. That's something I need to figure out a good workaround for, as none of those available options are really good proxies for "something (unspecified) is happening that Alexa-side routines may wish to know about". At least if I have to kill the binary sensor entirely I can live with it; it's the switches that are the important part of this feature.
Misspoke, meant "async setup entry or platform setup"