Dreizehn Stunden hing die Absperrung an der Cloud

Meran, 27. Oktober 2026, 03:17 Uhr. Das Netz fällt kurz aus. Alles kommt wieder, niemand merkt etwas.

Zwei Geräte kommen mit neuen Adressen zurück: die beiden motorisierten Wasserventile von PNI, kalt und warm.

Kaltwasser   .113  ->  .101
Warmwasser   .115  ->  .102

Die Integration, die sie lokal anspricht — tuya-local —, sucht sie über ihre feste Adresse, nicht über einen Namen. Damit war der lokale Weg zu beiden Ventilen tot. Dreizehn Stunden lang.

Aufgefallen ist es nicht, und das ist der eigentliche Punkt: Die Wolkenhälfte derselben Anbindung lief unbeeindruckt weiter. Die ganze Wasserabsperrung hing dreizehn Stunden an der Cloud — an genau dem Weg, den ich eigentlich nur als Rückfall behalten hatte.

Wer so viel wie möglich lokal macht, hat keinen Dienst mehr, der das Gerät wiederfindet. Diese Aufgabe erbt man mit.

Warum die Adressen überhaupt wandern

In Wien ist das nachgemessen. Zwischen zwei Netzdurchläufen liegen neun Tage, und von den 24 Geräten, die in beiden auftauchen, hatten 14 die Adresse gewechselt.

Die meisten um genau +2. Das sah nach einem Muster aus, und ich habe es als eines aufgeschrieben.

Der dritte Messpunkt hat es widerlegt:

	28.08.	06.09.	11.09.
Verstärker A	.57	.59	.58
Verstärker B	.241	.242	.241

Verstärker B steht wieder dort, wo er am 28.08. schon war. Kein Abdriften nach oben, sondern ein Neuziehen aus dem freien Vorrat: Die Box verlängert die Leihgabe nicht, sie vergibt sie neu — und wo ein Gerät danach landet, ist nicht vorhersagbar.

Zwei Messpunkte ergeben immer eine Richtung. Erst der dritte sagt, ob es eine gibt.

Was der Auslöser ist — Neustart, Ablauf der Lease-Dauer, Stromunterbrechung — habe ich nie geklärt. Für die Folgen macht es keinen Unterschied.

Was daran kaputtgeht, und warum man es nicht merkt

Der Ausfall ist still. Die Entität geht auf unavailable, und das sieht genauso aus wie ein Gerät, das gerade schläft.

Zwei Sorten Schaden, beide in Wien belegt:

Die Überwachung meldet Gespenster. Eine Erreichbarkeitsprüfung stand für einen Verstärker seit dem 08.09. um 17:52 auf off, für einen zweiten seit dem 11.09. um 04:59. Beide Geräte liefen die ganze Zeit. Weg waren nicht die Geräte, weg waren die Adressen.

Und die gefährlichere Sorte: Ein Skript schreibt eine Vermittleradresse in die Zähler hinein. Auf einer veralteten Adresse trifft so ein Schreibvorgang nicht ins Leere.

Eine falsche Adresse ist nicht leer. Dort wohnt jemand anderes.

Die Reservierung — über die MAC, niemals über die IP

In Meran ist genau das einmal schiefgegangen: Nach einem Routerneustart hatte der DHCP fast alle Adressen neu vergeben, und eine Geräteliste, die über die damalige IP identifizierte, war wertlos. Am deutlichsten bei zwei Klimageräten, die Home Assistant auf .10/.11 suchte, während sie auf .16/.14 gelandet waren.

Die MAC ändert sich nicht. Alle Werkzeuge in allen drei Wohnungen sind seitdem um die MAC herum gebaut, nicht um die Adresse.

Dazu zwei Einstellungen, die mehr bringen als die Reservierungen selbst:

	Meran	Kapfenberg
dynamischer Bereich	.100–.200	.201–.250
reservierte Einträge	22	16
Lease-Dauer	24 Stunden	2 Stunden

Der verkleinerte Bereich hat einen Nebeneffekt, den ich nicht eingeplant hatte: Alles außerhalb davon ist fest vergeben und benannt, alles darin ist Besuch. Wer im Netz auftaucht und nicht hierhergehört, fällt dadurch sofort auf.

Eine Reservierung wirkt nicht, weil sie gespeichert ist

Das ist der Teil, der in keiner Anleitung steht. Gespeichert heißt nicht gezogen. Vier Fälle, in denen es hakt:

Manche Geräte erneuern nur ihre bestehende Adresse und wechseln erst bei einer vollständigen Neuanfrage. In Kapfenberg blieben vier Geräte nach dem Speichern auf der alten Adresse sitzen; erst ein Neustart hat den Wechsel ausgelöst.

Ein Gerät mit fest eingestellter IP ignoriert DHCP. Dann greift die Reservierung nie — und man sieht ihr das nicht an, denn im Router steht sie korrekt.

Schlafende Geräte holen die Adresse erst beim nächsten Aufwachen. Bei Batteriegeräten können das Stunden sein.

Verstärker sind ein Sonderfall: Zieht man sie um, brechen offene Browsersitzungen zu ihnen weg, und das Funknetz hat kurz Schluckauf.

Verlässlich ist nur der Stromstoß. Sonst gilt die Reservierung spätestens nach Ablauf der Lease — und „spätestens“ ist bei 24 Stunden eine lange Zeit.

