Why are alerts not available in the ui and easier to set up?

[teachingbirds (Isabella Gross Alström)]

Why are alerts not available to make from the ui, and why are they differentiated from automations at all? Could they not be switched out to a special kind of automation trigger and action instead?
Also would make it easier to have actionable notification alerts!

[Tinkerer (aka DubhAd on GitHub)]

You forgot to vote for your own entry

[ntindle (Nicholas Tindle)]

This would make it easy to say publish an alert to my WebOS TV when an alert is triggered

[mattd (Matt)]

Yeah it seems like there needs to be alert and subscriber like model.

So you create your alerts and then devices are subscribed to the alert.

Then you don’t have to go and configure options multiple times in multiple locations.

[Didgeridrew]

@teachingbirds

Could they not be switched out to a special kind of automation trigger and action instead?

That might make it a lot easier to include conditional logic instead of having to rely on a hack that could be “fixed” at any time.

[CentralCommand (Mike)]

Just to clarify, this is asking for the ability to configure an alert entity in the UI right? Like make the already existing alert integration UI configurable?

That’s how I read it but the comments above seem to be asking for something else entirely. I can make a new WTH if it’s not about that.

[Michel]

Yes to more visiblilty for the alert entity. It is amazing, but really hard to find unless you are really digging into the docs.

[ZuluWhiskey]

Frenck discussed this with someone on Twitter a while back

[teachingbirds (Isabella Gross Alström)]

Yeah, that would be me And that’s where this wth comes from! @frenck

[teachingbirds (Isabella Gross Alström)]

You are correct.

[rct]

<soapbox> I’m surprised the idea of a persistent (repeated/nagging) alert that can be acknowledged or temporarily paused for protecting one’s property doesn’t come up more often.

Functionality that can potentially help avert some sort of loss has a lot more actual value for home automation then many nice to have little automation routines.

It terms of “streamlining” things, it should be easy to set these up even for relatively new users. This means they should be first class objects in Home Assistant.

It also shouldn’t be that the great is an enemy of the good.

The ultimate in flexibility isn’t the primary goal. If I can’t easily explain to a friend how to set one up, without sharing code, it is too complicated.
</soapbox>

[hassbrad]

I’m just hearing about this integration for the first time and I’ve been using HA for a long time. So I definitely agree it’s hidden. Looks very useful!

[scottg489 (Scott G.)]

WTH are votes not auto cast for your own submission?

But yes, I second a lot of the ideas in here. The cross over with automations is apparent and them being tied to only notifications is also a bit annoying.

[CentralCommand (Mike)]

@scottg489

WTH are votes not auto cast for your own submission?

WTH does the forum not auto-add your vote to your WTH or FR topic

I feel like this is probably Discourse’s fault but on the off-chance there’s a setting that isn’t turned on, please turn it on In the rare/never case where someone is making an FR/WTH on behalf of someone else and doesn’t actually want it themselves they can always unvote after.

Agreed.

[Tinkerer (aka DubhAd on GitHub)]

@scottg489

WTH are votes not auto cast for your own submission?

It’s a Discourse “feature” I guess, or bug.

[gjohansson]

I started making the PR for going to the UI here.

This should be expandable in next steps as with the ideas above.

[disforw]

This is an amazing PR! I think this integration has quite a lot of potential.
The only things left would be to allow for alerts based on an entire device_class (IE: alert if any device_class moisture IS wet) or alerts based on logic so you don’t need to create a template entity as a workaround.

[CentralCommand (Mike)]

@disforw

so you don’t need to create a template entity as a workaround.

That’s not really a workaround. It has had this complex alert criteria section in the docs for as long as I can remember that says this:

By design, the alert integration only handles very simple criteria for firing. That is, it only checks if a single entity’s state is equal to a value. At some point, it may be desirable to have an alert with a more complex criteria. Possibly, when a battery percentage falls below a threshold. Maybe you want to disable the alert on certain days. Maybe the alert firing should depend on more than one input. For all of these situations, it is best to use the alert in conjunction with a Template Binary Sensor.

That is literally how it was designed to work.

If you don’t like it that is understandable but I would suggest making another WTH rather then adding a separate feature request to this one

[Tomahawk]

The functionality to use more than one sensor in an alert is also missing. Making alerts more cumbersome to maintain compared to notifications. Now you have to make an alert for every smoke sensor.

Lets hope the HA-team does some work on Alerts getting this functionality more useful.

This will not work for alert:

  smoke_detected:
    name: Smoke alarm
    entity_id: 
      - sensor.smoke1_detected
      - sensor.smoke2_detected
      - sensor.smoke3_detected
      - sensor.smoke4_detected
    state: "on"
    repeat: 
      - 1
    can_acknowledge: true
    title: "HA - ALARM!" 
    message:  Fire in  {{ area_name(trigger.entity_id) }}!
    data:
      push:
        sound: mixkit-classic-alarm-995-classic.wav
        critical: 1
        volume: 1
    notifiers:
      - me

[Boroda]

The irony! Ouroboros in its nature…

• This integration was not set up from the UI

—meanwhile, in UI—

• This device cannot be added from the UI You can add this device by adding it to your ‘configuration.yaml’.