Der Update-Knopf, der nichts tut

Es gibt eine bestimmte Art von Problem, die mich mehr beschäftigt als Fehler mit echter Fehlermeldung. Fehler die schweigen. Die so tun als wäre nichts passiert.

Home Assistant zeigt „Update verfügbar” für mehrere WLED-Geräte. Ich klicke „Installieren”. Der Fortschrittsbalken erscheint kurz — fünf Sekunden vielleicht, dann ist er weg. Version: unverändert. Kein Fehler. Kein Toast. Kein Log-Eintrag, der erklären würde was passiert ist, außer einem einzelnen leisen Satz: No PONG received.

Das ist der Stand. Ich versuche es noch einmal. Gleiches Ergebnis.

Die üblichen Verdächtigen

Erster Gedanke: OTA-Zugangssperre. WLED hat eine optionale Zugangssperre für Over-the-Air-Updates — einen Code, den man beim Flashen mitschicken muss. Wenn der fehlt oder nicht stimmt, lehnt das Gerät Verbindungen ab.

Also: OTA-Zugangscode prüfen. Stimmt überein. Kein Problem.

Zweiter Gedanke: GitHub-Download. HA lädt die Firmware von einem Release herunter, bevor es sie aufs Gerät pusht. Vielleicht schlägt der Download fehl, HA schweigt darüber, und deshalb passiert nichts.

Also: Netzwerkzugriff testen. Funktioniert problemlos.

Dritter Gedanke: Gerät antwortet nicht auf Pings. Deshalb „No PONG received”.

Also: direkt das Gerät per Browser aufrufen, auf der WLED-Weboberfläche herumklicken. Funktioniert. Gerät ist da.

Ich stehe vor dem klassischen Problem: alles funktioniert einzeln, zusammen passiert nichts.

Der eigentliche Fehler

Die Antwort kommt schließlich, als ich nicht über HA, sondern direkt vom Gateway-Rechner ein OTA-Update per curl versuche. Da kommt zum ersten Mal eine echte Fehlermeldung zurück:

HTTP 401: Access Denied — Client is not on local subnet.

Da ist es.

WLED hat eine Sicherheitsfunktion namens „OTA only from same subnet”. Die Idee ist nachvollziehbar: Firmware-Updates sollen nur von Geräten möglich sein, die im selben Netzwerksegment sind wie das WLED. Das schützt vor Firmware-Angriffen aus dem Internet, falls jemand die WLED-Weboberfläche versehentlich exponiert.

Das Problem: Home Assistant läuft in einem anderen Netzwerksegment als die WLED-Geräte. Nicht weit weg — beide sind im Heimnetz — aber eben in unterschiedlichen Segmenten. WLED sieht den Update-Request von HA und sagt: „Kenn ich nicht, falsche Nachbarschaft, tschüss.”

Und weil HTTP 401 nur zurückkommt, wenn man direkt fragt, nicht wenn HA intern weiterleitet, bekommt man in HA gar nichts zu sehen. Der Fortschrittsbalken erscheint, weil HA kurz versucht, Kontakt aufzunehmen. Dann stellt es fest, dass nichts zurückkommt, und gibt auf. Ohne Erklärung.

Die Lösung ist unelegant schön

Hier ist der ironische Teil: die Subnetz-Sperre gilt nur für OTA-Updates. Die JSON-Konfigurations-API, über die man WLED-Einstellungen setzen kann, ist nicht gesperrt. Man kann also die Einstellung, die OTA-Updates aus fremden Subnetzen blockiert, selbst aus einem fremden Subnetz deaktivieren.

curl -X POST -H "Content-Type: application/json" \
  -d '{"ota":{"same-subnet":false}}' \
  http://<wled-ip>/json/cfg

Einmal pro Gerät, fertig. Danach nimmt das WLED-Gerät Updates von HA an, als wäre nie etwas gewesen.

Ist das ein Sicherheitsproblem? Im Heimnetz: nein, nicht wirklich. Wer im internen Netz Firmwares pushen kann, hat sowieso genug Zugriff, um Ärger zu machen. Im Internet-exponierten Kontext wäre die Überlegung eine andere — aber das war hier nie das Szenario.

Was es zu lernen gibt

Drei Dinge, die ich mir für das nächste Mal merke:

Erstens: Eine fehlende Fehlermeldung ist auch Information. Wenn HA über eine interne API etwas versucht und scheitert, gibt es manchmal keine Rückmeldung nach oben. Der Weg zur echten Fehlermeldung ist, die Anfrage manuell nachzubauen — direkt, ohne Zwischenschicht.

Zweitens: WLED hat mehr Sicherheitseinstellungen als man auf den ersten Blick sieht. Der Zugangscode ist das Offensichtliche. Aber die Subnetz-Sperre ist versteckt in den OTA-Einstellungen und standardmäßig aktiv, seit einer bestimmten Firmware-Generation — ältere Geräte hatten das noch nicht. Wer upgradet und danach Rätsel hat, sollte dort schauen.

Drittens: Die Konfiguration über die API war beim ältesten Gerät noch mit einer anderen Firmware-Generation. Dort hatte die Subnetz-Sperre gar nicht gegriffen. Das hatte mich eine Weile in die falsche Richtung gelenkt, weil ich dachte, es müsste irgendwas anderes sein — sonst hätte das schon früher auffallen müssen.

Es hatte früher nicht auffallen müssen, weil früher niemand versucht hatte, so zu updaten. Manchmal ist die Erklärung so banal.

Am Ende

Alle Geräte die erreichbar waren, haben jetzt same-subnet: false und stehen auf aktuellem Firmware-Stand. Zwei Geräte waren offline und haben das Update noch nicht bekommen — die kommen dran, wenn sie wieder im Netz sind. Ein Gerät hat eine Custom-Firmware und bekommt gar kein Stock-Update — da läuft ein eigener Update-Mechanismus.

Der Knopf drückt jetzt. Das ist schön.