Die Falle beim Nachprüfen

Nach dem Neustart der vier Umzieher meldete mein Prüfskript sie weiterhin auf den alten Adressen — obwohl die neue längst antwortete.

Der Grund: Windows behält den alten ARP-Eintrag, bis er verfällt. Dieselbe MAC steht dann unter zwei Adressen, und wer die zuletzt gelesene nimmt, meldet den Umzug als nicht erfolgt.

Entschieden hat es die direkte Frage an die Geräte:

.145    antwortet, meldet seinen Gerätenamen   <- umgezogen
.224    niemand                                <- alte Adresse, leer

Das Skript merkt sich seitdem, welche Adressen im Durchlauf tatsächlich geantwortet haben. Bei mehreren Adressen zu einer MAC gewinnt die lebendige.

Die ARP-Tabelle ist ein Gedächtnis, keine Messung. Wer sie für den Ist-Zustand hält, liest Vergangenheit.

Was sich nicht reservieren lässt

In Wien tauchen die beiden Verstärker in der Client-Liste der Box gar nicht auf. Es sind ihre eigenen Funkknoten, die verwaltet die Box selbst; reservieren lassen sich nur gewöhnliche Geräte. Für diese zwei gibt es den Weg über den Router also nicht.

Der Ausweg ist der DHCP-Name statt der Adresse. Die Probe kam von selbst: Am 13.09.2026 musste die Box neu gestartet werden.

	vorher	nachher
sechs reservierte Geräte		alle sechs unverändert
Verstärker A	.58	.57 — gewandert

Sechs von sechs Reservierungen haben gehalten. Der Verstärker ist wieder gewandert — und die Überwachung ist mitgegangen, weil sie seit dem Vortag den Namen anspricht statt der Adresse.

Aber der Name hat auch eine Schwäche

Nach demselben Neustart lösten die Namen von vier Geräten minutenlang nicht auf, obwohl alle vier auf ihrer richtigen Adresse antworteten. Die Leihgaben standen, der Namensdienst hatte sie nur noch nicht wieder veröffentlicht.

Damit haben beide Wege eine Schwachstelle, und man muss beide kennen:

	bricht, wenn	wie oft belegt
über die Adresse	das Gerät eine neue Lease zieht	4-mal in zwei Wochen
über den Namen	der Namensdienst gerade nicht antwortet	2-mal an einem Vormittag

Der Name bleibt die bessere Wahl: Sein Aussetzer dauert Minuten und heilt von selbst, ein Adresswechsel dauert bis zum Nachziehen von Hand.

Die praktische Folge daraus steht jetzt in der Dokumentation: Ein off ist kein Beweis für einen Ausfall. Erst nachsehen, ob das Gerät unter seiner Adresse antwortet.

Nebenbei ist dabei etwas entstanden, das ich vorher nicht hatte: Die Adresse ist zum Messwert geworden. Das Wandern .57 → .59 → .58 → .57 steht im Verlauf, statt nur aufzufallen, wenn jemand nachsieht.

Was ich dir rate

1. Reserviere über die MAC, nie über die aktuelle Adresse. Eine Liste, die Geräte über ihre heutige IP kennt, ist nach dem nächsten Routerneustart Altpapier.
2. Verkleinere den dynamischen Bereich. Dann ist auf einen Blick klar, was zu dir gehört und was Besuch ist.
3. Jedes Gerät, das in einer Integration mit fester Adresse steht, gehört in die Reservierungsliste. Sonst überlebt die Anbindung den nächsten Stromausfall nicht — und zwar still.
4. Nach dem Speichern einen Stromstoß. Sonst gilt die Reservierung irgendwann und du weißt nicht, wann.
5. Prüf den Umzug an den Geräten, nicht in der ARP-Tabelle. Frag die neue Adresse, ob dort jemand wohnt.
6. Wo du nicht reservieren kannst, nimm den Namen — und wisse, dass er minutenweise aussetzt.

Und was heißt das?

Die Cloud macht dieses ganze Thema unsichtbar. Ein Wolkengerät meldet sich von selbst an, der Dienst findet es wieder, die Adresse im Haus ist belanglos.

Genau diese Bequemlichkeit gibt man auf, wenn man lokal arbeitet. Das ist kein Mangel, das ist der Preis — und er ist niedrig, solange man ihn kennt. Lokal heißt: Das Verzeichnis bist du.

Die beiden Ventile haben das deutlicher gezeigt, als mir lieb war. Dreizehn Stunden sah in der App alles in Ordnung aus, weil die Hälfte trug, die ich nur als Rückfall behalten hatte. Wäre die Wolkenhälfte abgeschaltet gewesen — und genau das wollen viele, mit guten Gründen —, hätte es in dieser Zeit keine Wasserabsperrung gegeben.

Dieselben zwei Ventile haben mir binnen zweier Tage zwei völlig verschiedene Ausfälle geliefert: diesen im Netz, und einen Tag später einen im Zustand. Beide still, beide unbemerkt, beide an derselben Stelle folgenlos geblieben — weil zufällig jemand da war.

Eine Adresse ist keine Eigenschaft des Geräts. Sie ist eine Leihgabe des Routers, und Leihgaben holt man sich zurück.