For thirteen hours the shut-off hung on the cloud

Merano, 27 October 2026, 03:17. The network drops briefly. Everything comes back, nobody notices a thing.

Two devices return with new addresses: the two motorised PNI water valves, cold and hot.

cold water   .113  ->  .101
hot water    .115  ->  .102

The integration that talks to them locally — tuya-local — looks for them by their fixed address, not by a name. So the local path to both valves was dead. For thirteen hours.

Nobody noticed, and that is the actual point: the cloud half of the same connection carried on undisturbed. The entire water shut-off hung on the cloud for thirteen hours — on exactly the path I had only kept as a fallback.

Work as locally as you can and you no longer have a service that finds the device again. You inherit that job.

Why addresses wander in the first place

In Vienna this is measured. Two network sweeps nine days apart, and of the 24 devices appearing in both, 14 had changed address.

Most of them by exactly +2. That looked like a pattern, and I wrote it down as one.

The third data point disproved it:

	28.08.	06.09.	11.09.
Repeater A	.57	.59	.58
Repeater B	.241	.242	.241

Repeater B is back where it already was on 28 August. No drift upwards, but a fresh draw from the free pool: the box does not extend the loan, it hands out a new one — and where a device lands afterwards is not predictable.

Two data points always produce a direction. Only the third one tells you whether there is one.

What the trigger is — restart, lease expiry, power cut — I never established. For the consequences it makes no difference.

What breaks, and why you don’t notice

The failure is silent. The entity goes to unavailable, and that looks exactly like a device that happens to be asleep.

Two kinds of damage, both documented in Vienna:

The monitoring reports ghosts. A reachability check sat at off for one repeater since 08.09. at 17:52, and for a second since 11.09. at 04:59. Both devices were running the whole time. What was gone was not the devices, it was the addresses.

And the more dangerous kind: a script writes a broker address into the meters. On an outdated address a write like that does not land in empty space.

A wrong address is not empty. Somebody else lives there.

The reservation — by MAC, never by IP

In Merano exactly this went wrong once: after a router restart DHCP had reissued almost every address, and a device list that identified things by their then current IP was worthless. Most clearly with two air conditioners that Home Assistant was looking for on .10/.11 while they had landed on .16/.14.

The MAC does not change. Every tool in all three flats has been built around the MAC ever since, not around the address.

Plus two settings that help more than the reservations themselves:

	Merano	Kapfenberg
dynamic range	.100–.200	.201–.250
reserved entries	22	16
lease time	24 hours	2 hours

The narrowed range has a side effect I had not planned for: everything outside it is fixed and named, everything inside it is a visitor. Anyone turning up in the network who does not belong stands out immediately.

A reservation does not take effect because it is saved

This is the part no guide mentions. Saved is not drawn. Four cases where it sticks:

Some devices only renew their existing address and change only on a full new request. In Kapfenberg four devices stayed on the old address after saving; only a restart triggered the move.

A device with a statically configured IP ignores DHCP. The reservation then never applies — and you cannot tell, because in the router it looks correct.

Sleeping devices fetch the address at their next wake-up. With battery devices that can be hours.

Repeaters are a special case: move them and open browser sessions to them break, and the mesh hiccups.

Only a power cycle is reliable. Otherwise the reservation applies by the time the lease expires at the latest — and “at the latest” is a long time at 24 hours.

The trap when you verify

After restarting the four movers my check script still reported them on their old addresses — although the new one had long been answering.

The reason: Windows keeps the old ARP entry until it expires. The same MAC then appears under two addresses, and whoever takes the one read last reports the move as having failed.

Asking the devices directly settled it:

.145    answers, reports its device name   <- moved
.224    nobody                             <- old address, empty

The script now remembers which addresses actually answered during the sweep. With several addresses for one MAC, the live one wins.

The ARP table is a memory, not a measurement. Take it for the current state and you are reading the past.

What cannot be reserved

In Vienna the two repeaters do not appear at all in the box’s client list. They are its own mesh nodes, managed by the box itself; only ordinary clients can be reserved. For those two the router route simply does not exist.

The way out is the DHCP name instead of the address. The test arrived by itself: on 13 September 2026 the box had to be restarted.

	before	after
six reserved devices		all six unchanged
Repeater A	.58	.57 — wandered

Six of six reservations held. The repeater wandered again — and the monitoring went with it, because since the previous day it addresses the name instead of the address.

But the name has a weakness too

After that same restart, the names of four devices did not resolve for minutes, although all four were answering on their correct address. The loans were in place, the name service simply had not republished them yet.

So both routes have a weak spot, and you need to know both:

	breaks when	how often observed
by address	the device draws a new lease	4 times in two weeks
by name	the name service happens not to answer	twice in one morning

The name remains the better choice: its outage lasts minutes and heals itself, while an address change lasts until somebody pulls it by hand.

The practical consequence is now in the documentation: an off is not proof of an outage. First check whether the device answers on its address.

Something else came out of it that I did not have before: the address has become a measured value. The wandering .57 → .59 → .58 → .57 sits in the history instead of only being noticed when somebody looks.

What I’d suggest

1. Reserve by MAC, never by the current address. A list that knows devices by today’s IP is waste paper after the next router restart.
2. Narrow the dynamic range. Then it is obvious at a glance what belongs to you and what is a visitor.
3. Every device entered in an integration with a fixed address belongs in the reservation list. Otherwise the connection will not survive the next power cut — and it will not survive silently.
4. Power-cycle after saving. Otherwise the reservation applies at some point and you do not know when.
5. Verify the move at the devices, not in the ARP table. Ask the new address whether anyone lives there.
6. Where you cannot reserve, use the name — and know that it drops out for minutes at a time.

So what?

The cloud makes this whole topic invisible. A cloud device registers itself, the service finds it again, and its address inside the house is irrelevant.

That convenience is exactly what you give up by working locally. It is not a defect, it is the price — and it is a low one as long as you know it. Local means: you are the directory.

The two valves showed that more clearly than I would have liked. For thirteen hours everything looked fine in the app, because the half I had only kept as a fallback was carrying it. Had the cloud half been switched off — which is exactly what many people want, with good reason — there would have been no water shut-off during that time.

The same two valves handed me two completely different failures within two days: this one in the network, and one day later one in the state. Both silent, both unnoticed, and both without consequence in the same way — because somebody happened to be there.

An address is not a property of the device. It is a loan from the router, and loans get called in.