Hello,
i found out i totally misinterpreted the Alert guide, so i’m seeking for help to achieve my target 
i configured some alerts, one of them is about the instant power consumption above a certain level.
I set up the alert with the repeat parameter set to 30 minutes, assuming in this way i would get at most one alert every 30 minutes.
Clearly, i was wrong. If the power sensor goes up and down around the threshold, i’m getting an alert every time the sensor goes above the threshold. It makes sense (i mean, alerts are for things wrong, if the sensor goes under the threshold, it is ok), but is there a way to avoid “alert spamming”?
Thanks
Use a threshold sensor, with a suitably large hysteresis:
This accomplishes that the sensor does not go on and off repeatedly when the sensor value is around the chosen limit. The principle it uses is is called a Schmitt-trigger:
You could combine it with a for: clause in the trigger of the automation that says the alert only goes off if the situation stays like this for a certain time.
There are a few ways to solve that problem.
You could use your automation to also set a sensor then reset this sensor after 30 minutes in another automation. This sensor would be a condition in your original automation and will not allow it to proceed until the value is reset after 30 minutes.
Good luck!
Since you are already using a template sensor to trigger the Alert, you might consider modifying it.
template:
- trigger:
- platform: numeric_state
above: 100
entity_id: sensor.instant_power_consumption
id: 'on'
- platform: numeric_state
below: 100
entity_id: sensor.instant_power_consumption
for: "00:30:00"
id: 'off'
binary_sensor:
- name: Excess Power Consumption
state: "{{ trigger.id }}"
availability: "{{ states('sensor.instant_power_consumption') | is_number }}"
There are also slightly more complicated methods to be able to use more conditional logic with alerts through automations.
thank you all guys, three tricky different approaches with pros and contros
@Edwin_D thanks for that, i didn’t know about threshold sensors, i’ll keep in mind, but in this situation this is not going to work. Think about an oven, it can use 2.5kW when it heats, but then it is absorbing nothing for a while when it reaches the target temp, and then again 2.5kW, this is going to send me in any case more alerts, otherwise i should put an enormous hysteresis
also @Didgeridrew , nice solution using a template that resents only after a period of time, but even this idea is about the sensor and not the notification itself (using this, i could get only one alert in the whole day if the consumption is going up and down all day)
it seems @pcwii 's idea could work, since it is applicable to the alert notification itself, but damn this is so ugly 
i understand alert spamming is a problem only for me (yes, i’m using alerts for something probably they are not thought for…)
i’ll probably end up just getting power values less often, let’s say 5 minutes, so in any case i’m not getting any alert more than once every 10…
Might be, but there are always many ways to solve a problem. Not that it matters but I have been a systems integrator for more than 30 years writing programs for all manner of PLC’s, these days that also includes teaching said skill at a local college. That doesn’t make my solution better by any means, but I am awestruck by the many people in this forum who ask for help on an automation that is far too complicated attempting to cover every possible outcome in a single automation. It might be possible, but… I have learned that ugly might actually be more simple. K.I.S.S. does work. “Good decisions come from experience, Experience comes from making bad decisions”, Mark Twain.
i totally agree 
Yep you are, or not?! 
Kidding aside, you’re almost there, and what you want to do, is exactly what an alert is for. You just didn’t walk along far enough.
Let me give you an example with code, it’s my refrigerator “high usage” alert.
binary_sensor:
- platform: template
sensors:
kitchen_refrigerator_high_usage:
value_template: "{{ (states('sensor.kitchen_refrigerator_power') | float(60) > 60) }}"
friendly_name: Kühlschrank braucht überdurchschnittlich viel Strom
icon_template: 'mdi:fridge-outline'
alert:
kitchen_refrigerator_high_usage:
name: Kitchen Refrigerator High Usage
entity_id: binary_sensor.kitchen_refrigerator_high_usage
state: 'on'
repeat:
- 180
- 5
can_acknowledge: true
skip_first: true
title: "*** ACHTUNG! ***"
message: >
Der Kühlschrank verbraucht überdurchschnittlich viel Strom!
Ist eine Türe nicht geschlossen?
notifiers:
- notification_refrigerator_high
Note: I need to change the template binary_sensor from the old legacy format to the new format, but that doesn’t matter, as it is just an example.
First, you need the binary_sensor to set the value, in my case over 60W power use. Than comes the alert, and that’s where you’ve stopped to soon.
For you it is important, to set the repeat values, and skip_first to true. This example activates the alert, if the power consumption get’s over 60W. The repeat set’s a time frame for 180 minutes where it is already on, but doesn’t send a message (skip_first: true), and after that 180 minutes it gives out a message every 5 minutes.
Sounds like what you want, doesn’t it? 
Questions? Go ahead, ask! 
1 Like
Maybe we are misunderstanding what your goal is.
If the value being observed is “bouncy” enough to be spamming you with notifications, then you might be better off just using an automation, which would allow you to throttle how often the notifications are sent. Or use the throttled automation to handle the first notification and an Alert (with skip_first) to handle the case where the value is above your threshold for a prolonged amount of time.
The hysteresis was mentioned because you mentioned “going up and down the threshold” yourself. I interpreted that as fluctuations. It can help distinguish for that. What you describe now is indeed not that.
I also mentioned the for: clause in triggers or conditions. That can tackle intermittent heating situations. With the for clause you can say: only if it has previously been off for xxx time (to get the first high), or the opposite, to detect following heating cycles if you have need for that. Personally I combine those with threshold sensors because I think they are easier to use because they are binary sensors. I use the threshold sensor as the place to store the settings.
damn guys, you are amazing, and i’m so sorry i couldn’t explain well…
Trying to put everything together, i was thinking to a modified version of @Didgeridrew 's solution, i can’t try right now but i’d like to share the idea: a template binary sensor that is toggled on by power consumption going over the specified threshold (and this is the same), but it’s toggled off by the binary sensor itself staying on for a specified time. Do you thin i can trigger the binary sensor using the binary sensor itself? so using a state trigger, something like this:
template:
- trigger:
- platform: numeric_state
above: 100
entity_id: sensor.instant_power_consumption
id: 'on'
- platform: state
entity_id: this_sensor_id (can i use something like "this.id"?)
to: "on"
for: "00:30:00"
id: 'off'
binary_sensor:
- name: Excess Power Consumption
state: "{{ trigger.id }}"
availability: "{{ states('sensor.instant_power_consumption') | is_number }}"
(untested!!)
do you think this can work?
basically this should filter out everything is happening between the first on value and 30 minutes…
thanks!
You can trigger on the state of the sensor itself, but you would have to use the actual entity ID since templating is not supported in a State trigger.
However, in this case you should just use auto_off…
template:
- trigger:
- platform: numeric_state
above: 100
entity_id: sensor.instant_power_consumption
id: 'on'
binary_sensor:
- name: Excess Power Consumption
state: "{{ trigger.id }}"
auto_off: "00:30:00"
availability: "{{ states('sensor.instant_power_consumption') | is_number }}"
Here is an example for my internet outage alert. Basically I want to be notified if it’s out for more than 60 minutes. For all my alerts I also include a boolean to enable / disable the alert. Here I use the skip first because if I look at a dashboard I do want to see the internet is out (via the template binary sensor). The other option is to not use skip first and instead use delay_on on the template binary sensor.
You may also that I do a negative compare of != on. This will cause an alert if the sensor goes unavailable.
input_boolean:
al_nw_internet_alert_enable:
name: nw_internet alert enable
binary_sensor:
- platform: template
sensors:
al_nw_internet_alert:
value_template: '{{ (states("binary_sensor.nw_internet") != "on" ) and is_state("input_boolean.al_nw_internet_alert_enable", "on") }}'
- platform: ping
host: google.com
name: nw_internet
scan_interval: 600
alert:
al_nw_internet:
name: nw_internet
message: 'ALERT {{state_attr("zone.home","friendly_name")}} nw_internet google.com unreachable for 60 minutes'
done_message: 'Cleared {{state_attr("zone.home","friendly_name")}} nw_internet google.com unreachable for 60 minutes'
entity_id: binary_sensor.al_nw_internet_alert
state: "on"
repeat:
- 60
- 240
can_acknowledge: true
skip_first: true
notifiers:
- sms_notifiers_all
- sms_telegram_admin
recorder:
include:
entities:
- binary_sensor.al_nw_internet_alert
- alert.al_nw_internet
- input_boolean.al_nw_internet_alert_enable
- binary_sensor.nw_internet
- sensor.nw_internet_last_disconnect
- sensor.nw_internet_ping_average
template:
- trigger:
- platform: state
entity_id: binary_sensor.nw_internet
from: "on"
to: "off"
sensor:
- name: "nw_internet_last_disconnect"
state: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }} "
sensor:
- platform: template
sensors:
nw_internet_ping_average:
value_template: >-
{{ state_attr("binary_sensor.nw_internet","round_trip_time_avg") }}
unit_of_measurement: ms