Hue Bridge Pro (v3) - Migration in FHEM wie?

[taskkill]

Nach etlichen Stunden läuft jetzt wieder (fast) alles. Die Osram Lightifys wollen nur zum Teil. Was nicht geht wird jetzt ersetzt.

Die kannste doch alle über Zigbee2Mqtt betreiben, wenn Du hast.

[Smart_Homer]

Hallo,

ich bin jetzt ein bischen verwirrt, wie der aktuelle Stand ist. Hab mit der Migartion extra noch gewartet, weil das ja am Anfang noch nicht sauber lief in FHEM..

Kann man jetzt gefahrlos die V2 nach V3 migrieren und dann läuft die V3 einfach auf der gleichen IP wie die V2 weiter oder muss man noch einen workaround bauen?

Vielen Dank für die Hilfe und Eure Arbeit.

[Klaus.A]

Aktueller Stand: Wie Beiträge zu dem Thema (auch im "ZigBee" Bereich des Forums) zeigen, funktioniert es angeblich auf einigen Systemen ohne Modifikation, auf einigen mit Anpassungen und es gibt Systeme da hilft bisher nichts. Es kommt auf das Betriebssystem bzw. dessen aktuellem Stand an. Auf meinem System bisher kein Erfolg - das Betriebssystem ist "zu alt". Da die Bridge Pro aber noch andere Probleme hat, z.B. mit dem Zusammenspiel mit Apple Home, habe ich immer noch die alte Bridge (v2) und warte die Entwicklung weiter ab. Signify hat da noch eine große Baustelle.

Was ich bisher recherchieren konnte und verstanden habe:

Die Bridge Pro (v3) akzeptiert nur HTTPS-Verbindungen. Die alte Bridge (v2) hat ein Fallback zu HTTP.
Das Zertifikat für die HTTPS-Verbindung muss von Betriebssystem-Komponenten (bzw. Browser-Komponenten) verifiziert werden. Das verläuft immer erfolgreich bei Zugriffen innerhalb der Hue App, kann aber zu Problemen bei Zugriffen über die API führen. Es kommt darauf an, wie die Betriebssystem-Komponenten prüfen und wie das Systemverhalten mit dem Ergebnis umgeht.

Das Zertifikat in der Bridge wurde inzwischen (von Signify) mehrfach angepasst. Es fehlt immer noch das SAN-Feld (Subject Alternative Name) zur Verifizierung des Servers. Die Prüfung ist nicht erfolgreich, weil die Zertifikatkette nicht vollständig verifiziert werden kann.

Das kann - muss aber nicht - zu einem Abbruch führen und Folgekationen werden abgewiesen. Dann kann es mit dem aktuellen HueBridge.pm Modul zu Fehlern im FHEM-Log kommen (u.a. "invalid JSON"). Die Bridge bleibt dann in FHEM mit dem Status "initialized" hängen.

Bisher sind zwei Lösungen in FHEM bekannt:

• Anpassung im Modul HueBridge.pm (2 Zeilen)
• oder: Installation eines Reverse Proxy

Der ursprüngliche Autor des FHEM-Moduls ist offensichtlich nicht mehr aktiv, eine neue Zuständigkeit ist mir nicht bekannt. (Die Info in der "Maintainer.txt" sind veraltet.) Es gibt daher keine offizielle Wartung für das FHEM Modul. Die Änderungen muss jeder selbst vornehmen und testen.

Beide Lösungen (Umgehung des Problems) wirken wie folgt: Das System wird angewiesen, die Prüfung des Zertifikats bei negativem Ergebnis zu ignorieren und trotzdem die HTTPS-Verbindung aufzubauen. Beim Reverse Proxy ist es der Parameter "tls_insecure_skip_verify", der schon im Namen verrät was er macht.

Ich habe diese Work Arounds in meinem System noch nicht getestet (war wegen schwerer Krankheit lange Zeit nicht möglich). Wie Beiträge zeigen, sollte aber jede dieser Varianten erfolgreich sein.

In jedem Fall empfehle ich zunächst zu testen ob die Bridge in FHEM eingebunden werden kann. Wenn nicht, kann man sie aus FHEM wieder problemlos löschen.
Eine Migration im Hue System ohne vorherigen Test der Einbindung in FHEM ist gefährlich, weil es nach Abschluss der kompletten Migration in Hue keinen Weg zurück gibt!

(Wenn ich wieder in besserem Zustand bin dann werde ich mit meinem System weiter testen, auch das komplette Betriebssystem auf aktuellem Stand neu aufsetzen. Das wird noch etwas dauern, dann gibt es wieder Updates. Es könnte auch sein dass meine Bridge einen Defekt hat ... eine neue Bridge Pro ist schon angekommen. Das wäre ein weiterer Test).

Gruß, Klaus