Skip to content

Building on Alert Redux

Alistair Young edited this page Oct 13, 2026 · 4 revisions

Building on Alert Redux

Alerts are entities, with states, attributes, and events, so the rest of Home Assistant can use them: dashboards, automations, lights, history. The rule of thumb: make the condition an alert, and hang everything else off the alert, rather than building a second alerting system out of template sensors and automations.

Dashboards

The main card

type: custom:alert-redux-card
title: Alerts

It shows every firing alert, most important first, with acknowledge, snooze, dismiss (for dismissable manual alerts), and the alert's own buttons. Superseded alerts fold under their superseders; alerts without data are listed at the bottom; disabled alerts are counted. Click an alert's name for its details.

Options, all optional (also in the card's visual editor):

Option Does
title the card's heading
snooze_durations the snooze menu, in minutes (default [15, 30, 60, 120, 240])
areas only alerts in these areas (area IDs)
labels only alerts with one of these labels (label IDs)
hide_acknowledged start with acknowledged alerts hidden
priorities start showing only these priorities

A card for each room

Give alerts an area (their Area and labels section, or the entity's settings page; generators can use their target's area), then put a card on each room's dashboard scoped to it:

type: custom:alert-redux-card
title: Kitchen alerts
areas: [kitchen]

areas and labels set the card's scope: alerts outside it are left out of the card entirely, including the no-data list and the disabled count. With both, an alert must match each.

A wall tablet for what matters

type: custom:alert-redux-card
title: Needs attention
priorities: [emergency, critical, warning]
hide_acknowledged: true
snooze_durations: [30, 60, 240, 1440]

priorities and hide_acknowledged set the starting state of the card's filter buttons, which anyone can change while looking at it; the card says how many alerts they're hiding.

The admin card

type: custom:alert-redux-admin-card
title: All alerts
page_size: 20

Every alert, firing or not, by priority, with its kind and state. Admins can add, edit, delete, disable, enable, and suspend alerts, and export and import them. Each row's Summary button describes the alert's settings in plain words.

Colours

The priority colours can be changed in a theme, with alert-redux-emergency-color, alert-redux-critical-color, alert-redux-warning-color, alert-redux-notice-color, and alert-redux-informational-color.

Other cards

Every alert carries the label Alert Redux, so any card that takes targets can cover all alerts, including ones added later. An Activity (logbook) card with that label as its target is an alert history: who acknowledged what, when things fired and ended, snoozes, suspensions, and supersession.

A signal light

Nine summary sensors summarise every alert, so an automation only needs to follow one entity:

Sensor State
sensor.alert_redux_highest_priority the highest priority among firing alerts, or none
sensor.alert_redux_highest_unacked_priority the same, among unacknowledged alerts (active or latched) that aren't superseded
sensor.alert_redux_firing how many are firing
sensor.alert_redux_active how many are unacknowledged (not counting superseded ones)
sensor.alert_redux_acknowledged how many are acknowledged
sensor.alert_redux_latched how many are latched
sensor.alert_redux_superseded how many a firing alert supersedes
sensor.alert_redux_no_data how many are missing data
sensor.alert_redux_disabled how many are disabled or suspended

Each count sensor lists its alerts in entity_ids.

A lamp in the hall that shows the most serious unacknowledged alert, and goes off when everything's been acknowledged:

alias: Alert signal light
triggers:
  - trigger: state
    entity_id: sensor.alert_redux_highest_unacked_priority
    not_to: [unavailable, unknown]
actions:
  - choose:
      - conditions: "{{ trigger.to_state.state in ['none', 'informational'] }}"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.hall_signal
    default:
      - action: light.turn_on
        target:
          entity_id: light.hall_signal
        data:
          color_name: >-
            {{ {'emergency': 'red', 'critical': 'orange', 'warning': 'yellow',
                'notice': 'green'}[trigger.to_state.state] }}

This one ignores Informational, so status alerts like Vacation mode on don't light it. Superseded alerts don't count, so acknowledging the alert you can see turns the light off.

A badge on a dashboard: an entity badge on sensor.alert_redux_active, with a visibility condition that it's above 0.

With Accent & Signal Light

From a real home: this is the author's own automation, driving the accent lights in the living areas.

A plain light has one owner: if the signal light automation turns it red, it doesn't know what to put back afterwards. If the same lamp is also an accent light (warm white in the evenings, dim during a film), the automations fight over it.

Accent & Signal Light (signal_light), another integration by Alert Redux's author, solves this. It wraps a light in three layers: a base layer (the light's ordinary state), accents (long-lived looks, such as movie mode), and signals (notifications). Each accent and signal has a name and a priority, and the highest one present controls the light. Clear a signal, and the light goes back to whatever is underneath: the film's dim glow, or off. No automation has to remember.

