Der Trinkbrunnen läuft. In Home Assistant steht er nicht.

Bruno hat einen Trinkbrunnen. Er läuft, das Wasser bewegt sich, Bruno trinkt daraus. Das ist im Reel zu sehen und braucht keine weitere Erklärung.

Die Frage dieser Serie ist eine andere: Braucht sein Napf WLAN?

Die Antwort ist nach einem halben Nachmittag klar, und sie fällt in zwei Teile, die man auseinanderhalten muss.

Was der Napf ohne alles kann

Eine Pumpe, ein Filter, ein Becken. Bewegtes Wasser, weil Hunde und Katzen daraus lieber trinken als aus stehendem.

Das funktioniert ab Steckdose und braucht kein Netz. Wer nur das will, ist hier fertig und kann aufhören zu lesen.

Warum ich ihn trotzdem einbinden wollte

Zwei Dinge, und beide haben nichts mit Spielerei zu tun:

	warum ein System das besser weiß als ein Mensch
Wasserstand	Ein Brunnen, der trockenläuft, ist schlechter als gar keiner — die Pumpe läuft weiter und der Napf ist leer.
Filterstandzeit	Niemand merkt sich, wann der Filter zuletzt gewechselt wurde. Ein Zähler schon.

Beides sind Werte, die das Gerät ohnehin kennt. Es geht nicht darum, etwas Neues zu messen, sondern darum, an etwas Vorhandenes heranzukommen.

Zum Stand heute, damit hier nichts Falsches steht: Es gibt keine Wasserstandswarnung in meinem System. Der Napf hängt nicht in Home Assistant. Dieser Artikel erklärt, warum.

Der einfache Weg war zu

Home Assistant bringt eine Xiaomi-Integration mit. Die deckt bestimmte Gerätearten ab — ein Trinkbrunnen gehört nicht dazu.

Also der übliche zweite Schritt: eine allgemeine Gemeinschaftsintegration über HACS, die alles ansprechen kann, was Xiaomis Protokoll spricht. Die holt den Gerätetoken einmalig aus dem Herstellerkonto und redet danach lokal. Ein fairer Handel, und genau so soll es sein.

Daran ist es gescheitert, und zwar an etwas, das mit Technik nichts zu tun hat: Mein Xiaomi-Konto ist ein altes chinesisches Konto mit einer Telefonnummer, die es nicht mehr gibt. Die Zwei-Faktor-Bestätigung kommt weder per SMS noch per E-Mail an.

Xiaomi serviceLoginAuth2: … → need_verify

Ein Konto, in das man nicht hineinkommt, ist kein Konto.

Der lokale Weg, und warum er bei diesem Modell nicht aufgeht

Ohne Konto bleibt ein zweiter Weg, und der ist der interessante: Den Token kann man direkt vom Gerät holen. Im Kopplungsmodus gibt ein solches Gerät ihn im Handschlag preis — an der Stelle, die sonst mit Füllbytes belegt ist.

Dafür habe ich das Protokoll von Hand nachgebaut. Es war nicht umsonst, denn es hat funktioniert:

Kopplungsmodus, Token gelesen
    → volle Gerätedaten: Modell, Firmware, Netzwerk …

WLAN setzen
    → {"result": ["ok"]}

Heimnetz, derselbe Token
    → keine Antwort, fünf Versuche

Handschlag im Heimnetz
    → ffffffff…ffffffff
       └─ Token verschwiegen ─┘

Der Befund, und er ist nachgemessen

Das Gerät vergibt beim Verlassen des Kopplungsmodus einen neuen Token.

Das ist keine Vermutung. Zwei unabhängige Beobachtungen belegen es:

1. Vorher und nachher in derselben Sitzung. Die Abfrage funktioniert im Kopplungsmodus und mit exakt demselben Token danach im Heimnetz nicht mehr.
2. Zwei aufeinanderfolgende Durchläufe lieferten verschiedene Token für dasselbe Gerät.

Und ein Detail, das die Sache erst vollständig macht: Es verschweigt den Token auch dann, wenn es an kein Konto gebunden ist. Die Kontobindung ist also nicht die Bedingung. Der Wechsel passiert beim Verlassen des Kopplungsmodus, Punkt.

Damit ist der cloudfreie Weg für dieses Modell zu. Nicht wegen eines Fehlers, sondern konstruktionsbedingt.

Die Fehlermeldung, die das Gegenteil von dem sagt, was sie zu sagen scheint

Hier ist der Teil, bei dem ich falsch abgebogen bin, und er ist lehrreicher als der Rest.

Antwortet das Gerät nicht auf einen Befehl, liefert die Integration intern ein leeres Wörterbuch zurück statt einer Fehlermeldung. Ihr Einrichtungsdialog fängt das nicht ab und stürzt beim nächsten Zugriff ab:

AttributeError: 'dict' object has no attribute 'model'

Nach außen erscheint das als HTTP 500, „Server got itself in trouble“.

Wer das sieht, denkt an einen Fehler in der Integration. Tatsächlich sagt die Meldung nur: Das Gerät hat nicht geantwortet. In aller Regel also: falscher Token.

Ich habe daraus das Gegenteil geschlossen. Aus dem Absturz an genau dieser Zeile las ich, die Integration habe Daten bekommen und der Token stimme also. Falsch — das leere Wörterbuch bedeutet, dass nichts kam.

Ein Fehler tief im fremden Code sagt selten das, was die oberste Zeile suggeriert.

Und der Grund, warum der Vorher-Nachher-Versuch nötig war

