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

Begonnen von Klaus.A, 09 September 2025, 10:28:01

Vorheriges Thema - Nächstes Thema

Jamo

Zitat von: mrprohl2 am 27 Oktober 2025, 17:50:54.
.
Update: Die Lösung über einen Reverse Proxy ist deutlich eleganter, da die SSL Verbindung die Lampen sehr langsam ein-/ausschalten...
.
.

Sehr interessant. Das die neue Hue Bridge Pro die Lampen langsamer als vorher ein/ausschaltet, war mir auch direkt aufgefallen, hab aber gedacht "kann ja irgendwie nicht sein". Ist aber so, kann ich bestätigen.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

mrprohl2

#16
Für alle die das gleiche Problem haben, lade ich nun noch einmal die vollständige fertige Config hoch:

Docker yaml:
version: '3'
services:
  hue-proxy:
    container_name: hue-proxy
    hostname: hue-proxy
    image: caddy:latest
    volumes:
      - conf:/etc/caddy
      - data:/data/caddy
      - config:/config/caddy
    mac_address: BC-24-11-F5-99-55
    networks:
      dockervlan:
        priority: 100
        ipv4_address: 192.168.100.245
    ports:
      - 80:80
    restart: unless-stopped
     
volumes:
  conf:
  data:
  config:

networks:
  dockervlan:
    name: dockervlan
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: "192.168.100.0/24"
          ip_range: "192.168.100.0/24"
          gateway: "192.168.100.100"

Caddy Config:
{
acme_ca https://acme-v02.api.letsencrypt.org/directory
email valid@domain.de
}

http://192.168.100.245 {
reverse_proxy https://192.168.100.240 {
        transport http {
            tls
            tls_insecure_skip_verify
        }
    }
}

https://192.168.100.245 {
reverse_proxy https://192.168.100.240 {
        transport http {
            tls
            tls_insecure_skip_verify
        }
    }
}

Bei funktioniert dies so seit mehreren Tagen einwandfrei. In der fhem.cfg habe ich die IP des Caddy Servers angegeben, also 192.168.100.245. Die angepasste HUEBridge.pm habe ich noch beigefügt.


@Jamo:
Die v3 ist nicht langsam, sondern die https Verbindung mittels der Anpassung in der HUEBridge.pm ist zu langsam.

Neeein

Bei mir funktioniert die alte Integration warum auch immer noch, aber dafür habe ich 100 Prozent Auslastung auf der CPU und einfach ALLES ist sehr lahm geworden was mit FHEM zu tun hat...
Ich möchte eigentlich weniger "spielen" mit FHEM, aber das ist echt nicht tragbar.

Scheinbar ist keiner mehr mit der HUE-Integration beschäftigt...

Ich schreibe mal, damit ich auf dem Laufenden bleibe

Hotbird

nur gut das ich erstmal hier geschaut habe. Hab mir eben die Hue Bridge Pro bestellt... Wird wohl erstmal nicht in FHEM eingebunden....

Klaus.A

Ich setze die Info/Diskussion im Bereich "ZigBee" fort, weil dort der Maintainer für die FHEM-Hue-Module angeblich unterwegs ist (lt. Liste Maintainer.txt).

Mit der Hue Bridge Pro (v3) gibt es widersprüchliche und sonderbare Ergebnisse. Vieles ist da unklar.

Gruß Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) HomeBridge für Homekit-/Siri-Integration. 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge v2 und v3 (im Test), IRTrans IR-Konverter, AutoMower via API

mystex

Hallo zusammen,
ich war wohl auch zu schnell und habe mir die neue Bridge bestellt ohne den gesamten Beitrag zu lesen. Sah ja erst ganz easy aus, die neue Bridge einzubinden und bei einigen scheint es ja auch tatsächlich ohne Probleme und Performance-Einbußen geklappt zu haben. Ich würde gerne erst testen, ob ich die neue Bridge "sauber" in FHEM anbinden kann. Wenn ich es richtig gelesen habe wird bei der Migration von v2 auf v3 die "alte" Bridge zurückgesetzt und so wäre es dann auch nicht mehr möglich ein FHEM Backup einzuspielen und die "alte" Bridge weiter zu nutzen, falls es mit der Neuen nicht funktioniert.

