Alert Redux: a full, feature-rich replacement for the alert integration

Share your Projects! Custom Integrations
1

Introducing Alert Redux, a custom integration installable through HACS that replaces Home Assistant’s built-in alert integration. it’s just reached 1.0.0 after extensive smoke-soak testing on my own house.

Alert Redux card
Alert Redux card1500×1320 202 KB

Why?

The built-in alert had served me well for years, but it’s YAML-only, its conditions are limited to “an entity is in a state”, and there’s no good way to see in detail, acknowledge, or snooze alerts from a dashboard. It’s also effectively deprecated. Alert Redux keeps the same idea (an alert is an entity that nags you until it’s dealt with) and builds on it.

What it does

  • Eight kinds of alert: manual (fired and dismissed by your automations, and optionally ending by itself), state, threshold (with hysteresis), template, on/off (separate criteria for on and off), alert state (e.g. “unacknowledged for 30 minutes”), trigger, and bus event.

  • Configured entirely in the UI, with no YAML requirement.

  • A Lovelace card that ships with the integration (no separate install). It shows every firing alert coloured by priority, with acknowledge, snooze, and dismiss buttons, plus an admin card for disabling and suspending alerts.

  • Notifications through notifier groups: on, reminder, and done messages (all templates), with your choice of reminder schedule. On the mobile app they replace and clear each other, and carry actionable buttons: Acknowledge, Snooze, and your own (a Close door button on Garage Door Left Open, say). There’s also throttling for flapping alerts, quiet hours for loud notifiers such as TTS or Amazon Echo announcements, and retries with a fallback if a notifier fails.

  • Supersession: Door Left Open can supersede Door Open, so you’re not told twice. Acknowledging one can preemptively acknowledge or snooze the other, so if you know you’re going to be leaving the door open, you can snooze the entire alert chain immediately.

  • Generators: one alert per matching entity, such as every lock, every battery, or everything with a given label. Alerts are added and removed automatically as entities come and go.

  • Missing data handled properly: an unavailable sensor shows as No data rather than silently looking fine, and a brief dropout doesn’t end a firing alert.

  • Easy to build on: events for every change, seven summary sensors (e.g. the highest unacknowledged priority, for a status light - including, but not limited to, those provided by Accent and Signal Light), Activity/logbook entries showing who acknowledged what, and state that survives restarts.

  • An agent skill: if you use an AI agent with Home Assistant (e.g. through HA-MCP), the repo includes a skill that teaches it how to set up and manage alerts.

Admin card
Admin card1500×3304 415 KB

Installing and Links

Alert Redux isn’t in the default HACS store yet, so add it as a custom repository:

Open in HACS

Or, in HACS, add https://github.com/arkane-systems/ha-alert-redux as a custom repository of type Integration. Then install it, restart, and add Alert Redux from Settings → Devices & Services. It requires Home Assistant 2025.3 or later.

Feedback is very welcome, here or on GitHub.

How you could help development

Any use and testing, reports of bugs, feature requests, and so forth are obviously welcome, but here are a couple of specifics:

  • I don’t have an Android phone available, so I haven’t been able to test Android notifications or custom buttons against the Android version of the Home Assistant mobile app. Any reports in this area would be particularly welcome.
  • When voice controls ship in 1.1, for similar reasons, any reports against Assist via voice (I myself use it only via a text chat channel) or against the voice proxies via Google Home would also be particularly welcomed.

What’s next

Voice control (Assist commands, and proxy switches for Alexa and Google Home) is next, followed by card filters (by area and label, e.g. a per-room alerts card), an acknowledgement queue, export/import, and a converter for existing alert: YAML.

Inspiration and Acknowledgements

Many thanks to Alert2, the integration which showed us just how good alerts on Home Assistant could be and inspired many of the features of Alert Redux.

Thanks also to weather_alerts_card, which inspired the alert card’s look.

Apologia Pro Mea Intellegentia Artificiali

I used Claude Code (Opus and Sonnet) extensively to build first the specification, and then the integration. Title aside, I make no apology for this; I spent a couple of decades of my career writing software the old-fashioned way, and now I’m using the best tools currently available to me, just like I did then. I have read the code, extensively tested the code, and the code works.

Which is to say that this is not, by any reasonable standard, “vibe-coded slop”.

If you still don’t want to use it because an agent touched it, that’s up to you, and why I made this disclosure.

Enjoy

Enjoy! (Then tell your friends.)

3 Likes
2

Neat! Makes me think about what features I haven’t gotten around to implementing in Alert2 that might be easier to implement in your spec+AI-based approach.
J

1 Like
3

Some late additions:

We shipped at 1.0.0, but hadn’t finished everything quite yet; now we’re at 1.3.0, which includes everything in the original batch of ideas and where we slow down a bit until the issues and feature requests come in.

This now includes

  • Voice control (both in detail for Assist and functional for Alexa and Google Home)
  • Latched alerts (stay around until acknowleged, even if they’re no longer firing)
  • Card filters (to let you set up individual per-area alert cards)
  • And a passel of other minor features. But most importantly –

The Alert Redux wiki, walking you through the setup and providing a rich cookbook of example alerts for all the alert types and features, along with examples of how to build on top of it.

Enjoy!

4

I’ve really come to enjoy co-developing with Claude Code, I must say.

I doubt I’m ever going to love the products of as-you-go “vibe coding”, but if you’re already a developer, get your design in place first, and keep an eye on the architectural decisions and code written along the way, you can get some really amazing results out of it.

(Certainly a lot more efficiently that I can hand-write that much Python of consistent quality.)

5

I’m hoping one of you will be able to provide something specific for notifications, namely user-controlled distribution of notifications.

