I have a smart switch that I want to trigger a notification if it is off for more than 30 minutes.
I cannot seem to figure out how to do this via automation and searching has lead me to Alert - Home Assistant but that seems as if it is not really used any more and I should be doing this a different way.
Can / Should I be doing this an automation the frontend now and if so what setting do I need to achieve the notification I want?
alias: Device On Notification
description:
trigger:
- platform: state
entity_id: switch.your_switch_name
to: off
for:
hours: 0
minutes: 30
seconds: 0
milliseconds: 0
condition:
action:
- service: notify.your_mobile_device
data:
message: The smart switch has been off for 30 minutes
title: Home Notification
Note that the above is just an example and has not been tested.
This is roughly what I created in the frontend but it never sends any notifications (I left out the time as without it it should just fire when it is off?
alias: Betta Heater
description: ''
trigger:
- platform: state
entity_id: switch.betta_heater
to: 'Off'
condition: []
action:
- service: notify.mobile_app_pixel_5
data:
message: Betta Heater is Off
mode: single
If I run it manually the notification fires up so it is the trigger that is the issue (I tied setting for to 00:00:30 and leaving it for a minute but still no notification)
Th docs say alert is used by something like 1% of installs. I guess I was getting that this appears to now be deprecated (or at least the old way of doing things) and I should be using automation in the UI to achieve the same result
No, I think it just means that not many people are using it.
I wouldn’t read too much into that data.
It’s not deprecated and there is no “official new way” of doing alerts.
It could be just that either not many people know about it or they need additional functionality than the alert integration allows for and they use custom automations instead.
Unless I am missed the point I thought that HA was in general moving away from users editing yaml files and trying to make everything configurable in the UI. I would have thought that people wanting alerts was a pretty common use case (?) but there isn’t a direct replacement in the UI only automations.
You look to also need to manually configure the notification integration but the UI seems to use services without needing to configure anything in the UI.
Probably that I am relatively new to HA and I am trying to do things in the modern way to avoid having to rework things later on down the line. I do have several things in my configuration.yaml that you cannot configure in the UI but I have found that most things I want to do can be done in the UI.
But I’m just telling you that alerts are not deprecated and there is no more of a “modern” way of doing them.
I used to use automations for some of my notifications but the alerts integration made a few of them much less complicated than doing them thru automations so I switched to alerts for those.
I don’t mind yaml configuration but I can see how this puts off newcomers (particularly the fact that a lot of documentation and examples are now out of date or contradictory).
and in particular
Any new integration that communicates with devices and/or services, must use configuration via the UI. Configuration via YAML is only allowed in very rare cases, which will be determined on a case by case basis.
does suggest a move away from updating configuration.yaml directly
I personally don’t mind either way I just want to do things right hence the thread.
This is where the documentation gets confusing as the alert page
references notification integrations and the notifications page
talks about the notify service so according to the ADR anything that uses a notification should be configured through the UI as it is a service ???
And yes, there is a move toward using the UI for everything. But I doubt it will ever be completely implemented. there are just some things that don’t lend themselves to a UI config as easily as others.
And on the off chance that the alerts are ever moved to be UI only there will likely be an automatic migration of your existing yaml configured alerts into the .storage files so there is still likely nothing to be concerned about “future-proofing” where alerts are concerned.
That said, I could be completely wrong and they could completely break alerts in the next release.