Ten hours without water, and the watchdog said nothing

The flat in Merano has two motorised shut-off valves, one for cold and one for hot water. They close when you leave and open when you arrive. There is a watchdog for that: water off while the flat is occupied should be reported.

One Tuesday both stood closed for ten hours, with the flat occupied. The watchdog said nothing.

The reason is general enough to affect every alarm in the house.

What happened

00:00:36   hot water closed
00:00:39   cold water closed
10:27      question why no water is coming

Exactly midnight, both at once. That is the time of the anti-seize cycle: per the manual the valves open and close once every night so they do not stick.

This time they closed and did not reopen. The meter reading confirms it: not a single litre since the previous evening.

The finding: two entities, one truth

Each valve appears in Home Assistant twice — once as a valve, once as a switch. Same device, same integration, same data stream.

They are not equivalent:

switch     on   ->  off          continuously available
valve      open ->  unavailable  for ten hours

The switch reported the truth correctly all night. The valve entity fell silent.

It only came back when a command went to the device. It evidently depends on the device sending its data point of its own accord — and after a cycle the device itself initiated, it does not.

Reloading the integration did not help: afterwards temperature, meter reading and all switches delivered data again, the valve entities stayed mute.

Why the watchdog stayed quiet

The automation looked like this:

triggers:
  - trigger: state
    entity_id: [valve.cold_water, valve.hot_water]
    to: "closed"
conditions:
  - condition: state
    entity_id: valve.cold_water
    state: "closed"

It waited for closed. What arrived was unavailable.

The trigger never fired, and the condition would not have matched either. Technically everything worked. It was simply built on the wrong state.

A watchdog waiting for a particular fault state is blind to every other one.

The question is not “does it say closed” but “does it not say open”. unavailable is just as un-open as closed — and arguably worse, because then nobody knows what the valve is doing at all.

That is the same class of error as a condition that describes the normal case cleanly and silently excludes the exception. It looks entirely right while you write it.

What changed

The watchdog now asks the switches, not the valve entities, and checks for not open rather than for closed:

conditions:
  - condition: template
    value_template: >-
      {{ not is_state('switch.cold_water', 'on')
         or not is_state('switch.hot_water', 'on') }}

Plus three small things, each with a reason:

Level “warning” instead of “information”. No water in an occupied flat is not a footnote.

A three-hourly check as an additional trigger. A state that already existed before a restart produces no state change afterwards — and should still be found. That is the case pure event triggers miss by design.

At most one message every six hours. Otherwise the three-hourly check reports a persistent state three times a day, and after three days you swipe it away without looking.

The water was reopened through the switches — through the entities that answered. Both valve entities snapped back in the same moment.

And afterwards not only this one watchdog was converted but the whole package. A half conversion would have meant the same error living on in eleven other places.

What I would advise

1. Ask for “not good” instead of “bad”. Any check naming a concrete fault state has a gap the size of every other state.
2. Treat unavailable as an alarm, not an exception. A sensor that stays silent is not a sensor giving the all-clear.
3. Pair every event trigger with a time-based check. Otherwise every state that survived a restart is invisible.
4. Check which of two entities for the same device is dependable. Same integration does not mean same reliability. Here the simpler data point was the more robust one.
5. Limit repetition. A message saying the same thing three times a day becomes background noise — and that is then just as silent as no message.

So what?

The actual damage was small: ten hours without water, noticed by a human turning on a tap.

The actual finding is larger. I had built a watchdog, considered it finished, and never played through the case where the monitored entity does not report “wrong” but nothing at all.

That is the same mechanism as monitoring that does not notice its own silence. And it is why I now ask, for every new alarm, not how it triggers but what it looks like when the source disappears.

An alarm that only fires on one particular fault covers exactly one fault. The next one always looks different.