For alert handling, I looked into Alert2 some time ago, and found it promising but rather complex, and suspect that Alert Redux may be similar. But I should probably look again.

Meanwhile, the thing I really want, is easy control of where notifications go. The Ticker integration looked exactly like what I needed. Unfortunately, a critical part of it has never worked for me, and I’ve asked for help several times, but there hasn’t seemed to be any activity around the distro for months.

So if one of you incorporates functionality something like Ticker in your AlertX tool, it would be fantastic. Basically, I’m looking for the ability to send notifications (from AlertX tool or from my own automations), to a single place, with a minimal amount of parameterization to signify classification / urgency / etc. And let the users individually decide whether they want to receive particular types of alerts, and how they want them delivered: target devices (e.g., phone / smart speakers), ACK / snooze options, queuing, etc.

So I’ve been trying to figure out combinations of tools, something like Alert2 plus Ticker plus maybe Notiscript. But it would be so nice if it was all in one tool. I’d be more than happy to provide testing / user feedback for notification handling.

6

This integration is fantastic considering how new it is. Clearly a lot of thought went into the design. This is going to replace a bunch of hard to maintain stuff I’ve made for temperature and water alerts. Thank you!

I see the alert/generator name is used for the email notification subject. Is there a way to have a different subject for alert triggered vs cleared events? I unsuccessfully tried this in the alert name template:

{% if (state_attr(entity_id, ‘fire_count’) | int(0)) > 0 %}
Temp Alert: {{ state_attr(‘zone.home’, ‘friendly_name’) }}: {{ area_name(target) }}
{% else %}
Temp Alert Cleared: {{ state_attr(‘zone.home’, ‘friendly_name’) }}: {{ area_name(target) }}
{% endif %}

although the template value works fine:

Temp Alert: {{ state_attr(‘zone.home’, ‘friendly_name’) }}: {{ area_name(target) }}

7

Thank you kindly for the compliment, and I’m glad Alert Redux is solving problems for you.

Regarding the e-mail issue - just to check, are you using the built-in SMTP integration for e-mail delivery? That’s what I based the rest of this on, but I know there are some custom e-mail integrations out there.

Unfortunately, SMTP uses the new-style notification system, which means that it takes no parameters but pass along title and message, and there’s no way to override it.

(Your trick with the alert name template is clever, but unfortunately can’t work: the generator uses that template to give the alerts names when it makes them, but it only recomputes the names when the generator’s edited or the target list changes, so it never runs when it matters.

Also, the rename would affect things like the entity ID and so forth, so there would be awkward consequences downstream.)

I think there’s a good idea for an added feature (title customization) here, though. I don’t know when I’ll be able to add it, but I’ve opened a GitHub issue to track it as something for the next feature release I do.

But, in the meantime, I have a workaround for you. Alert Redux exposes alert state in entity attributes and events, so you should be able to get close to what you want with just one automation:

alias: Temperature alerts by email
description: >-
  Emails Alert Redux's temperature alerts, with one subject when an alert
  fires and another when it clears.
mode: queued  # not "single": several alerts can fire or clear at once
max: 25
triggers:
  - trigger: event
    event_type: alert_redux_fired
    id: fired
  - trigger: event
    event_type: alert_redux_ended
    id: ended
conditions:
  # Only the alerts made by the temperature generator. Check the exact
  # sensor name in the generated_by attribute of one of your alerts.
  - condition: template
    value_template: >-
      {{ state_attr(trigger.event.data.entity_id, 'generated_by')
         == 'sensor.alert_redux_generator_temperature' }}
  # An alert that fires again while still firing sends alert_redux_fired
  # again, with a higher fire_count. Email only the first.
  - condition: template
    value_template: "{{ trigger.id == 'ended' or trigger.event.data.fire_count == 1 }}"
variables:
  alert: "{{ trigger.event.data.entity_id }}"
  home: "{{ state_attr('zone.home', 'friendly_name') }}"
  # The alert's own area (generators put it in its target's area by
  # default), else the area of the entity it's about.
  place: >-
    {{ area_name(alert)
       or area_name(state_attr(alert, 'subject_entity'))
       or trigger.event.data.name }}
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: fired
        sequence:
          - action: smtp.send_message
            target:
              entity_id: notify.my_email
            data:
              title: "Temp Alert: {{ home }}: {{ place }}"
              # The alert's own on message, as rendered for the card.
              message: >-
                {{ state_attr(alert, 'message')
                   or trigger.event.data.name ~ ' is firing.' }}
      - conditions:
          - condition: trigger
            id: ended
        sequence:
          - variables:
              duration: >-
                {% set s = trigger.event.data.duration_seconds | int(0) %}
                {%- if s < 60 %}{{ s }} seconds
                {%- elif s < 3600 %}{{ s // 60 }} minutes
                {%- else %}{{ s // 3600 }} h {{ (s % 3600) // 60 }} min{% endif %}
          - action: smtp.send_message
            target:
              entity_id: notify.my_email
            data:
              title: >-
                {{ 'Temp Alert Cleared' if trigger.event.data.reason == 'resolved'
                   else 'Temp Alert Ended' }}: {{ home }}: {{ place }}
              message: >-
                {{ trigger.event.data.name }}
                {%- if trigger.event.data.reason == 'resolved' %} cleared
                {%- elif trigger.event.data.reason == 'no_data' %} stopped: its sensor stopped reporting
                {%- elif trigger.event.data.reason == 'disabled' %} was disabled
                {%- else %} was dismissed{% endif %} after {{ duration }}.

You’ll need to remove the e-mail notifier from the Alert Redux config to avoid duplicates, and fill in your own e-mail entity name and generator sensor name.

Hope this helps!