Flood Sensors: Kitchen, Bathroom, Washer, Dishwasher, Boiler Room, and a Water Valve
Flood Sensors: Kitchen, Bathroom, Washer, Dishwasher, Boiler Room, and a Water Valve
You already have the notification channel and the escalation template from Lessons 2 and 3. Now you're wiring up the first real scenario: water detected → close the valve → trigger the security alarm. This is the lesson where HA genuinely limits damage, not just sends a push.
We're not starting by buying ten sensors. We're starting with the riskiest spots in your home: the washing machine, the dishwasher, the sink, the toilet, and the boiler room. Every spot only makes sense once you know what happens after water is detected.
Plan on about 90 to 110 minutes. If you don't have a water valve yet, you'll build the automation with a siren and an alarm; you can add the valve later without rewriting the logic.
The rule for this lesson
For flooding, the first response should be local.
Shutting off the water matters more than the push to your phone.
A real-life problem: water is running, and you're away from home
A supply hose on the washing machine bursts. Water's been dripping for twenty minutes. The sensor under the washer flips to on. Home Assistant is running locally. The internet went down after a storm. The push doesn't go out. If all you have is a notification, the damage keeps growing. If you have a water valve controlled from HA, the system can shut off the supply before you get home.
This scenario pulls together everything from the previous lessons: local response, escalation, SMS as a second channel, and alarm acknowledgment. Lesson 4 adds the sensor and the valve; the rest of the chain already exists inside script.flood_alarm.
What's actually the risk
A sensor in the wrong spot: it detects water too late, or never, because it's sitting next to the leak source instead of underneath it.
Notification only, no valve: you know about the flooding, but the water's still running.
A valve with no test and no manual override: it closed during a false alarm and you don't know how to open it.
A sensor offline or on a low battery: the entity stays silent, and you assume everything's fine.
A false alarm from mopping the floor: the valve shuts off the water because someone spilled a cup near the sink.
Where to mount flood sensors
A flood sensor is usually a small device with contacts on the bottom. It triggers once water closes the circuit between the contacts. Mount it where water reaches first: not in the middle of the room.
| Location | Where to place the sensor | Typical leak source |
|---|---|---|
| Bathroom / washing machine | Under the washer, at the back or side, near the hoses | A gasket, the supply hose, the drain trap |
| Kitchen / dishwasher | Under the dishwasher or under the sink | The dishwasher hose, the sink drain trap |
| Bathroom / sink, toilet | Under the vanity cabinet or near the toilet's mounting frame | A drain trap, a seal, an overflow |
| Boiler room | Under the boiler, the tank, or the water filters | Condensation, a leaking fitting |
The dishwasher lives in the kitchen, not the bathroom
Keep this consistent in your risk map and your entity names: the dishwasher is a kitchen appliance, the washing machine is usually in the bathroom. Good names make for a clear alert.
Which sensors to choose
In this course we assume Zigbee or Wi-Fi sensors that integrate with Home Assistant and create a binary_sensor.* entity. You don't need to standardize on one brand: what matters is that every sensor has a stable connection, reports its battery, and has a sensible name.
Zigbee: low power draw, integrates well with Zigbee2MQTT or ZHA, a plugged-in sensor can act as a mesh router.
Wi-Fi: a simpler start, but every device adds load to your network; check its battery reporting or power source.
Wired: less common at home, but very reliable in a boiler room with constant power.
Which entities we're watching
Once your sensors are paired, write down the entities in Developer Tools. The names below are examples; yours will have different endings.
| Entity | Meaning |
|---|---|
binary_sensor.bathroom_washer_leak |
Water under the washing machine in the bathroom |
binary_sensor.kitchen_dishwasher_leak |
Water under the dishwasher in the kitchen |
binary_sensor.bathroom_sink_leak |
Water near the sink or the toilet |
binary_sensor.boiler_room_leak |
Water in the boiler room |
switch.water_valve |
The main electric shutoff valve: on = water flowing |
group.flood_sensors |
A group of every flood sensor, for the dashboard |
Check your valve's direction before automating it
The entity might be valve.*, switch.*, or cover.*. off doesn't always mean "closed." For a valve entity, use valve.close_valve and wait for the closed state. Only send a "valve closed" message once the state is confirmed.
A water valve: when it's worth it
An electric valve on the main water supply lets Home Assistant shut off the water locally. It's the most effective response to flooding, as long as the valve is installed correctly, has a manual bypass or an easy way to open it, and has power.
The safest setup is one where the automatic valve never takes away your ability to act manually. A household member should know where the valve physically is, how to open it after a false alarm, and what to do if Home Assistant isn't working.
What happens on a power outage?
Check how your valve behaves when the power fails. Normally-open (NO) and normally-closed (NC) valves react differently: some stay in their last position, others return to a defined state. That matters during a power failure. If you need the valve and Home Assistant to work with no power, you need backup power.
The valve is a plumbing decision
If you don't have plumbing experience, hire a professional to install the valve. In this lesson, you're building the HA logic. You can start with the switch.water_valve entity replaced by a test helper or a simulator plug, so you can validate the automation without a physical valve.
The response sequence for flooding
1. Water detected: the sensor flips to on.
2. Close the valve: if the water automation is enabled and this isn't a test.
3. Security alarm: you call script.flood_alarm with a clear title and location.
4. Escalation from Lesson 3: push, SMS, repeats, acknowledgment: with no duplicated logic.
Helpers and a sensor group
input_boolean:
auto_close_water_on_flood:
name: "Auto: close the water on flooding"
icon: mdi:valve-closed
initial: true
flood_test:
name: "Flood test"
icon: mdi:water-alert
group:
flood_sensors:
name: "Flood sensors"
entities:
- binary_sensor.bathroom_washer_leak
- binary_sensor.kitchen_dishwasher_leak
- binary_sensor.bathroom_sink_leak
- binary_sensor.boiler_room_leakauto_close_water_on_flood lets you disable the automatic water shutoff without disabling the whole alarm. While mopping the floor, or during a test, you can briefly uncheck this helper. flood_test runs the same scenario with no physical water: the valve won't close.
Automation: flooding detected
This is the heart of the lesson. The automation doesn't duplicate the escalation: it calls the ready-made script from Lesson 3. That way flooding, smoke, and open doors all share the same alarm mechanism.
automation:
- alias: "Security: flooding detected"
description: "Closes the water (with state confirmation) and triggers the flood alarm"
mode: queued
triggers:
- trigger: state
entity_id:
- binary_sensor.bathroom_washer_leak
- binary_sensor.kitchen_dishwasher_leak
- binary_sensor.bathroom_sink_leak
- binary_sensor.boiler_room_leak
- input_boolean.flood_test
to: "on"
actions:
- choose:
- conditions:
- condition: state
entity_id: input_boolean.auto_close_water_on_flood
state: "on"
- condition: template
value_template: >
{{ trigger.entity_id != 'input_boolean.flood_test' }}
sequence:
# Adjust the domain: valve.close_valve / switch.turn_off / cover: confirm the direction manually
- action: valve.close_valve
continue_on_error: true
target:
entity_id: valve.main_water_valve
- wait_template: >
{{ is_state('valve.main_water_valve', 'closed') }}
timeout: "00:00:30"
continue_on_timeout: true
- if:
- condition: template
value_template: >
{{ not is_state('valve.main_water_valve', 'closed') }}
then:
- action: script.notify_household_urgent
continue_on_error: true
data:
title: "ERROR: water valve did not confirm closing"
message: >
Flooding was detected, but the valve did not confirm a closed state.
Shut off the water manually.
- action: script.turn_on
target:
entity_id: script.flood_alarm
data:
variables:
title: "ALARM: flooding detected"
message: >
{% if trigger.entity_id == 'input_boolean.flood_test' %}
This is a LOGICAL flood test: the valve should not move.
Check the push, the siren, and the escalation.
{% else %}
Water detected: {{ state_attr(trigger.entity_id, 'friendly_name') or trigger.entity_id }}.
The system sent a command to close the valve: check that the state was confirmed.
{% endif %}
- choose:
- conditions:
- condition: template
value_template: >
{{ trigger.entity_id == 'input_boolean.flood_test' }}
sequence:
- delay:
seconds: 2
- action: input_boolean.turn_off
target:
entity_id: input_boolean.flood_testNotice: flood_test triggers the alarm but doesn't close the valve: the condition trigger.entity_id != 'input_boolean.flood_test' blocks the valve action. That lets you test notifications, the siren, and escalation without cutting off water in the house. A real flood sensor can go on to close the valve, as long as the automation helper is enabled.
Don't copy the entities from this lesson
Swap the sensor list for your own entities from Developer Tools. If you only have one sensor under the washer to start with, leave just that one in the trigger.
Two flood tests
1) A logical test (flood_test): the valve doesn't move. 2) A separate, controlled valve test done with a household member present: that's when you check the physical shutoff.
A helper test doesn't replace a valve test. In the logical test, the message can't suggest "check the valve," since the automation is deliberately skipping it.
Manually reopening the valve after an alarm
After a flood, you need to be able to turn the water back on once the situation is under control. Keep the valve switch on the dashboard next to the automation helper.
type: entities
title: Flooding and water
entities:
- group.flood_sensors
- input_boolean.auto_close_water_on_flood
- input_boolean.flood_test
- switch.water_valve
- input_boolean.flood_alarm_acknowledgedHow to test, step by step
1. Let the household know about the flood-alarm test.
2. Turn on flood_test on the dashboard. Check the push, the siren, and the escalation. The valve should not close.
3. Acknowledge the alarm through flood_alarm_acknowledged.
4. On one sensor, pour a small amount of water: a few drops from a pipette, not a bucket. Check that the entity flips to on.
5. If you have a valve: with auto_close_water_on_flood enabled, check that switch.water_valve flips off.
6. Dry the sensor and check that the entity goes back to off. Manually reopen the valve if it closed.
Test with water, not with flooding
This is about a drop of water on the sensor's contacts, not pouring out liters. Dry the sensor after the test. The goal is checking the system's response, not ruining the floor.
A flood sensor needs ongoing supervision too
The fact that a sensor was added to Home Assistant once doesn't mean it works forever. In Lesson 10 we'll come back to battery monitoring, the unavailable state, and periodic testing. For flood sensors, it's worth checking the battery and doing a water-drop test every so often.
Common mistakes
A sensor mounted too high or too far away: it only detects water once the whole floor is soaked.
A separate escalation automation for flooding: you're duplicating the Lesson 3 logic instead of calling script.flood_alarm.
A valve closed with no way to reopen it: the house is left without water after a false alarm.
No sensor battery test: the sensor dropped off the network and you don't know it.
A technical alert instead of a human message: "binary_sensor.bathroom_washer_leak on" instead of "Water detected under the washing machine."
What not to do
Don't expect a sensor to replace a valve, or vice versa: the sensor detects, the valve limits the damage.
Don't test flooding without warning the household: the siren and the escalation are a real alarm.
Don't install a valve with no manual-open plan: you must always be able to restore water.
Assignment: your first flood scenario
To do
☐ Pick the first spot for a flood sensor: usually the washing machine or the dishwasher.
☐ Pair the sensor, give it a clear name, and note its entity down.
☐ Create the flood_sensors group and the auto_close_water_on_flood, flood_test helpers.
☐ Add the flooding automation that calls script.flood_alarm.
☐ If you have a valve: wire up the switch.water_valve entity and add it to the dashboard.
☐ If you have a valve, manually confirm that the off state actually shuts off the water.
☐ Show the household how to manually open the water after a false alarm or an HA outage.
☐ Test flood_test without closing the water.
☐ Test the real sensor with a drop of water and check that the entity returns to off.
☐ Update the risk map from Lesson 1: where you have a sensor, where you're planning the next one, and whether you have a valve.
Key takeaways
For flooding, the local response is what counts, not just the push.
The water valve limits damage while you're away from home.
script.flood_alarm centralizes escalation: don't duplicate it in the flooding automation.
A water-drop test and flood_test are two different scenarios: you need both.
What's next
In Lesson 5 we'll move on to smoke, carbon monoxide, and gas. A different rule applies there: a certified detector with its own siren is the foundation, and Home Assistant is only an extra layer of notification. Flooding and smoke are two different worlds of safety.
If, after this lesson, detecting water triggers the valve, the alarm, and the escalation from Lesson 3, you have your first complete home security scenario in Home Assistant.
