Home Assistant Water Leak Notifications: Repeat Until Checked

Q: Why not stop as soon as the sensor dries?

This guide keeps the incident open until inspection. Dry contacts alone do not establish that the leak source is fixed.

Q: Can I use this for several rooms?

Give each monitored location its own helper, two automations and reset script so clearing one location cannot clear another.

Q: Does clearing the incident reopen a water valve?

No. The reset only changes the incident helper and operates no valves.

Keep “needs inspection” separate from “wet right now”

A useful Home Assistant water leak notification should tell you where to look and keep the problem visible until you deal with it. For an existing wet/dry sensor, use a remembered incident, a repeating reminder and an intentional reset. Do not make “sensor is no longer wet” your only definition of “problem solved.”

The kitchen-sink example below uses three built-in pieces: a helper, which stores an on/off value; two automations, which react to changes; and a script, a saved sequence you run after inspection. One automation remembers detection. The other sends reminders. The script clears the incident only when the sensor reports dry.

This is an alert workflow for a sensor already connected to Home Assistant. If you are still choosing hardware, start with the water leak sensor comparison. Keep any independent local alarm working: Home Assistant, its sensor connection and phone delivery can each fail. This example operates no shutoff valves and makes no claim to prevent flood damage.

Researched from current Home Assistant and Companion documentation on October 2, 2026. The example logic was checked in an isolated Home Assistant 2026.9.4 instance using simulated sensor states and notification calls, with the reminder wait shortened for the test. This was not a tested home installation; no physical leak sensor, phone delivery or plumbing equipment was tested. The cover is an AI-generated residential illustration.

1. Check the sensor and one ordinary phone message

Current documentation calls this menu Settings → Tools; older releases label it Developer tools. Use an administrator account for setup, and use the matching States and Actions tabs on your installed version.

Open Settings → Tools → States and find your leak sensor’s entity ID, the name Home Assistant uses for that reading. The example uses binary_sensor.kitchen_sink_leak; replace it everywhere with yours.
Confirm the sensor uses the moisture class. Its underlying on value means wet; off means dry. The screen may display these as “Wet” and “Dry.” unknown and unavailable are separate states. See the official binary-sensor meanings.
Install and connect the Home Assistant Companion app on the receiving phone and allow notifications. In Settings → Tools → Actions, select your actual notify.mobile_app_… action. Send a message such as “TEST: kitchen leak notification.” Confirm that it appears on that phone, following the Companion notification setup.

Record that exact notification action. A successful action call is not proof that someone heard or read the message. If this basic test fails, fix phone notification delivery before building repeats.

2. Create the remembered incident

Go to Settings → Devices & services → Helpers → Create helper → Toggle. Name it “Kitchen leak pending.” Check that its ID is input_boolean.kitchen_leak_pending, or substitute the actual ID throughout the examples. Start with it off.

The Toggle helper normally restores its previous value after Home Assistant stops and starts. If you define it in YAML instead, do not force initial: false: that would discard the pending state on every start. Restoration is not a guarantee against lost data after a host or storage failure.

On means “needs inspection,” not “water is definitely present now.” Leave it on when the physical sensor becomes dry or unavailable. For everyday use, offer the guarded reset script from step 5 instead of encouraging people to switch this helper off directly.

3. Remember each wet report

In Settings → Automations & scenes, create a new empty automation. Open its menu, choose Edit in YAML, and replace the editor contents with the block below. This is one automation, not an entire configuration.yaml file. Save it after replacing the sensor and helper IDs. On a narrow screen, scroll code blocks sideways to see long lines.

alias: Kitchen leak - remember detection
triggers:
  - trigger: state
    entity_id: binary_sensor.kitchen_sink_leak
    to: "on"
  - trigger: homeassistant
    event: start
  - trigger: event
    event_type: automation_reloaded
actions:
  - condition: state
    entity_id: binary_sensor.kitchen_sink_leak
    state: "on"
  - action: input_boolean.turn_on
    target:
      entity_id: input_boolean.kitchen_leak_pending
mode: restart

The state trigger watches for on without requiring a previous off. That allows a sensor reconnecting while wet to raise the incident too. The condition inside the actions also checks the actual reading, including during a manual run.

A startup check and an automation-reload check catch a sensor already reporting wet. They cannot reconstruct a leak that began and ended entirely while Home Assistant was offline.

4. Repeat until the incident is cleared

Create a second empty automation and paste this into its YAML editor. Replace notify.mobile_app_your_phone with the action you tested. Keep both automations enabled.

alias: Kitchen leak - repeat notification
triggers:
  - trigger: state
    entity_id: input_boolean.kitchen_leak_pending
    to: "on"
  - trigger: homeassistant
    event: start
  - trigger: event
    event_type: automation_reloaded
actions:
  - repeat:
      while:
        - condition: state
          entity_id: input_boolean.kitchen_leak_pending
          state: "on"
      sequence:
        - action: notify.mobile_app_your_phone
          continue_on_error: true
          data:
            title: "Kitchen sink: inspect for a leak"
            message: >-
              A leak was detected and still needs inspection.
              Current sensor state:
              {{ states('binary_sensor.kitchen_sink_leak') }}.
              Clear the incident in Home Assistant after checking.
        - wait_template: >-
            {{ is_state('input_boolean.kitchen_leak_pending', 'off') }}
          timeout: "00:05:00"
          continue_on_timeout: true
mode: restart

Each run checks the helper before sending. It then waits up to five minutes, waking sooner if you clear the incident. The message includes the current sensor reading, so a disconnected sensor is not described as dry. The five minutes are the example’s reminder interval, not a measured delivery time.

