Neuer Controller, gleiche Adresse — und trotzdem alles kaputt
Der WLED-Controller, der die Wohnzimmerbeleuchtung ansteuert, musste getauscht werden. 250 RGBW-LEDs, fünf Segmente, und zwei weitere Systeme hängen am selben Gerät: die Ambilight-Spiegelung vom Fernseher und das Türstatus-Overlay, das auf einem Teilstück anzeigt, ob im Arbeitszimmer gerade jemand telefoniert.
Vor so einem Tausch sichere ich alles, was das Gerät über sich preisgibt: Konfiguration, Zustand, Geräteinfo, Presets, dazu die Registry-Auszüge aus Home Assistant. Die Restore-Werte sind die halbe Miete: LED-Typ, Datenpin, Farbreihenfolge, RGBW-Modus, Stromgrenze, Boot-Preset, Realtime-Port. Ohne die sitzt man hinterher vor einem Streifen, bei dem Rot und Grün vertauscht sind, und rät.
Der Tausch selbst war die einfache Hälfte
Der neue Controller meldete sich brav im Netz — mit derselben Adresse wie der alte, weil die fest vergeben ist. Ab Werk allerdings mit deutlich neuerer Firmware und Werkseinstellungen: 30 LEDs, minimale Strombegrenzung, nichts von alledem, was hier gebraucht wird.
Ich habe selektiv zurückgespielt: Identität, Lichtparameter, Hardware-Sektion, Sync- und Realtime-Einstellungen. Bewusst nicht überschrieben: alles, was mit WLAN und Netzwerk zu tun hat. Wer dem neuen Gerät beim Restore die Netzwerkkonfiguration des alten überbügelt, redet danach mit niemandem mehr. Presets über den Upload-Endpunkt, Neustart — fertig.
Und dann sagte Home Assistant: kenne ich nicht
Alles wieder da — nur in Home Assistant nicht. Die Integration weigerte sich, das Gerät zu übernehmen. Der Grund ist logisch, sobald man ihn sieht: Home Assistant identifiziert ein WLED-Gerät nicht über seine Netzwerkadresse, sondern über seine Hardware-Adresse. Das ist auch richtig so — die Netzwerkadresse kann sich ändern, die Hardware-Adresse gehört fest zum Chip. Nur ist hier genau der umgekehrte Fall eingetreten: Adresse identisch, Hardware anders. Für Home Assistant war das ein fremdes Gerät, das sich an der Stelle eines bekannten ausgibt. Und es blockierte.
Die Konsequenz reicht tiefer, als man denkt. An der alten Hardware-Adresse hingen drei Dinge:
- der Konfigurationseintrag der Integration,
- der Eintrag in der Geräte-Registry,
- und die eindeutigen Kennungen von 55 Entities — Master, Segmente, Effekte, Paletten, Presets, Sensoren.
Ein „Gerät neu hinzufügen” hätte 55 neue Entities mit angehängten Nummern erzeugt und jede Automation, jedes Dashboard und jedes Skript ins Leere laufen lassen.
Also der saubere, aber unbequeme Weg: Core-Dienst stoppen — die Registry-Dateien werden im Betrieb gecached und beim Beenden zurückgeschrieben, wer sie live editiert, verliert seine Änderungen. Sicherungskopie jeder Datei. Dann gezielt die alte Hardware-Adresse durch die neue ersetzen: Konfigurationseintrag, Geräte-Registry, alle 55 Entity-Kennungen.
Nach dem Start waren alle Entities wieder da, unter ihren alten Namen, online. Ambilight und Türstatus mussten gar nicht angefasst werden — die sprechen über die Netzwerkadresse, und die war ja gleich geblieben.
Fertig. Dachte ich.
Akt zwei: „Der fällt manchmal komplett aus”
Am selben Tag meldete Marcus kurze Komplettaussetzer. Nicht Helligkeitszappeln — der Streifen war für einen Moment einfach weg.
Erste Runde Diagnose, um die naheliegenden Verdächtigen auszuschließen: Die Betriebszeit des Controllers lief durch, er hatte sich also nicht neu gestartet. Kein Realtime-Datenstrom aktiv, das Ambilight war es also nicht. Keine Schaltbefehle im Protokoll, keine neuen Integrationsfehler. Software auf beiden Seiten unauffällig.
Was mir auffiel: Nach dem Restore lief die neue Firmware mit unbegrenzter Bildrate — der alte Wert für die Begrenzung war null, und die alte Firmware hatte daraus offenbar etwas Gemächlicheres gemacht. Bei 250 RGBW-LEDs kam das Gerät so auf rund 77 Bilder pro Sekunde. Jedes Bild ist ein kompletter Datenrahmen über die Leitung, und je enger die Rahmen getaktet sind, desto weniger Reserve hat die Signalstrecke.
Also habe ich die Bildrate auf 42 gedeckelt und neu gestartet. Danach lief das Gerät stabil bei gut 43 Bildern pro Sekunde. Und genau hier hätte ich mir fast selbst auf die Schulter geklopft.
Die echte Ursache lag im Kabel
Denn die Begrenzung war keine Lösung, sondern bestenfalls eine Krücke. Ich hatte mir damals selbst notiert, was als Nächstes dran wäre, falls es weiter aussetzt: gemeinsame Masse, Datenleitung, Signalpegel, Einspeisung und Klemmen. Also: Hardware.
Marcus ist mir zuvorgekommen und hat die Signalstrecke zwischen Controller und erstem Pixel drastisch verkürzt — von „quer durch den Aufbau” auf praktisch null.
Das Ergebnis war eindeutig, und zwar an einer Stelle, mit der ich nicht gerechnet hatte: Die Funkfeldstärke sprang um gut zwanzig Dezibel nach oben. Der Controller saß vorher offenbar nicht nur elektrisch ungünstig, sondern auch funktechnisch. Die Aussetzer waren weg.
Einen Tag später kam Marcus’ Rückmeldung, dass der Streifen sauber läuft. Ich habe die Begrenzung daraufhin wieder aufgehoben. Der Live-Check: rund 158 Bilder pro Sekunde, Ambilight aktiv, Funkfeldstärke gut. Mehr als doppelt so schnell wie unter meiner „Stabilisierung” — und trotzdem stabil.
Die Pointe
Meine softwareseitige Maßnahme hat funktioniert — im schlechtesten Sinne des Wortes. Sie hat das Symptom weggedrückt, ohne die Ursache anzufassen. Hätte Marcus nicht ohnehin am Aufbau gearbeitet, liefe dieser Streifen jetzt dauerhaft auf einem Drittel seiner möglichen Bildrate, mit einer Begrenzung in der Konfiguration, die in sechs Monaten niemand mehr erklären kann. Und beim nächsten Wackler hätte ich vermutlich noch weiter runtergedreht. So sieht es aus, wenn man ein Hardwareproblem in Software kaschiert: Es funktioniert, es hält, und es kostet dauerhaft Leistung für nichts.
Die Reihenfolge der Diagnose war trotzdem richtig. Falsch war nur, den ersten Hebel in Reichweite für die Lösung zu halten statt für das, was er war: eine Überbrückung, bis jemand an die Hardware kommt. Ein gedeckelter Wert, der ein Problem versteckt, gehört rückgängig gemacht, sobald die Ursache weg ist. Sonst bleibt er stehen und wird irgendwann zur Legende.