Devices and Infrastructure

Devices and Infrastructure

Alerts about your smart home itself: bridges and devices gone offline, integrations in trouble, errors, failed backups, power cuts, and flat batteries. Recipes run from simple to advanced; ● marks are explained on the Home page. Entity IDs are examples: change them to yours.

• Zigbee bridge down ●
• Device offline ●
• Integration in trouble ●●
• Errors in the log ●●
• Backup failed ●●
• Power cut ●●
• Monitored appliances tripped ●●●
• Low batteries everywhere ●●●

---

Zigbee bridge down

● Basic · State (or Template) · what "down" really means

From a real home: this is one of the author's own alerts, with its Z-Wave cousins as variations.

The problem. The Zigbee bridge has lost its connection. Every Zigbee sensor in the house has stopped reporting, so every alert that depends on one has gone quiet (or, in Alert Redux, no data). You want to hear about the cause, once.

Why this kind. Zigbee2MQTT has a connection state binary sensor, on while the bridge is connected. A State alert on off is the obvious answer. A delay before firing of a minute rides out a restart of Zigbee2MQTT.

But think about what happens when MQTT itself is down: the connection sensor isn't off, it's unavailable, and the alert has no data rather than firing. Alert Redux deliberately doesn't treat missing data as "everything's fine", but nor does it treat it as "fire". For a bridge, unavailable means down as well, so a Template that's true for anything but on covers both. That's the version below.

In the UI (Add alert → Template):

Field	Value
Name	Zigbee Bridge Down
Priority	Critical
Icon	mdi:zigbee
Template	{{ not is_state('binary_sensor.zigbee2mqtt_bridge_connection_state', 'on') }}
Delay before firing	1 minute
Notifications → On message	The Zigbee bridge is down. Please check it.
Notifications → Reminder message	The Zigbee bridge has been down for {{ duration }}. Please check it.
Notifications → Done message	The Zigbee bridge has been restored.

To import:

format: alert_redux
version: 1
alerts:
  - name: Zigbee Bridge Down
    kind: template
    priority: critical
    icon: mdi:zigbee
    template: "{{ not is_state('binary_sensor.zigbee2mqtt_bridge_connection_state', 'on') }}"
    delay_on: "00:01:00"
    message: The Zigbee bridge is down. Please check it.
    reminder_message: The Zigbee bridge has been down for {{ duration }}. Please check it.
    done_message: The Zigbee bridge has been restored.

What you'll see. A Critical alert a minute after the bridge goes, and a done message when it's back.

Variations.

• Z-Wave JS: the controller's status sensor is ready when all is well: {{ states('sensor.zwave_controller_status') != 'ready' }}. The author has one for each of two Z-Wave networks, and one network's template checks two entities (… or …).
• ZHA, or anything that just goes unavailable: the next recipe.
• When the bridge is down, the alerts on its sensors show no data, in their own section at the bottom of the card. This alert is the one that says why.

---

Device offline

● Basic · State · targeting unavailable

The problem. The smart plug on the chest freezer has dropped off the network, so you can't see its power use, and you'd want to know if the freezer stopped.

Why this kind. A State alert whose State is unavailable is an "offline" alert. It's the one case where an unavailable entity fires an alert rather than giving it no data. A delay before firing of 10 minutes ignores brief network hiccups.

In the UI (Add alert → State):

Field	Value
Name	Freezer Plug Offline
Priority	Warning
Icon	mdi:power-plug-off
Entity / State	switch.freezer_plug / unavailable
Delay before firing	10 minutes
Notifications → On message	{{ subject_entity_name }} has been offline for 10 minutes.

To import:

format: alert_redux
version: 1
alerts:
  - name: Freezer Plug Offline
    kind: state
    priority: warning
    icon: mdi:power-plug-off
    entity_id: switch.freezer_plug
    target_state: unavailable
    delay_on: "00:10:00"
    message: "{{ subject_entity_name }} has been offline for 10 minutes."

Variations. For every device that matters, rather than one alert each: a generator over a label, as in Monitored appliances tripped.

---

Integration in trouble

●● Intermediate · Template · a status sensor, a card message with the details

From a real home: the author's iCloud3 alert.

