Will the Water Shutoff Valve Actually Close? Dry-Testing the Actuator Before the Pipe Bursts

Most smart water shutoff valves are installed, paired, and then trusted for years without ever being asked to prove they can close. The dashboard says Closed. The valve may not have moved. This is the failure mode worth engineering against: a command that is accepted, acknowledged, and never physically executed. The fix is a dry test — a scheduled, repeatable procedure that verifies the actuator’s travel and the feedback path that reports it, without flowing water.

Commanded state is not physical state

Home Assistant’s valve entity exposes states that map cleanly onto the question: Open, Opening, Closed, Closing, Stopped, Unavailable, and Unknown. The Stopped state is defined as the valve having stopped moving before reaching a fully open or closed position — that is the state you want your dry test to be able to produce on demand, because it is the state that tells you the actuator tried and failed. The valve building block also provides valve.close_valve, valve.open_valve, valve.set_valve_position, and valve.stop_valve actions, plus valve.closed and valve.opened triggers and valve.is_closed / valve.is_open conditions. See the Home Assistant valve integration documentation for the full state list and action names.

The trap is that a device can report Closed without any position sensing. A binary switch entity only has On, Off, Unavailable, and Unknown — there is no Stopped, no Closing, no intermediate position. If your shutoff is exposed as a switch rather than a valve, the state you see is the state of the relay or the last command, not the state of the ball valve. That distinction is the whole reason to dry-test.

What the radio actually reports

Zigbee2MQTT describes device capabilities through the exposes property at zigbee2mqtt/bridge/devices. A cover expose can include state (binary, OPEN/CLOSE), position (numeric, 0–100), and tilt. The access bitmask tells you whether a property is published in state (bit 1), settable via /set (bit 2), and retrievable via /get (bit 3). A valve that only exposes state with access 7 can be commanded and will report back, but the report is the device’s own claim about its endpoint, not a measured position. A valve that exposes position with access 7 gives you something to compare against.

Z-Wave JS exposes devices through the Z-Wave integration in Home Assistant, and the driver interviews the network on first startup. For a shutoff valve, the relevant command classes are typically Binary Switch or Multilevel Switch, and some devices report a currentValue that reflects the last commanded value rather than a sensed position. The Z-Wave JS integration documentation covers inclusion, network backup, and firmware updates, but it does not promise that every device reports true position. That is a device-level property, not an integration-level one.

ESPHome’s valve component is explicit about its limits: a valve can currently be either closed or open and supports open, close, and stop commands. It exposes position as a value between 0.0 and 1.0, current_operation as idle, opening, or closing, and triggers on_open and on_closed that fire when the valve reaches a fully open or closed state. The valve.control action accepts a position percentage. If you build a valve controller from a GPIO relay and a motor, the on_closed trigger is only as truthful as the sensor you wired to it. Without an end-stop switch or a current-sense circuit, on_closed fires when the firmware decides the travel time has elapsed.

The dry test procedure

The goal is to command a close, observe whether the actuator moves, and confirm that the feedback path reports the result — all without water in the line. Do this on a schedule, and do it once manually before you trust the automation.

1. Identify the entity domain. Confirm whether your shutoff is a valve entity or a switch entity. If it is a switch, note that you have no Stopped state and no position feedback. Write that down; it changes what the test can prove.
2. Close the upstream manual valve. This is the step that makes the test dry. If the actuator fails to close, no water moves. If it closes and you later open the manual valve, you have verified the actuator under pressure — but only after the dry test has passed.
3. Command a close from Home Assistant. Use valve.close_valve for a valve entity, or switch.turn_off for a switch entity. Record the timestamp and the entity state immediately after the command.
4. Listen and feel. A motorized ball valve produces audible motor noise and a tactile vibration at the body. A solenoid produces a sharp clack. If you hear nothing and feel nothing, the actuator did not receive power or the motor is seized. This is the step that catches the failure the dashboard hides.
5. Watch the state transition. A valve entity should move through Closing to Closed, or to Stopped if it fails to reach the endpoint. A switch entity will simply report Off regardless of whether the valve moved. If the state jumps from Open to Closed with no Closing interval, the device is reporting the command, not the travel.
6. Verify with a secondary signal if you have one. A flow sensor downstream, a current-sense relay on the motor circuit, or a physical end-stop switch wired to an ESPHome GPIO gives you an independent confirmation. If you have none of these, the dry test can only confirm that the actuator was commanded and that the device reported a state — not that the valve physically closed.
7. Open the valve again and restore the manual valve. Confirm the actuator returns to Open or On. A valve that closes but will not reopen is a different failure mode, and you want to find it during the test, not during a freeze event.
8. Log the result. Record the date, the entity state before and after, whether you heard or felt the actuator, and whether any secondary signal confirmed the result. A simple text file or a Home Assistant input_text helper is enough. The log is what turns a one-time test into a maintenance record.

