Alert2 - a new alerting component

Development
364

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

365

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_id available to most template config fields, including display_msg
  • Doc updates

-Josh

366

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

IMG_3792
IMG_37921170×629 61.5 KB

367

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

368

Hi All,
I just released v1.19.5 of Alert2 and the UI.

Changes

  • For global_exception and unhandled_exception events, 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

369

Hi All,
I just released Alert2 v1.20.1.

Changes

  • generator can now create event alerts (it used to only be compatible with condition alerts)
  • The entity_id field inside a state trigger 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

370

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 :slight_smile: ?
Josh

371

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

372

...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.)

373

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

374

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

375

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.

376

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.

377

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.

378

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:

image
image1391×494 18.4 KB

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.)

379

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.

:man_shrugging:

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.

380

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.

381

Misspoke, meant "async setup entry or platform setup"

382

@petro - Alert2 internal entities (like the binary_sensor ones I think you saw) are created when the Alert2 component is setup. But Alert2 alert2.* entities are created / destroyed dynamically (eg when using alert2 generators).

@cerebrate - I took a quick peek at the code. It was a bit difficult for me to tell what was being proxied. Does each AlertVoiceAlertSwitch entity correspond to a single Alert2 entity? And if so, what does on/off of the switch correspond to? I’m not very familiar with how any of the Alexa / assistant stuff works.

I think my biggest concerns with proxying are a) clutter of extra entities and perhaps more importantly b) the potential for the proxy entity to get out of sync wrt the Alert2 entity. Eg Alexa says an alert is firing and it in fact is not.

I suppose clutter is unavoidable if proxying. Thoughts on the consistency question?

-Josh

383

It’s a little different to the initial design I talked about before, due to some limitations with what Alexa can represent (it can’t really represent a binary sensor in ways that are suitable for alerts), and to keep that clutter of extra entities you mention down to a minimum. So I abandoned snooze as something to support via voice, at least in this first version, and –

Well. What I ended up implementing in AlertVoiceAlertSwitch is something that behaves almost identically to an Alert (as in the built-in integration) only as a facade over an Alert2.

So, in this current design, you can turn on voice proxies as a default option (in which case you get one per Alert2 entity, except where disabled specifically), or you can not, in which case you only get them for Alert2 entities where you specifically enabled them. That follows the existing Alert2 config model, and lets people keep clutter down to only what they need voice access to, or just enable everything, as they like.

(I thought about grouping alert2.* entities and their proxies into devices for ease of management, but especially given that there’s only one per one now, it seemed like too big a change for too little return? Depends on future plans for Alert2 whether it would be useful, I suppose.)

The voice proxy itself appears as a switch.* entity, with the same unique ID and friendly name as the Alert2 it’s proxying for. I clone some data about the underlying Alert2 into its attributes for ease of debugging/automation, but it’s behavior is more complex:

So usually, when the alert2 isn’t on[1], it’s off.
When the alert2 goes on, so does the switch.
If you turn the switch off when the alert is on, it acks the alert2. If you turn it off and the alert2 is still on, it unacks the alert2 again.
When the alert2 goes off, so does the switch.

(And you can’t turn the switch on when the alert2 is off.)

This essentially reproduces the behavior of the old Alert integration. From the point of view of Alexa (or other voice assistants), they can tell if there is an alert requiring attention (i.e., on and not acked), by seeing the switch state, and more importantly, ack an alert by voice just by saying “Alexa, turn off Back Door Left Open”, or whatever.

Hopefully, this shouldn’t be an issue. I deliberately wrote AlertVoiceProxyBase and AlertVoiceAlertSwitch to always refer back to the Alert2 entity they’re proxying and not keep their own internal state so that they wouldn’t need to manage sync (and so that they’d automatically pick up any code changes made in the base entity). It’s always possible I’ve missed something, but I don’t think I have.

  1. This is more complicated for event alerts, which don’t have an on/off state, so for those it turns the switch on for a set “notice period” - default 60s, but configurable - then turns it off again. ↩︎