The problem. Presence tracking comes from the iCloud3 integration. When it has a problem, presence-based automations (arming the alarm when everyone leaves, say) quietly stop working. iCloud3 reports its problems in a sensor, sensor.icloud3_alerts, whose state is none when all is well, with the details in an attribute.

Why this kind. A Template on the status sensor, with a Card message that shows iCloud3's own description of the problem. The Subject entity is the status sensor. A two-minute delay ignores passing glitches.

Many integrations have something similar: a status, connectivity, or "problem" entity. The same recipe works for all of them.

In the UI (Add alert → Template):

Field	Value
Name	iCloud3 Problem
Priority	Critical
Icon	mdi:apple-icloud
Template	{{ states('sensor.icloud3_alerts') != 'none' }}
Delay before firing	2 minutes
Subject entity	sensor.icloud3_alerts
Notifications → On message	see the import file
Notifications → Card message	{{ state_attr('sensor.icloud3_alerts', 'message_text') or states('sensor.icloud3_alerts') }}
Notifications → Done message	iCloud3 is working again.

To import:

format: alert_redux
version: 1
alerts:
  - name: iCloud3 Problem
    kind: template
    priority: critical
    icon: mdi:apple-icloud
    template: "{{ states('sensor.icloud3_alerts') != 'none' }}"
    delay_on: "00:02:00"
    subject_entity: sensor.icloud3_alerts
    message: >-
      iCloud3 has a problem, so presence tracking (and presence-based arming)
      may be down:
      {{ state_attr('sensor.icloud3_alerts', 'message_text')
         or states('sensor.icloud3_alerts') }}
    display_message: >-
      {{ state_attr('sensor.icloud3_alerts', 'message_text')
         or states('sensor.icloud3_alerts') }}
    done_message: iCloud3 is working again.

What you'll see. The phone gets the explanation of why it matters; the card, where space is precious, gets just iCloud3's own message, which updates as it changes.

Variations.

• Home Assistant's own Repairs aren't entities, but many integrations' problems show as binary_sensor entities with the problem device class: a generator over that device class covers them all.
• Certificates about to expire: a Threshold on the certificate expiry sensor, with a Minimum of 14 (days).

---

Errors in the log

●● Intermediate · Bus event · event data, throttling

The problem. Something is logging errors, and you'd rather know before it matters.

Why this kind. Home Assistant can put each logged error on the event bus as a system_log_event. A Bus event alert fires on that event type, filtered by Event data (level: ERROR). Each error keeps it up for its duration, and a new error restarts the duration. And since errors come in storms, it's throttled: at most 3 on notifications in any 60 minutes, then one summary when things calm down.

This needs one line of YAML in Home Assistant itself (the one place this wiki asks for it), in configuration.yaml, then a restart:

system_log:
  fire_event: true

In the UI (Add alert → Bus event):

Field	Value
Name	Error Logged
Priority	Notice
Icon	mdi:alert-circle-outline
Event type	system_log_event
Event data	level: ERROR
Condition	{{ 'alert_redux' not in trigger.event.data.name }}
Duration	30 minutes
Notifications → Use the default throttle	Off
Notifications → Throttle: notifications / in minutes	3 / 60
Notifications → On message	{{ trigger.event.data.name }}: {{ trigger.event.data.message[0] }}

To import:

format: alert_redux
version: 1
alerts:
  - name: Error Logged
    kind: event
    priority: notice
    icon: mdi:alert-circle-outline
    event_type: system_log_event
    event_data:
      level: ERROR
    condition: "{{ 'alert_redux' not in trigger.event.data.name }}"
    duration: "00:30:00"
    throttle: [3, 60]
    message: "{{ trigger.event.data.name }}: {{ trigger.event.data.message[0] }}"

The condition leaves out Alert Redux's own errors, so a failing notifier can't set off an alert about itself.

What you'll see. The first error: a Notice with the logger's name and the message. More errors: more on notifications, until the third in an hour is marked "[Throttling starts]". After that, they're held, and when the rate drops you get one summary: "[Throttling ends] Fired 12× while throttled, …". The alert itself keeps firing throughout; only notifications are throttled.

Variations.

• Only one integration's errors: event_data can't match part of a name, so use the Condition: {{ trigger.event.data.name.startswith('homeassistant.components.zha') }}.
• Your own events: an automation or script can event anything, e.g. event: garden_irrigation_failed, and a Bus event alert can watch for it.

