Nagging repeatable alert

A single “freezer is warm” push is easy to swipe away. This workflow nags: when a sensor enters an alert state it waits an initial delay, then sends a Companion notification, then keeps sending on a repeat interval until the sensor clears, you flip a dismiss helper, or a max-count is hit. When it clears for real, you get one resolved message.

Entity ids are blueprint inputs. Do not publish which door or freezer this watches.

This is the loop. Quiet-hours notification hub is the router (priority, who is home, hold-until-morning). Use this pack to decide that something is still wrong; point the notify action at the hub if you also want quiet hours.

What problem it solves

You want “keep telling me until it is fixed” — a freezer lid, a leak binary, a door left open — without writing a repeat by hand, and with a way to mute one incident without disabling the automation.

How it works

1. Enter alert — the watched entity goes to the alert state (pack default on). Complex criteria (temperature above 8 °C, battery below 15%, two contacts) belong in a template binary sensor; the blueprint only compares one entity to one state.
2. HA start — a second trigger on Home Assistant start, with a condition that the entity is still in the alert state. A reboot mid-loop would otherwise swallow the nag. The count restarts from zero after a start (the pack does not persist “already sent 2 of 5”).
3. Optional condition — a second entity must match a state before the loop runs (someone home, an input_boolean enable). Empty = always.
4. Initial wait — wait_for_trigger until the sensor leaves the alert state or the dismiss helper turns off, with timeout = initial delay. If the wait catches a clear/dismiss, no notify (a door shut at 90 seconds of a 2-minute delay stays silent). If it times out, the loop starts.
5. Repeat — up to max_alerts times: send the Companion message, run the optional extra action (TTS, a lamp), then wait repeat_delay for clear or dismiss. Each iteration re-checks the sensor and the dismiss helper so a late close stops the rest.
6. Resolved — after the loop, if the sensor left the alert state, send the resolved message and the optional resolved action. If the dismiss helper was flipped, log a dismiss and skip the “all clear” (you already know). Reset the dismiss helper to off so the next incident can nag again.

mode: restart so a flicker off-and-on starts a fresh initial delay instead of stacking loops.

Hardware notes

• No extra sensors required. Any binary (or a template binary) already in HA. A leak, a door, a freezer probe wrapped as on when too warm.
• Companion. The blueprint targets a mobile_app device. For a notify group or the quiet-hours hub, use the optional extra action (or the pack’s notify-service variant) instead of the single-device slot.
• Dismiss helper. An input_boolean. Optional, but the only way to mute one incident without fixing the sensor. Put it on a dashboard card or an actionable notification.
• Do not use this for momentary button classification. That is binary-sensor short/long press.

Snippet

The pack ships a blueprint. Inputs replace real entity ids:

mode: restart

trigger:
  - platform: state
    entity_id: !input sensor_entity
    to: !input alert_state
  - platform: homeassistant
    event: start

condition:
  - condition: template
    value_template: "{{ is_state(sensor_entity, alert_state) }}"
  - condition: template
    value_template: >
      {{ condition_entity == none
         or is_state(condition_entity, condition_entity_state) }}

action:
  - wait_for_trigger:
      - platform: template
        value_template: "{{ not is_state(sensor_entity, alert_state) }}"
      - platform: template
        value_template: >
          {{ dismiss_entity != none
             and not is_state(dismiss_entity, 'on') }}
    timeout:
      seconds: !input initial_delay
    continue_on_timeout: true
  - if:
      - condition: template
        value_template: "{{ wait.trigger == none }}"
    then:
      - repeat:
          count: !input max_alerts
          sequence:
            - condition: template
              value_template: "{{ is_state(sensor_entity, alert_state) }}"
            - service: !input notify_service
              data:
                title: "{{ alert_title }}"
                message: "{{ notify_message }}"
            - wait_for_trigger:
                - platform: template
                  value_template: "{{ not is_state(sensor_entity, alert_state) }}"
              timeout:
                seconds: !input repeat_delay
              continue_on_timeout: true
      # resolved / dismiss branches: full blueprint in the pack

Template binary for a threshold (not a live freezer name):

template:
  - binary_sensor:
      - name: Chest freezer warm
        state: "{{ states('sensor.chest_freezer_temp') | float(0) > 8 }}"

Setup outline

1. Confirm the alert entity in Developer Tools. If you need a threshold or two inputs, create the template binary first.
2. Create an optional input_boolean dismiss helper. Import the blueprint. Fill sensor, alert state, delays, max count, notify service, messages.
3. Force the alert state (or set a short initial delay and open a test door). Confirm: no push during the initial wait if you clear it; first push after the wait; repeats on the interval; clear → one resolved; dismiss helper → loop stops, no resolved.
4. Restart HA while still in alert: the nag starts again from the initial delay.

Troubleshooting

• No first push. Initial delay is longer than you waited, the condition entity is not in the required state, or the sensor never stayed in the alert state for the whole wait. Watch the automation trace.
• Only one push, then silence. max_alerts is 1, or the sensor flickered off between repeats (a noisy leak). Debounce the template binary; raise max if you want a longer nag.
• Never stops. The sensor never leaves the alert state and you did not set a dismiss helper or a max. Set a max (pack default a handful) so a vacation does not fill the phone.
• Night pages. This pack does not implement quiet hours. Either add a condition entity that is off at night, or send through the quiet-hours hub as low / critical.
• Count reset after a reboot. Expected. The start trigger re-enters the loop from zero. Persist a counter helper only if you truly need “already sent 3 of 5” across restarts; the pack’s default does not.

Credits

Based on the community blueprint Nagging/Repeatable Alert Notification. This write-up is an original overview of the initial-delay plus repeat-until-cleared loop, kept separate from the quiet-hours hub.