Weiß jemand, ob man die Migration von v2 auf v3 auch später durchführen kann? Aktuelle Idee ist "alte" Bridge "abschalten". Neue Bridge ohne Migration in FHEM einbinden. Vorher vielleicht noch über die HUE App eine Testlampe (hab noch ein bisher ungenutztes HUE Leuchtmittel) anlegen. Sollte die Anbindung der neuen Bridge dann reibungslos laufen, die Bridge auf Werkseinstellungen setzen und dann die Migration von v2 auf v3 machen. Bin halt nur etwas unsicher, ob die Möglichkeit der Migration weiterhin besteht, wenn die Bridge bereits im Einsatz war.

Vielleicht hat auch noch jemand einen anderen Lösungsansatz für mich. Hab keine Idee, wie ich es ansonsten testen soll, ohne mir die ganze HUE Integration zu zerschießen, falls es nicht läuft.

Gruß,
Rene


Klaus.A

@Rene

Ja, bei einigen funktioniert es, bei vielen nicht. Was ich bisher weiß, auch aus anderen Foren: Es liegt an der Bridge Firmware, genauer ist es die Implementierung der Zertifikate. Mit der Original hue App funktioniert alles, nur die API hat ein Problem: Wenn die externe Anwendung (z.B. FHEM) die Validierung der Zertifikate auslöst (was standardmäßig erforderlich und sinnvoll ist) dann schlägt diese Validierung in den meisten Fällen fehl. Es liegt daran wie der Betriebssystem bzw. Browser-Komponenten diese Validierung durchführen. Ein bestimmtes Feld (SAN = Subject Alternative Name) ist nicht wie erwartet besetzt, daher das negative Ergebnis.

Andere Systeme versuchen zur Zeit die Validierung zu umgehen - ein Verfahren das äußerst problematisch gesehen wird, weil es "Man-in-the-Middle" Attacken ermöglichen kann.

Zur Migration, so wie ich es bisher getestet habe: Man kann die bisherige Bridge (v2) unverändert lassen und die neue hue Bridge Pro (v3) zusätzlich in FHEM definieren. Da passiert erst einmal nichts mit der bestehenden Installation. Dann sieht man ob die Einbindung erfolgreich ist.

Die Migration der Lampen von v2 auf v3 ist jederzeit später möglich. Man könnte sie auch nochmals auf Werkseinstellungen wieder zurück setzen und dann die Migration durchführen.

Richtig, wenn man die Migration im hue System macht dann wird die v2 Bridge am Ende zurück gesetzt. Wenn dann die Anbindung von FHEM nicht funktioniert dann hat man ein großes Problem: Zurück von v3 auf v2 geht nicht und die Bridge v2 ist dann auch "leer".

Ich konnte noch nicht eine komplette Neuinstallation meines gesamten Systems testen (bin zur Zeit noch aus gesundheitlichen Gründen blockiert). Es wird interessant was mit der neuesten Armbian OS Version (Trixie) passiert. Ich warte auch auf einen Firmware-Update von Philips/Signfy für die hue Bridge Pro. Das Problem liegt in der Firmware der Bridge, nicht im FHEM hue Bridge Modul - das kann das geforderte HTTPS (bereits für die Bridge v2) und wie ich gesehen habe läuft es auch mit ein paar OS-Varianten/Konfigurationen. Da kamen korrekte Daten von der neuen Bridge zurück.

Gruß Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) HomeBridge für Homekit-/Siri-Integration. 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge v2 und v3 (im Test), IRTrans IR-Konverter, AutoMower via API