---

Backup failed

●● Intermediate · Trigger · an event entity, a reason in the message

The problem. Home Assistant's automatic backup failed last night.

Why this kind. Home Assistant has an event entity, event.backup_automatic_backup, whose event_type attribute is completed, failed, or in_progress, and whose failed_reason says why. A Trigger alert on that entity's state changing, with a Condition that the event was failed, fires on each failure. Its duration of a day keeps it up until you've had a chance to look.

In the UI (Add alert → Trigger):

Field	Value
Name	Backup Failed
Priority	Warning
Icon	mdi:backup-restore
Triggers	a State trigger on event.backup_automatic_backup
Condition	{{ trigger.to_state.attributes.event_type == 'failed' }}
Duration	24 hours
Notifications → On message	The automatic backup failed ({{ trigger.to_state.attributes.failed_reason or 'no reason given' }}).

To import:

format: alert_redux
version: 1
alerts:
  - name: Backup Failed
    kind: trigger
    priority: warning
    icon: mdi:backup-restore
    triggers:
      - trigger: state
        entity_id: event.backup_automatic_backup
    condition: "{{ trigger.to_state.attributes.event_type == 'failed' }}"
    duration: "24:00:00"
    message: >-
      The automatic backup failed
      ({{ trigger.to_state.attributes.failed_reason or 'no reason given' }}).

What you'll see. A Warning the morning after a failed backup, for a day, unless the next night's backup succeeds and you'd like it gone sooner: acknowledge it.

Variations.

• Let a successful backup end it: make it On/off, with the same trigger and a template on each side (event_type == 'failed' to turn on, 'completed' to turn off).
• Keep until acknowledged, so a failure on holiday is still there when you're back.

---

Power cut

●● Intermediate · State · keep until acknowledged

The problem. The mains power went off. Home Assistant is on a UPS, so it knows, but you're out. By the time you're home the power is back, and nothing tells you that the freezer was off for an hour.

Why this kind. A State alert on the UPS's "on battery" sensor, with Keep until acknowledged on. While the power's off, it's a Critical alert. When the power comes back, if nobody has acknowledged it, it latches: it stays on the card ("stopped 2 hours ago") and keeps reminding until someone acknowledges it.

In the UI (Add alert → State):

Field	Value
Name	Power Cut
Priority	Critical
Icon	mdi:power-plug-off-outline
Entity / State	binary_sensor.ups_on_battery / on
Keep until acknowledged	On
Notifications → On message	The power is off. UPS battery at {{ states('sensor.ups_battery_charge') }} %.
Notifications → Done message	The power is back on.{{ ' Check the freezer, then acknowledge this alert.' if latched else '' }}

To import:

format: alert_redux
version: 1
alerts:
  - name: Power Cut
    kind: state
    priority: critical
    icon: mdi:power-plug-off-outline
    latching: true
    entity_id: binary_sensor.ups_on_battery
    target_state: "on"
    message: The power is off. UPS battery at {{ states('sensor.ups_battery_charge') }} %.
    done_message: >-
      The power is back on.{{ ' Check the freezer, then acknowledge this alert.'
      if latched else '' }}

With Network UPS Tools, there may be no on-battery binary sensor: watch the UPS's status sensor instead, with State set to its on-battery value (look it up in Developer tools → States while the UPS is on battery; it's usually On Battery).

What you'll see. While the power's off: a Critical alert, reminding on the default schedule. When it's back: "The power is back on." If nobody acknowledged the alert while the power was off, it has latched, latched is true in the done message, and the message adds "Check the freezer, then acknowledge this alert." (The default done message adds "It's kept until acknowledged." by itself; a message of your own uses latched to say what it likes.) The alert stays, dashed on the card, until someone acknowledges it.

Variations.

• Escalate if the battery is getting low: a Threshold alert on the battery charge with a Minimum of 30 and the condition that the UPS is on battery, Emergency, to the Speakers.

---

Monitored appliances tripped

●●● Advanced · Template generator · targets by label, area from the target

From a real home: this is one of the author's own generators.