Zwei unabhängige Umsetzungen sind hier gleich gescheitert: meine selbstgebaute und die der Integration.

Ein Fehlschlag allein beweist nichts über den Token. Er kann genauso gut bedeuten, dass das eigene Werkzeug kaputt ist — und bei zwei Werkzeugen, die dasselbe Protokoll umsetzen, kann derselbe Denkfehler in beiden stecken.

Erst der Versuch im Kopplungsmodus hat „Werkzeug kaputt“ von „Token gewechselt“ getrennt. Ohne diesen Schritt hätte ich weiter in meinem eigenen Code gesucht, und zwar nach etwas, das dort nicht ist.

Was übrig bleibt: ein zweites Konto

Der Ausweg ist unspektakulär und funktioniert. Nach dem Zurücksetzen hängt das Gerät im WLAN und ist an kein Konto gebunden — genau dieser Zustand löst das Problem:

1. Ein neues Konto mit erreichbarer E-Mail-Adresse, Region Europa.
2. In der Hersteller-App mit diesem Konto anmelden und den Napf einbinden.
3. Erst danach in Home Assistant anmelden.

Die Reihenfolge ist der ganze Trick. Wer sich zuerst in Home Assistant anmeldet, findet ein leeres Konto und sucht den Fehler an der falschen Stelle.

Danach ist es der Normalfall: Der Token kommt einmalig aus der Cloud, danach läuft alles lokal, und die App bleibt nutzbar.

Gemacht habe ich es nicht — und ich werde es nicht mehr machen.

Ein zweites Konto anlegen, pflegen und im Blick behalten, damit ein Hundenapf einmalig einen Schlüssel herausrückt: Dafür steht der Aufwand nicht im Verhältnis zu dem, was am Ende herauskommt. Es sind zwei Zahlen, Wasserstand und Filterstandzeit, und für beide gibt es eine Alternative, die seit jeher funktioniert — hinsehen.

Der Napf bleibt draußen. Das ist kein Scheitern, sondern eine Entscheidung, und sie gehört genauso dokumentiert wie ein Erfolg. Ein System wächst nicht dadurch, dass alles hineinkommt, sondern dadurch, dass das Richtige hineinkommt.

Das Urteil

Die Serie heißt „Smart oder sinnlos?“, und die Antwort hat zwei Hälften:

	Urteil
Als Trinkbrunnen	Sinnvoll. Bruno trinkt daraus, das Wasser bewegt sich, der Filter tut seinen Dienst. Dafür braucht es kein Netz und keine App.
Als smartes Gerät	Sinnlos — nicht weil es schlecht wäre, sondern weil der einzige cloudfreie Weg bauartbedingt zu ist und der Umweg den Aufwand nicht wert war.

Würde ich ihn wieder kaufen? Für den Hund ja. Fürs System nein — jedenfalls nicht, ohne vorher eine Frage zu stellen, die ich mir damals nicht gestellt habe.

Die eine Frage vor dem Kauf

Nicht „ist das kompatibel“. Diese Frage beantwortet jede Verpackung mit Ja.

Sondern: Wie kommt der Schlüssel aus dem Gerät heraus, und was brauche ich dafür?

Bei dieser Geräteklasse lautet die Antwort: über ein Herstellerkonto, in das du hineinkommen musst. Wer ein funktionierendes Konto hat, hat kein Problem. Wer ein altes hat, hat einen Nachmittag.

Das steht auf keiner Verpackung, und es ist der einzige Punkt, der hier entschieden hat.

Was ich dir rate

1. Trenn das Gerät von seiner Anbindung. Ein guter Trinkbrunnen bleibt ein guter Trinkbrunnen, auch wenn er nie in deinem System auftaucht.
2. Prüf vor dem Kauf den Weg zum Schlüssel, nicht die Kompatibilitätsliste. Bei Xiaomi ist das die Kontofrage, bei anderen Herstellern heißt es anders.
3. Räum dein Herstellerkonto auf, bevor du es brauchst. Eine tote Telefonnummer im Zweitfaktor merkt man genau einmal — wenn es eilig ist.
4. Lies Fehlermeldungen aus fremdem Code misstrauisch. Ein Absturz an einer bestimmten Zeile sagt dir, wo es geknallt hat, nicht warum.
5. Trenn „mein Werkzeug ist kaputt“ von „das Gerät macht etwas anderes“. Dafür braucht es einen Versuch, bei dem du den Unterschied erzwingst — bei mir war das der Vorher-Nachher-Test im Kopplungsmodus.
6. Schreib auf, was nicht geht. Die Werkzeuge aus diesem Nachmittag funktionieren nachweislich. Beim nächsten Gerät desselben Herstellers kann derselbe Weg aufgehen.

Und was heißt das?

Der ehrlichste Satz über dieses Gerät ist der langweiligste: Es tut, wofür es gekauft wurde. Bruno trinkt, und das war der Zweck.

Was es nicht tut, ist etwas, das ich mir dazugedacht habe — und das Scheitern liegt nicht am Gerät, sondern an einer Entscheidung des Herstellers, die man vor dem Kauf nicht sieht: Der Schlüssel verlässt das Gerät nur über ein Konto.

Das ist die eigentliche Lehre aus diesem Nachmittag, und sie gilt weit über einen Hundenapf hinaus. „Lokal steuerbar“ heißt bei vielen Geräten: lokal steuerbar, nachdem die Cloud einmal zugestimmt hat. Der Unterschied fällt nicht auf, solange das Konto funktioniert.

Bruno ist das alles herzlich egal. Für ihn war der Brunnen vom ersten Tag an smart genug.