HUEBridge und Phoscon Software im Docker Container

[DS_Starter]

Hallo zusammen,

ich habe die Phoscon Software im Docker Container installiert und somit sind die entsprechenden Container-Ports auf Host-Ports gemappt.
Ich konnte die Definition der HUEBridge und das Pairing mit Angabe des Host Ports erfolgreich durchführen:

Code Auswählen Erweitern

defmod deCONZ HUEBridge 192.168.2.10:32785
attr deCONZ httpUtils 1
attr deCONZ key XXXXXXX
attr deCONZ noshutdown 1
attr deCONZ room Dienste->Gateways

Log:

Code Auswählen Erweitern

2021.03.27 09:36:30.913 2: HUEBridge_OpenDev: got empty config
2021.03.27 09:46:50.575 3: deCONZ_HUEGroup1: I/O device is deCONZ
2021.03.27 09:46:50.683 3: deCONZ_HUEGroup0: I/O device is deCONZ
2021.03.27 09:46:50.794 2: deCONZ: autocreated 2 devices

Allerdings erscheinen nun im Log diese Fehler weil der Port 443 ebenfalls auf einen anderen Host-Port (32784) gemappt ist:

Code Auswählen Erweitern


2021.03.27 09:53:50.575 3: deCONZ: websocket opened to 192.168.2.10:443
2021.03.27 09:53:50.588 2: deCONZ: websocket: Switching Protocols failed
2021.03.27 09:53:50.588 2: deCONZ: websocket closed


Frage ist nun ob man das Mapping irgendwo einstellen kann oder ob das ignoriert werden kann. Könnte mir vorstellen dass es Probleme in der Funktion geben könnte. Ich stehe mit der Phoscon Einbindung noch am Anfang.
Es wurden initial 2 Devices/Gruppen aus Phoscon angelegt. Also scheint schon einiges zu funktionieren, bin mir allerdings unsicher.

Grüße,
Heiko

[Otto123]

Hallo Heiko,

Du bist schon im Herbst? (hast es korrigiert )
Du hast das extra in einem vorhandenem Container installiert? Warum hast Du nicht einfach das existierende docker Image  genommen?
image: marthoc/deconz

Ich gebe zu ich habe das dort gelassen wie es ist. Die Verwendung von Ports ist im HUEBridge Modul nicht wirklich dokumentiert

Gruß Otto

[DS_Starter]

Moin Otto

ähh, ich habe das Image marthoc/deconz benutzt und in den Syno Docker geladen.

Dann hat man die Port-Mappings wie im Screen zu sehen. Die Ports 80/443 sind auf der Syno schon anderweitig belegt.

[Otto123]

Ok klang so als Ob Du in einem anderen Container was installiert hast. Weil das Image muss man doch nur starten?
Man müsset mal in den Code schauen, ich glaube das Modul ist primär für die HUEBridge   gemacht, das ist ne extra Kiste und da können die Ports auf Standard bleiben. 

Ich kann momentan leider nicht helfen - nur mitlesen

[DS_Starter]

Habe mich ein bisschen in den Code reingelesen.
In dem Block ab Zeile 417 habe ich die Zuweisung zu $hash->{websocketport} auf meinen https Mapped Port testweise fest eingetragen. Damit klappt es jetzt einwandfrei.

Code Auswählen Erweitern


  if( defined($config->{websocketport}) ) {
    # $hash->{websocketport} = $config->{websocketport};
    $hash->{websocketport} = "32784";
    HUEBridge_openWebsocket($hash) if( !defined($hash->{CD}) );
  }


Werde mir jetzt in dem Modul ein Attribut mapHttpsPort dafür anlegen. Damit ist das flexibel. Für mein Standard Philipps HUE Gateway soll das ja nicht gesetzt sein.

@ justme1968, möglicherweise ist dieser Workaround noch nicht das Beste was man machen kann. Würde mich freuen wenn du dir die Sache mal anschauen würdest.

LG,
Heiko

[justme1968]

der port der für die websockets zu verwenden ist wird von der gegenseite (d.h. von deconz) im api mit geliefert. d.h wenn hier für docker irgendetwas umgebogen wird muss man auch dafür sorgen das deconz etwas davon 'weiß' und den richtigen port im api angeben kann. alles andere ist schlimmes gefrickel.

also wenn man wirklich den docker mist verwenden will: bitte auf decons seite für den richtigen port sorgen. wenn das nicht möglich ist: dort ein vorschlag oder bug aufmachen.

ps: genau diese intransparente port umbiegerei ist einer der gründe warum docker einfach nur eine unsaubere behelfslösung ist. wenn es irgendwie möglich ist bitte lieber richtige virtualisierung verwenden.

[Otto123]

Heiko und ich haben es gerade genau herausgefunden wie Du schreibst. Man darf das Port nicht von drinnen nach draußen im docker ummappen sondern sauber dem deconz mit der Variable - DECONZ_WS_PORT=443 mitteilen.

Danke für die Antwort! Alles ordentlich

[DS_Starter]

Kann Otto bestätigen 
Man kann über die Umgebungsvariablen DECONZ_WEB_PORT und DECONZ_WS_PORT direkt den Port innerhalb des Containers auf den benötigten Wert setzen. Dann entfällt das Mapping.

Ich bin übrigens auch kein Dockerfreund und setze auf VMWare für Virtualisierung. Aber für manche Dinge und und schnelle Lösungen ist Docker ganz praktisch.

@Otto ... DECONZ_WS_PORT = 32784 ist der richtige set (in meinem Fall). Das neue setting ist im Screenshot zu sehen.

Danke auch nochmal an Otto ! 
Heiko

[dreizehn]

Vielen Dank für die Erklärung!
Ich habe ewig gesucht warum Sensoren nicht direkt aktualisiert werden. Ich habe vergessen den DECONZ_WS_PORT zu setzen und weiterzuleiten. Das HUEBridge modul/device meldet leider nur den STATE connected, da kommt man nicht so schnell dahinter wo das Problem ist.

Vielleicht ist das auch ein Fall für das Wiki. Das mit den Zweiten Port eine neue Verbindung aufgebat wird war mir zumindest nicht bewust.