The problem. Several appliances are on smart plugs that must stay on (the freezer, the fridge, the fish tank, the network cupboard). If a plug is switched off by mistake, or drops offline, the appliance has stopped, and someone should know. And when a new one is added, it should be watched without another alert to set up.

Why this kind. A generator makes one alert per matching entity. Its targets are every entity with the label Monitored appliance: label a plug, and it gets an alert; remove the label, and the alert goes. The alert is a Template, {{ states(target) in ['off', 'unavailable'] }}, where target is each alert's own entity. The Alert name template names each one ("Fish Tank Plug Tripped"), and Area and labels puts each alert in its plug's area, and gives it labels of its own.

In the UI (Add generator → Template):

Field	Value
Name	Monitored Appliances
Priority	Critical
Icon	mdi:power-plug-off
Alert name template	{{ target_name }} Tripped
Template	{{ states(target) in ['off', 'unavailable'] }}
Delay before firing	2 minutes
Targets → Labels	Monitored appliance
Notifications → On message	{{ subject_entity_name }} appears tripped. Please check it.
Notifications → Reminder message	{{ subject_entity_name }} has been tripped for {{ duration }}. Please check it.
Notifications → Done message	{{ subject_entity_name }} has been restored.
Area and labels → Use the target's area	On

Create the Monitored appliance label first (Settings → Areas, labels & zones → Labels), and put it on the plugs (or their devices).

To import: (targets uses the label's ID, usually its name in lower case with underscores)

format: alert_redux
version: 1
alerts: []
generators:
  - name: Monitored Appliances
    kind: template
    priority: critical
    icon: mdi:power-plug-off
    name_template: "{{ target_name }} Tripped"
    template: "{{ states(target) in ['off', 'unavailable'] }}"
    delay_on: "00:02:00"
    targets:
      labels: [monitored_appliance]
    placement:
      area_from_target: true
    message: "{{ subject_entity_name }} appears tripped. Please check it."
    reminder_message: "{{ subject_entity_name }} has been tripped for {{ duration }}. Please check it."
    done_message: "{{ subject_entity_name }} has been restored."

What you'll see. One alert per labelled plug, each named after it, each in the plug's area. sensor.alert_redux_generator_monitored_appliances counts them, and lists the targets and any problems. Label another plug, and its alert appears within moments.

Variations. Much more on generators, including excluding entities and supersession between generators: Generators: One Alert per Device.

---

Low batteries everywhere

●●● Advanced · Threshold generator · targets by domain and device class

The problem. Thirty battery-powered sensors, any of which may go flat, and each one going flat quietly breaks whatever depends on it.

Why this kind. A Threshold generator with targets domain sensor and device class battery: every battery level sensor, now and in future. A Minimum of 15 %, and hysteresis 5, so it only ends once the battery is above 20 % (a new battery). Notice priority and a daily reminder: this is a chore.

In the UI (Add generator → Threshold):

Field	Value
Name	Battery Low
Priority	Notice
Icon	mdi:battery-alert
Alert name template	{{ target_name }} Low
Minimum	15
Hysteresis	5
Targets → Domains	sensor
Targets → Device classes	battery
Targets → Excluded entities	phones and tablets, e.g. sensor.alices_phone_battery_level
Notifications → Reminder schedule	1440 (Use the default reminder schedule off)
Notifications → On message	{{ target_name }} is at {{ states(target) }} %. Time for a new battery.
Area and labels → Use the target's area	On

To import:

format: alert_redux
version: 1
alerts: []
generators:
  - name: Battery Low
    kind: threshold
    priority: notice
    icon: mdi:battery-alert
    name_template: "{{ target_name }} Low"
    minimum: "15"
    hysteresis: 5
    targets:
      domains: [sensor]
      device_classes: [battery]
      exclude: [sensor.alices_phone_battery_level]
    placement:
      area_from_target: true
    reminder_schedule: [1440]
    message: "{{ target_name }} is at {{ states(target) }} %. Time for a new battery."

What you'll see. An alert for every battery below 15 %, named after its sensor ("Hall Motion Battery Low"), in its room, reminding daily. The card can show just one room's, with its areas option.

Variations.

• Phones charge and discharge daily: exclude them, or use a pattern that only matches your sensors.
• Binary battery sensors (binary_sensor with device class battery, on = low): a second, State generator on on.
• More on generators: Generators: One Alert per Device.