Restart mode replaces an existing reminder run when a new trigger arrives. After startup or an automation reload, a pending incident starts a fresh run and may send again immediately; the old five-minute countdown is not restored. Saving another automation can also produce a reload event and an extra reminder.

The notification step uses continue_on_error so a handled send error can leave the repeat running. It does not repair invalid configuration or guarantee recovery from every failure. Inspect the trace and logs if sending fails. These behaviors use Home Assistant’s repeat, wait and error-handling building blocks.

For a second phone, duplicate the notification action immediately before the wait, using that phone’s tested action. Give each send its own continue_on_error: true. Test each recipient separately.

5. Add a reset button that requires a dry reading

Create a new script under Settings → Automations & scenes → Scripts. Use its YAML editor for this block, then add the saved script to a dashboard as a button named “Kitchen inspected: clear incident.”

alias: Kitchen leak - clear after inspection
sequence:
  - condition: state
    entity_id: binary_sensor.kitchen_sink_leak
    state: "off"
  - action: input_boolean.turn_off
    target:
      entity_id: input_boolean.kitchen_leak_pending
mode: single

Run the script only after checking the area and addressing the cause. The state condition stops the sequence unless the sensor reports exactly off. It cannot verify your inspection or detect water that never reaches the sensor. If the reading is wet, unknown or unavailable, the helper stays on and reminders continue. A stale off reading can still pass this check; confirm that the sensor is reporting properly as well as inspecting the area.

This example has no separate snooze. Swiping away a phone message does not clear the helper. Turning off the reminder automation suppresses delivery and leaves it disabled until you enable it again. If you do that while investigating, re-enable it and use Run actions to resume any pending reminder; do not leave it disabled for the next incident.

6. Rehearse with the real sensor left dry

Tell everyone receiving these messages that you are running a test. Keep the ordinary notification settings for this first rehearsal, and confirm the physical sensor reports dry.

Use the helper’s control to turn input_boolean.kitchen_leak_pending on. Expect the reminder automation to send a message naming the kitchen. It should show the current raw sensor state as off; that is intentional for this synthetic test.
Leave the helper on. Expect another send after the five-minute wait. Check the phone and the automation’s trace, not just a green “action ran” indicator.
Run “Kitchen inspected: clear incident.” With the sensor dry, the helper should turn off, the wait should finish, and no further repeat should be sent. A message already in transit may still arrive.
Turn the helper on once more, then save the reminder automation to exercise its reload path. Expect a fresh reminder while the incident stays pending. Clear the test again. Check restart recovery during your next planned maintenance window; do not interrupt critical routines just to test this guide.

This checks the stored incident and notification logic, not the sensor’s water detection or radio path. Afterward, follow the exact sensor manufacturer’s safe test procedure and confirm that the first automation turns the helper on. Do not create a real plumbing leak, wet powered equipment or disable another safety system for testing.

What each state should mean

The following is a walkthrough of the example’s intended behavior, not measurements from a home installation. On a phone, scroll the table sideways to see all three columns.

Situation	Expected behavior	What to do
The sensor reports wet.	The first automation sets the helper on; the second begins reminders.	Inspect the named location and follow your household response plan.
The sensor dries before anyone checks.	The helper stays on. Reminders say inspection is still needed.	Check the area before using the reset button.
An incident is pending and the sensor becomes unavailable.	The remembered incident stays on; the reset condition fails.	Check both the area and the sensor connection. Missing contact is not an all-clear.
A previously dry sensor becomes unavailable.	No leak incident is invented by this automation.	Use a separate unavailable-device reminder to find this gap.
Home Assistant restarts with a restored pending helper.	The startup trigger begins a new reminder run.	Expect a possible repeat immediately, rather than the remaining old interval.
The phone gets nothing, but the helper is on.	The incident is recorded, but that alone does not confirm phone delivery.	Inspect the send step, actual notify action and phone settings.

Make phone sound and offline behavior explicit

The example sends ordinary notifications. Before relying on it overnight, follow the platform-specific critical-notification instructions and repeat the harmless test with the phone locked. On iPhone, critical sound needs the appropriate payload and Critical Alerts permission. On Android, high priority and a zero time-to-live affect prompt delivery through push; they do not by themselves establish audible sound through Do Not Disturb. Alarm-stream, channel and phone settings are separate checks.

The incident logic runs on your Home Assistant server. Receiving the physical event without internet still requires a local sensor integration. Standard remote phone push uses external infrastructure; notification privacy and delivery limits still apply. Merely connecting the phone to Wi-Fi does not prove that you configured a working local delivery path. Check the Local Push requirements and connection status for your phone. Keep an independently functioning local alarm and test your actual arrangement.

Frequently asked questions

Why not stop as soon as the sensor dries?

That is reasonable if you specifically want a reminder only while water touches the sensor. This guide answers a different household rule: someone must inspect a recorded incident. Moving a sensor or drying its contacts does not establish that the source of the leak is fixed.

Can I use this for several rooms?

Yes. Give each monitored location its own pending helper, two automations and reset script, with unique names and matching IDs. This keeps a kitchen reset from clearing a bathroom incident. Do not add several sensor IDs to these examples without also designing which incident each reset is allowed to clear.

Does clearing the incident reopen a water valve?

No. The reset only changes the helper. Automatic shutoff, valve reopening, plumbing compatibility and manual operation require a separate design for the installed equipment.

For help planning local routines and everyday household controls together, see Tara’s home automation kit approach.