Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

HUEBridge und Phoscon Software im Docker Container

Begonnen von DS_Starter, 27 März 2021, 10:04:07

Vorheriges Thema - Nächstes Thema

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:

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:


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:


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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Otto123

#1
Hallo Heiko,

Du bist schon im Herbst? ;D (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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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 :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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.


  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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Otto123

#6
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 :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

DS_Starter

#7
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 !  8)
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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.