What the test can and cannot prove

A dry test with no secondary sensor proves that the command path works and that the device reports a state change. It does not prove that the ball valve rotated. A dry test with an end-stop switch or current-sense circuit proves that the actuator reached a physical endpoint. A dry test with a downstream flow sensor proves that water stopped moving — but only if you run it with the manual valve open, which is no longer dry.

The honest position is that most residential shutoff valves fall into the first category. They are commanded, they report, and the report is taken on faith. If that is your installation, the dry test still has value: it catches a dead motor, a disconnected wire, a failed power supply, and a device that has dropped off the network. It does not catch a valve that is stuck mid-travel and reporting Closed anyway.

Graceful degradation when the hub is down

A local-first stack should not depend on Home Assistant being up to close a valve. The Z-Wave JS integration runs as a separate server process; if Home Assistant restarts, the Z-Wave network and the devices remain paired and reachable once the integration reconnects. Zigbee2MQTT runs as a separate service and publishes to MQTT; if Home Assistant is down, the Zigbee network and the MQTT broker can still carry commands from another consumer. ESPHome devices run their own firmware and can execute local automations — a GPIO switch with an on_turn_on trigger and a delay can pulse a relay without any network connection at all.

The practical degradation strategy is to put the close command in more than one place. A Z-Wave valve that supports direct association can be commanded by a nearby switch even if the hub is offline. An ESPHome valve controller can close on a local GPIO input from a leak sensor wired to the same board. A Zigbee2MQTT device can be bound to a leak sensor so the close command travels over the mesh without the coordinator. None of these are substitutes for a dry test; they are what remains after the dry test has told you the actuator works.

If your shutoff valve is a solenoid that requires continuous power to stay closed, a power loss opens the valve. That is a mechanical property, not a software one, and no amount of local-first engineering changes it. A motorized ball valve with a latching mechanism holds its position without power. If you are choosing hardware, that difference matters more than the radio protocol.

When a mechanical timer or a plain switch is the better choice

If the only automation you need is a scheduled close during a vacation, a mechanical timer on the valve actuator is simpler, cheaper, and immune to network failures. If the only automation you need is a manual close from a wall switch, a plain switch is more reliable than any smart relay. The case for a smart shutoff valve is remote monitoring, integration with leak sensors, and a log of when the valve was exercised. If you do not need those, the smart valve is a liability you have to maintain.

The dry test is the maintenance task that keeps the liability honest. Run it before the heating season, run it after any firmware update, and run it any time you change the automation that commands the valve. The procedure is short, the log is short, and the alternative is finding out during a burst pipe that the valve was reporting a state it never reached.

Frequently asked questions

How often should I dry-test a water shutoff valve?

There is no universal interval. A reasonable starting point is twice a year, plus after any firmware update or automation change. The test is cheap; the failure is not. If your valve is a solenoid that holds position only under power, test more often and consider whether that hardware is appropriate for your risk tolerance.

Can I dry-test a valve that has no position feedback?

Yes, but the test proves less. You can confirm that the command was accepted, that the device reported a state change, and that the actuator made noise or vibration. You cannot confirm that the valve physically closed. If that distinction matters to you, add an end-stop switch or a current-sense circuit.

What does the Stopped state mean in Home Assistant?

The Home Assistant valve documentation defines Stopped as the valve having stopped moving before reaching a fully open or closed position. If your dry test produces Stopped, the actuator tried to move and did not reach the endpoint. That is a useful failure signal, and it is only available on valve entities, not switch entities.

Does Zigbee2MQTT report true valve position?

It reports what the device exposes. A cover expose with a position feature and access bit 1 set will publish a position value. Whether that value is measured or inferred depends on the device. Check the exposes output for your specific device at zigbee2mqtt/bridge/devices and read the access bitmask to see what is actually reported.

What happens to a Z-Wave valve if Home Assistant goes down?

The Z-Wave network and the paired devices remain intact. The Z-Wave JS server can continue to run, and direct associations between devices can still carry commands. When Home Assistant comes back, the integration reconnects and the entities return. The valve does not close on its own unless you have configured a local association or a device-level failsafe.

Is a smart shutoff valve worth it if I already have a manual valve?

It depends on whether you need remote monitoring, leak-sensor integration, or a log of valve exercise. If you do not, a manual valve and a mechanical timer are simpler and have fewer failure modes. The smart valve adds a maintenance task — the dry test — that a manual valve does not require.

For a broader look at auditing the small systems that quietly run your week, see How to Audit the Small Systems That Quietly Run Your Week. The same principle applies: the systems you never test are the ones that fail without warning.