Is there a native/built-in way in Home Assistant to debounce notifications or prevent sending duplicates within a time window?
What I'm looking for is essentially: "don't send this notification if the same one was already sent in the last X minutes."
I know I can build this with helpers — input_booleans, input_datetimes, timers, etc. — but it feels like a lot of boilerplate for something that should be a common pattern. Every automation that sends notifications ends up needing its own little state machine to avoid spamming.
Is there something built into the notification system or automations engine that I'm missing? Or is the helpers approach really the canonical way to do this?
If you are using an automation or script, you can throttle it with a Template condition that checks the last_triggered attribute of the entity using the built-in this variable:
alias: Prevent automation from running more than once per hour
condition: template
value_template: |
{{ this.attributes.last_triggered | default(as_datetime(0), 1) < now() - timedelta(hours=1) }}
Depending on the trigger, you may also be able to use the trigger variable to check whether the monitored entity was in its previous state for a certain amount of time.
alias: The triggering entity was in its previous state for at least 30 minutes
condition: template
value_template: >
{{ now() - trigger.from_state.last_changed >= timedelta(minutes=30) }}
If you wanted to take it even further, you could set up a trigger-based template sensor to store the last n notifications with timestamps, then have your automations checked against that history before sending a new message.
The first two approaches are too simplistic for my case, but this one sounds interesting. Still, it seems to require a helper template sensor? Or is it backed in the automation?
I find frustrating how detached the "persistence" for the automations is from the place where you define the automations.
If your automation mode is in single then you can just add a x minute delay at the end of the automation.
That will prevent the automation from running again while the delay is active
But that is NOT what I want.
I have a Co2 alert, that sends me notifications. I have 5 triggers based on ranges, and currently I "store" the value of the last trigger in a helper and check against it before sending the notification.
If the Co2 values change within 1 minute, I want the notification. I only want notifications when the value moves from one range to another, a timeout will allow duplicated notifications after the timeout.
I already have this problem solved with a helper, but I find annoying to have to go to a completely separate part of HA to add a little bit of state that i need for my automation, for every automation
Have you considered using a template sensor to quantize the Co2 value and have your automation trigger off that instead of having 5 different triggers? By doing so, you would probably cut down on the number of trigger events; and it would make it easier to check that the value was increasing or decreasing if that's something that would help you filter out some triggers.
Another option would be to use the File integration to store the data then have your automations call file.read_file and check the response.
There may be a way to do it using a SQL query action, but that's outside my wheelhouse.
Others may disagree, but my mental model of HA is that there are only three things:
State
Events
Logic
State can be relate to physical sensor/devices, be persisted and/or be calculated.
Events typically happen when state changes, although some things can directly generate events such as a button press.
When an event occurs, it can directly update state and/or it can trigger logic to start executing.
Logic can create new events and/or it can change state.
The line between Events and State can be fuzzy, for example if you turn a light on there is a change in state (the light is now on) but there is also an event which is sent to the switch to turn it on.
HA does a pretty good job of separating these three things, for example in an automation you have three sections:
Triggers - basically responses to event.
Conditions - check on state
Actions - the logic you want to execute.
Once you accept that in HA, state and logic are isolated it becomes much easier to accept the HA way of doing things.
Finally if you really can't tolerate the separation you can use trigger based templates, that allows you to persist state at the end of every execution.
My frustration arises from the fact that I'm in the middle of an automation and I need to open a new tab to create a new helper, which requires 4 or 6 clicks, then go back to the automation. And when I delete the automation, I need to remember to delete the helpers, and HA doesn't help you telling "this helper is not used" or anything like that.
What do you mean? How can I do that? I have triggers that are templates, but I'm not sure what do you mean by that
This is neat, but you are not building automations anymore. This are templates that you can "abuse" to treat them as automations. But I guess they don't have the same tracing and other semantics that automations enjoy.
UI support - your editing files on the file-system.
Execution modes - they always run as "Single"
Tracing (ish **)
** - You can mirror them with convention automations to debug, but its hassle cutting&pasting back and forth.
Another option is to store values in text fields as JSON instead of just strings.
With a bit of wrapper code you can store multiple values in a single text field.
However text fields are limited to 255 characters, so you have to keep your "variable names" short and you are still limited to 10-20 of them.
Another problem with this approach is that you can potentially get unwanted updates since the raw text box is updated whenever any key in the JSON is changed.
I have also experimented with using MQTT, but the read back on that is also limited to 255 characters.
I think it would be possible to build some external code to "watch" an update topic and dynamically create new devices as a result of setting values (read: autodiscovery), I think that would solve (almost) all of the issues with state management in HA.
However there would still be a timing issue, in that it will take a non zero amount of time to post a MQTT message and receive the update back from the external code, so that opens up the possibility of race conditions.
