Generators

Generators: One Alert per Device

Twelve doors, thirty batteries, eight smart plugs that must stay on. Writing the same alert for each is tedious, and every new device needs remembering. A generator is one definition that makes an alert for every entity that matches its targets, and keeps the set up to date as entities come and go.

How a generator works

Add one with Add generator on the integration page (or the admin card). Choose the kind of alert it makes (State, On/off, Threshold, Template, or Alert state), and fill in that kind's form as usual, with two differences:

• There's no entity to watch: each alert watches its target. Templates get target (the entity ID) and target_name (its name), and the target is each alert's subject entity, so subject_entity_name works in messages too.
• A Targets section chooses the targets:

Criterion	Example	Matches
Labels	Monitored appliance	entities with the label, or whose device has it
Areas	Kitchen, Garage	entities in the area, or whose device is
Domains	lock	lock.*
Device classes	battery	entities with that device class
Entity ID pattern	binary_sensor.*_door	a glob on the entity ID
Excluded entities	sensor.phone_battery	never targets

An entity must match every criterion you set, and any value within each ("a sensor with device class battery, in the Kitchen or the Garage"). Disabled entities, configuration entities, and alerts themselves are never targets.

Each alert's name comes from the Alert name template; by default, the target's name followed by the generator's ("Front Door" + "Unlocked"). Its entity ID comes from the target and the generator.

Then:

• New entities that match get their alert at once; entities that stop matching (a label removed, a device deleted) lose theirs. After a restart, nothing is removed until the generator startup grace (5 minutes) has passed, so slow integrations don't make alerts come and go.
• Generated alerts are edited through their generator: on the admin card, a generated alert's Edit and Delete act on the generator. Saving the generator updates every alert it has made, keeping their states.
• If a target is renamed, its alert follows it, state and all.
• Each generator has a sensor, sensor.alert_redux_generator_<name>: the number of alerts, with their targets, the alerts, and any problems.
• The Area and labels section puts each alert in its target's area (Use the target's area, on by default) or a fixed one, and gives them all labels.

Recipes

Low batteries everywhere

A Threshold generator over domain sensor and device class battery. Full recipe: Low batteries everywhere.

Monitored appliances tripped

A Template generator over a label, {{ states(target) in ['off', 'unavailable'] }}. Full recipe: Monitored appliances tripped.

Every leak sensor

A State generator over the moisture device class, so each alert says which sensor is wet, with the same priority, groups, and button as Water leak.

format: alert_redux
version: 1
alerts: []
generators:
  - name: Leak
    kind: state
    priority: critical
    icon: mdi:water-alert
    target_state: "on"
    targets:
      domains: [binary_sensor]
      device_classes: [moisture]
    placement:
      area_from_target: true
    notifier_groups: [Phone, Speakers, Persistent]
    reminder_schedule: [5]
    message: Water detected by {{ target_name }}!
    done_message: "{{ target_name }} is dry again."
    buttons:
      - label: Shut off water
        action:
          - action: valve.close_valve
            target:
              entity_id: valve.main_water

Named "Kitchen Leak Sensor Leak" and so on by default; an Alert name template of {{ target_name }} alone may read better if your sensors are already named "Kitchen Leak".

Door open and left open, for every door

From a real home: the author's own pair of generators.

The door open, then left open pair, for every door that has the label Monitored door. The second generator supersedes the first generator: each door's Left Open alert supersedes the same door's Open alert (not every Open alert), with propagation Snooze for 4 hours.

	Door Open	Door Left Open
Kind	State, on	State, on
Priority	Notice	Warning
Alert name template	{{ target_name }} Open	{{ target_name }} Left Open
Delay before firing		10 minutes
Targets → Labels	Monitored door	Monitored door
Supersession → Supersedes		Generator Door Open, Snooze this alert for 4 hours
Area and labels	target's area, label Outside doors	the same

format: alert_redux
version: 1
alerts: []
generators:
  - name: Door Open
    kind: state
    priority: notice
    icon: mdi:door-open
    name_template: "{{ target_name }} Open"
    target_state: "on"
    targets:
      labels: [monitored_door]
    placement:
      area_from_target: true
      labels: [outside_doors]
    message: "{{ subject_entity_name }} is open."
    reminder_message: "{{ subject_entity_name }} has been open for {{ duration }}."
    done_message: "{{ subject_entity_name }} is closed."
  - name: Door Left Open
    kind: state
    priority: warning
    icon: mdi:door-open
    name_template: "{{ target_name }} Left Open"
    target_state: "on"
    delay_on: "00:10:00"
    targets:
      labels: [monitored_door]
    placement:
      area_from_target: true
      labels: [outside_doors]
    message: "{{ subject_entity_name }} has been left open."
    reminder_message: "{{ subject_entity_name }} has been left open for {{ duration }}."
    done_message: "{{ subject_entity_name }} has been closed."
    supersedes:
      - generator: Door Open
        propagation: snooze
        snooze_duration: "04:00:00"

In an import file, a generator relationship names the other generator by its name. Labels in targets and placement are label IDs: create the labels first (Settings → Areas, labels & zones → Labels), and check their IDs, which are usually the name in lower case with underscores.

A relationship can also name a fixed alert: then every generated alert supersedes that one alert.

Tips

• Start narrow. Try a new generator on one label or one area first, check the generator sensor's targets list, then widen it. A generator over every sensor of a device class can surprise you.
• Exclude the odd ones out, rather than making the criteria complicated: phones in a battery generator, the cat flap in a door generator.
• Labels are the most flexible target. "Every entity with the label Monitored appliance" says exactly what you mean, and you choose membership by labelling, from the entity's page.
• Generators make condition alerts only. Manual, Trigger, and Bus event alerts aren't per-entity in the same way: one Trigger alert with several entities in its trigger usually does the job (Motion while away).
• alert_redux.refresh_generator, given a generator's sensor, re-evaluates its targets at once. You shouldn't need it, as they follow changes by themselves, but it's there for debugging.