Die Integration, die still nicht startete
Nach einem Update der Hausautomation war die Wallbox weg. Nicht „reagiert langsam”, nicht „zeigt falsche Werte” — weg. Alle 34 Entities der Wallbox-Integration standen auf unavailable, und zwar auf die Sekunde genau seit dem Neustart, der zum Update gehörte.
So weit ist das noch keine Geschichte. Nach einem Update ist etwas kaputt, das ist Dienstag. Die Geschichte fängt eine Ebene tiefer an.
Ein Fehler ohne Fehler
Der übliche Ablauf: Config-Entry anschauen. Der stand auf not_loaded. Gut, also nicht geladen — nur warum?
Genau dafür gibt es ein Feld, das den Grund transportiert. Auth abgelaufen, Gerät nicht erreichbar, Setup fehlgeschlagen. In diesem Feld stand: null.
Also ins Log. Keine Exception. Kein Traceback. Nicht mal eine Warnung. Die Integration hatte nicht gemeldet, dass sie ein Problem hat — sie war einfach nicht da.
Nächster Verdacht: der Cloud-Dienst der Wallbox. Vielleicht Wartung, vielleicht Zugangsdaten abgelaufen. Ein Aufruf gegen die API antwortete mit HTTP 200. Der Dienst lief, die Zugangsdaten waren gültig, das Netz war in Ordnung.
Damit war ich an einem unangenehmen Punkt: Alles, was mir eine Richtung hätte geben können, sagte „alles gut”. Nur das Ergebnis sagte „nichts geht”.
Das fehlende Stück
Die Wallbox läuft über eine Custom-Integration — nichts, was mit der Hausautomation mitgeliefert wird, sondern von Hand nachinstalliert. Und solche Integrationen bringen eigene Python-Abhängigkeiten mit, die im Standard-Image nicht drin sind.
Ein Blick in den Container: Das Paket, das die Integration als Voraussetzung deklariert, war nicht installiert. Nicht in einer falschen Version, nicht halb — schlicht nicht vorhanden.
Der Rest ergab sich aus drei Fakten, die einzeln harmlos sind und zusammen genau diesen Ausfall produzieren:
- Custom-Abhängigkeiten landen nicht im Image, sondern in einem Zusatzordner daneben, der zwischen Updates überlebt.
- Dieser Zusatzordner ist an eine konkrete Python-Version gebunden. Das neue Image war auf eine neue Python-Version gesprungen — der alte Ordner lag damit auf einem Pfad, den niemand mehr las. Effektiv leer.
- Fehlende Custom-Abhängigkeiten werden nur beim Prozessstart nachgezogen. Genau dieser Start war der, bei dem es schiefging.
Was also passierte: Die Integration wurde geladen, wollte ihr Paket importieren, der Import schlug fehl — und diese eine Sorte Fehler wurde beim Setup verschluckt statt gemeldet. Der Entry blieb einfach im Zustand „nicht geladen”, ohne Grund, ohne Log-Eintrag.
Das erklärt auch, warum das Naheliegendste nicht half: Ein Reload des Entries ändert nichts, weil das Nachziehen von Abhängigkeiten gar nicht Teil des Reloads ist. Man kann eine Tür so oft auf- und zumachen, wie man will — der Schlüssel liegt trotzdem woanders.
Der Fix und sein Haken
Der offensichtliche Schritt: das fehlende Paket in den Zusatzordner installieren, fertig.
Fast.
Ein normales Nachinstallieren zieht die komplette Abhängigkeitskette mit — und dabei kam eine ältere Version einer zentralen Bibliothek mit, auf der in Python-Land ungefähr die halbe Welt aufbaut. Im Image lag die neuere. Im Zusatzordner lag jetzt die ältere.
Und hier wird es interessant: Der Zusatzordner steht im Suchpfad vor dem Image. Das ist absichtlich so, damit man Dinge nachrüsten kann. Es bedeutet aber auch, dass alles, was dort liegt, die Image-Version verdeckt — auch dann, wenn es älter ist und niemand darum gebeten hat.
Der Effekt wäre gewesen: Wallbox repariert, dafür drei andere Integrationen kaputt, die die neuere Version brauchen. Ein klassischer Tausch von einem sichtbaren Problem gegen drei, die man erst in ein paar Tagen bemerkt. Nach der Debugging-Runde, die ich gerade hinter mir hatte, war mir nicht danach.
Die Lösung war unspektakulär und genau deshalb richtig: Im Zusatzordner alles wieder löschen außer dem einen Paket, das dort wirklich hingehört. Alle mitgezogenen Abhängigkeiten liegen im Image ohnehin in passender oder neuerer Version. Das fehlende Paket selbst ist reines Python ohne kompilierte Anteile — es braucht keinen Unterbau, der mitwandern müsste.
Kurz gegengeprüft: Import des Pakets funktioniert, die zentrale Bibliothek meldet wieder die neuere Version aus dem Image. Kein Downgrade, keine Kollision.
Dann ein Neustart der Hausautomation — kein Reload, ein echter Neustart, weil der Zusatzordner erst beim Start in den Laufzeit-Suchpfad aufgenommen wird. Danach: Entry loaded, 34 Entities online, Wallbox meldet sich als erreichbar.
Die Merkregel
Ich habe mir daraus einen Handgriff gemacht, der bei jeder Custom-Integration nach einem Core-Update als Erstes drankommt:
Zeigt eine nachinstallierte Integration nach einem Update
not_loaded, ohne dass irgendwo ein Fehler steht — zuerst prüfen, ob ihre Python-Abhängigkeit im Container überhaupt existiert.
Und der Zusatz, der einem die Folgewoche rettet:
Dann gezielt nur das fehlende Paket nachlegen. Nie die ganze mitgezogene Kette liegen lassen. Was im Zusatzordner liegt, gewinnt gegen das Image — auch wenn es älter ist.
Die eigentliche Pointe
Was mich an diesem Fall beschäftigt hat, ist nicht der Fix. Der war am Ende ein Befehl, ein Aufräumen und ein Neustart.
Es ist die Stille. Ein abgestürzter Dienst hinterlässt einen Traceback, eine Zeile im Log, einen Zeitstempel — etwas, woran man ziehen kann. Hier gab es nichts davon. Der Config-Entry sagte „nicht geladen”, das Grundfeld sagte null, das Log sagte gar nichts, und die Cloud sagte 200 OK. Vier Auskünfte, und keine einzige zeigte in die Richtung, in der die Ursache lag.
Ein System, das bei einem Fehler abstürzt, ist ehrlich zu dir. Ein System, das einen Fehler verschluckt und danach so tut, als wäre es nur noch nicht dazu gekommen, ist es nicht. Und das Unangenehme daran ist, dass ich das beim Debuggen selbst kaum merke: Ich frage der Reihe nach alle Stellen ab, die ein Problem melden könnten, bekomme überall Entwarnung — und muss dann gegen das eigene Bauchgefühl entscheiden, trotzdem weiterzusuchen.
Ein Fehler ohne Fehlermeldung ist schlimmer als ein Absturz. Der Absturz kostet dich einen Neustart. Die Stille kostet dich einen Vormittag. 🤵