Repeating Alert Notifications - ideal for doors, windows, locks, etc
🚀 Version 2026.02.27.26c
- ADDED: Final Notification and Actions
- Fixed: Timeout conflicts. Make sure to read each setting description to know how it works!
- recent: Restart Survival... great for long time frames
- IMPORTANT... Automations prior to 18c need to be recreated.
Author: LTek
📖 Community Discussion, Help, and Details... https://community.home-assistant.io/t/repeating-alert-notifications/888294
**FEATURES**
⚡ Advanced Triggering — Any trigger type (state, numeric, template, event) with optional conditions and restart mode
🔄 Restart Survival — Optional Timer + Text helpers preserve the repeat countdown and count across HA restarts
❌ Notification Clearing — Dedicated clear trigger, auto-clear delay, and user-defined Notification ID to replace or clear alerts across automations
♻️ Repeating Alerts — Configurable repeat limits, intervals, and optional repeat counter appended to title
⏱️ Timing Controls — Initial delay before first alert, repeat intervals, and auto-clear delay after last repeat
🎬 Actionable Buttons — Up to 3 buttons + optional cancel, button timeout, and failsafe auto-action if all repeats go unanswered
📲 Multi-Device Delivery — Send to multiple mobile devices simultaneously
💬 Customizable Notifications — Templated titles and messages with built-in variables (see below)
👇 Tap Action — Open dashboards, URLs, or specific app views on notification tap
✅ Android and iOS Specific Options — Android icon, color, persistence, and channel; iOS interruption levels and sounds
💥️ Custom Actions — Run your own actions on first trigger, on each notification, and on clear
**📖 Available Variables (use in Notification ID, title, and message)**
- `{{ now().strftime('%I:%M %p') }}` — Local time (e.g. 3:45 PM)
- `{{ now().strftime('%A') }}` — Day of week (e.g. Tuesday)
- `{{ now().strftime('%Y%m%d') }}` — Date stamp (e.g. 20260219)
- `{{ trigger.entity_id }}` — Entity that fired the trigger (if state-based)
- `{{ states('sensor.my_sensor') }}` — Current state of any entity
- `{{ trigger_entity_state }}` — State of the triggering entity at the time of trigger (e.g. on, off, open)
- `{{ time_since_trigger }}` — Time elapsed since trigger entity last changed (e.g. 4 min 32 sec ago), updates on each repeat
- `{{ friendly_name }}` - Friendly Name of the triggering entity or the user custom version
- `{{ trigger_entity_state }}` - Display the actual state that triggered the automation
**⚠️ Notification ID Note**
The Notification ID (tag) is used to replace or clear notifications on devices.
Sending a new notification with the same ID replaces the existing one.
A companion automation sharing the same Notification ID can send clear_notification to dismiss it.
If left blank, notifications cannot be replaced or cleared by this automation.
**⚠️ Action Buttons — How It Works**
Buttons appear on every notification including repeats. After each send the automation
waits up to the Button Timeout for a press before continuing.
- **Button pressed** → that button's action fires immediately, all remaining repeats are cancelled
- **Cancel pressed** → automation stops immediately, no actions fire
- **Timeout (mid-repeat)** → automation continues to the next repeat, no action fires yet
- **Timeout (final repeat)** → Auto Actions fire as a one-time failsafe, then the automation ends
Auto Actions are distinct from Custom Actions — Custom Actions fire on every notification,
Auto Actions fire only once after all repeats are exhausted with no button ever pressed.
I believe there is a bug if you select ONE entity to monitor:
choice 1: Error in 'if[0]' evaluation: In 'template' condition: TypeError: unhashable type: 'list'
If I take that one entity and put it in a group no errors are emitted.
Also I noticed a bug when you “slugify” the device. If your device is named “Dave’s iphone” it will try to call notify.mobile_app_dave_s_iphone but it should really be notify.mobile_app_daves_iphone. Again fix here is to put in a group.
When an alert has recovered and you call a custom Exiting Trigger State, do you think the alert should only send if a notification was sent? The way it is now, it send a notification anytime it changes state.
Here is code I propose:
- conditions:
- condition: trigger
id: delete_notification
- condition: template
# Only proceed if the alert has been active longer than the 'Initial Delay'
value_template: >
{{ (now() - state_attr('automation.' ~ this.entity_id, 'last_triggered')).total_seconds()
> (duration_issue_state.minutes * 60) }}
- condition: template
value_template: '{{ delete_notification }}'
sequence:
- variables:
repeat_count: 0
I think “Time Delay before Alert is Sent” setting covers that? It should delay the initial notification… so, for example if you do not want the first alert to happen for 10 minutes, it should not.
then, you also have “Delay Between Repeats” which handles the time delay between 1st-2nd-3rd, etc
Sometime soon I will update the blueprint to use a wider range of Triggers (not just on/off trigger), like I have for Conditions. At that time I’ll organize and update the descriptions so it is easier to understand how each Option works.
Hey I just wanted to say thanks for this blueprint. I have the Yolink garage tilt sensor on my garage door and for the longest time I had been using the native app for this purpose because it was really easy to set up.
I could, but didn’t feel like doing a bunch of conditional notifications that would repeat around 5-10 times. But this blueprint makes it just as easy as the app with additional features which I love.
Other than that the only other thing I have to say is that I hope you can include a garage-door-open icon in the Android Options section if possible lol.
Repeating Alert Notifications - ideal for doors, windows, locks, etc