So Alert Redux becomes one named signal, alert_redux, whose colour and priority follow sensor.alert_redux_highest_unacked_priority, and which is cleared when nothing is left unacknowledged.

Translating priorities. Signal priorities are numbers. Mapping Alert Redux's five priorities to widely spaced values leaves room for other signals (a doorbell, a timer) to sit between them:

Alert Redux priority Signal priority Colour Lights off: wakes them? (wake priority 8000)
Emergency 10000 red yes
Critical 9000 orange yes
Warning 7000 yellow no
Notice 6000 green no
Informational 5000 blue no

The signal wake priority. Each Accent & Signal Light instance has a signal wake priority (set when it's added, or by reconfiguring it). While the base layer is on, any signal changes the light's colour. While it's off, only a signal whose priority is greater than the wake priority turns the light on; the others wait in the queue, and show as soon as someone turns the light on. With a wake priority of 8000, as here:

  • an Emergency or Critical alert lights the lamps even in an empty, dark room, or at 3 a.m.;
  • a Warning, Notice, or Informational alert only recolours lamps that are already on, so a door left open in the evening tints the room yellow, but nothing lights up at night for a flat battery.

Set the wake priority to 6500, say, to let Warnings wake the lights too, or 10000 for nothing but Emergencies. It's one setting, and the automation doesn't change.

The automation:

alias: Sync accent light signals with Alert Redux highest unacked alert
description: >-
  Mirrors sensor.alert_redux_highest_unacked_priority onto the accent lights. A new
  alert must hold for 10 seconds before the signal is set, so briefly active alerts
  (such as Door Open) don't flicker the lights. A change between two priorities is
  applied at once, and so is clearing.
mode: queued
triggers:
  - id: cleared
    trigger: state
    entity_id: sensor.alert_redux_highest_unacked_priority
    to: none
  - id: raised
    trigger: state
    entity_id: sensor.alert_redux_highest_unacked_priority
    from: [none, unavailable, unknown]
    not_to: [none, unavailable, unknown]
    for:
      seconds: 10
  - id: changed
    trigger: state
    entity_id: sensor.alert_redux_highest_unacked_priority
    not_from: [none, unavailable, unknown]
    not_to: [none, unavailable, unknown]
actions:
  - variables:
      priority: "{{ states('sensor.alert_redux_highest_unacked_priority') }}"
  - choose:
      - conditions:
          - condition: trigger
            id: cleared
        sequence:
          - action: signal_light.clear_signal
            target:
              entity_id: light.accent_lights_base
            data:
              signal_name: alert_redux
      - conditions:
          - condition: trigger
            id: [raised, changed]
          - condition: state
            entity_id: sensor.alert_redux_highest_unacked_priority
            state: [emergency, critical, warning, notice, informational]
        sequence:
          - action: signal_light.set_signal
            target:
              entity_id: light.accent_lights_base
            data:
              signal_name: alert_redux
              priority: >-
                {{ {'emergency': 10000, 'critical': 9000, 'warning': 7000,
                    'notice': 6000, 'informational': 5000}[priority] }}
              color_name: >-
                {{ {'emergency': 'red', 'critical': 'orange', 'warning': 'yellow',
                    'notice': 'green', 'informational': 'blue'}[priority] }}
              brightness_pct: 100
              transition: 2

How it works:

  • raised: from nothing to an unacknowledged alert. It waits 10 seconds, so an alert that's acknowledged (or ends) at once, such as a door opened and closed again, never reaches the lights.
  • changed: from one priority to another (an escalation, or acknowledging the top alert and leaving a lesser one). The colour changes at once.
  • cleared: everything acknowledged. The signal goes, and the lights go back to the accent or base layer, or off.
  • set_signal with an existing name replaces that signal, so changing colour needs no clear first.
  • The action reads the sensor's current state rather than trigger.to_state. That matters for raised: if the priority changes during its 10-second wait (a Warning, then a Critical), the trigger still fires at the end, but its to_state is from the start of the wait.
  • It's queued, so a change arriving while a run is finishing isn't dropped. The state condition skips a queued run whose alert has been acknowledged in the meantime (the cleared run behind it takes care of the light).
  • After a restart, Accent & Signal Light deliberately forgets its signals. The summary sensor comes back from unavailable to the current priority, which is a raised, so the signal is set again 10 seconds after Home Assistant starts.

Doing something when an alert fires

To react to Use
one alert starting, ending, being acknowledged a state trigger on the alert entity
why it ended, who acknowledged it, what fired it an event trigger on its alert_redux_* event
anything urgent, across all alerts the summary sensors

For automations that react to many alerts, or do something a notifier group can't (such as an email whose subject changes when the alert clears), see Reacting to Alerts, which also has a blueprint that does the groundwork.

Flash the lights red when there's smoke, using the alert's state:

alias: Smoke lights
triggers:
  - trigger: state
    entity_id: alert_redux.smoke_detected
    to: active
actions:
  - action: light.turn_on
    target:
      floor_id: [ground_floor, first_floor]
    data:
      color_name: red
      brightness_pct: 100
      flash: long

Unlock the doors for the fire brigade at the same time, or turn off the HVAC so it doesn't spread smoke: more actions in the same automation.

Log why things ended, using the events: every change fires an event (alert_redux_fired, _ended, _acked, _snoozed, and more), carrying the alert's entity_id, name, priority, the old and new states, and the user, if one made the change. alert_redux_ended adds the reason (resolved, dismissed, no_data, disabled) and how long it fired.

alias: Note long alerts
triggers:
  - trigger: event
    event_type: alert_redux_ended
conditions:
  - "{{ trigger.event.data.reason == 'resolved' and trigger.event.data.duration_seconds > 3600 }}"
actions:
  - action: logbook.log
    data:
      name: "{{ trigger.event.data.name }}"
      message: "cleared after {{ (trigger.event.data.duration_seconds / 3600) | round(1) }} hours"

Announce a new Emergency alert on the TV, for any alert:

alias: Emergency on the TV
triggers:
  - trigger: event
    event_type: alert_redux_fired
conditions:
  - "{{ trigger.event.data.priority == 'emergency' }}"
actions:
  - action: notify.living_room_tv
    data:
      title: "{{ trigger.event.data.name }}"
      message: "{{ state_attr(trigger.event.data.entity_id, 'message') }}"

(A simpler way: a TV notifier group, chosen by your Emergency alerts.)

Raise an alert from an automation that only an automation can detect: a manual alert, fired with alert_redux.fire and ended with alert_redux.dismiss.

Templates on alerts

Alert attributes are useful in templates elsewhere:

{# Names of everything firing and unacknowledged #}
{{ state_attr('sensor.alert_redux_active', 'entity_ids')
   | map('state_attr', 'friendly_name') | join(', ') }}

{# How long the freezer alert has been firing #}
{{ relative_time(as_datetime(state_attr('alert_redux.freezer_too_warm', 'firing_since'))) }}

Each alert has attributes such as priority, firing_since, fire_count, message (rendered, while firing), last_acked_by, snoozed_until, superseded_by, and for condition alerts missing_inputs; the README has the full list.

Using an AI agent

An agent that can reach your Home Assistant (for example through HA-MCP) can create and manage alerts for you, if it knows how. The repository includes an agent skill that teaches it: see the README. Ask it for any of the recipes in this wiki by name.

Clone this wiki locally