[Frage] EDOMI Container

[tger977]

Hallo zusammen,

ich versuche gerade den EDOMI Docker Container zum laufen zu bringen. Zumindest habe ich mittlerweile Zugriff auf die Admin Oberfläche...

ABER:

Der EDOMI Docker Container benötigt zwingend auch Zugriff auf die Ports 8080 (Websocket für die Visu in EDOMI) und auch den Port 3671 für den KNX Traffic. Diese Ports sind ja aber im TW schon belegt...

Wie kann ich das lösen? Ideen?

[gbglace]

Es gibt hier einen laufenden Thread der sich bereits mit den vom TWS verwendeten Ports beschäftigt und wie diese für Docker nutzbar gemacht werden können.

viewtopic.php?f=31&t=35&p=143&hilit=http+ports#p143

Schau Dir den mal an und verfolge ihn.

[tger977]

welchen meinst Du da genau?

In diesem hier habe ich nur die Info gefunden daß die Ports schon belegt sind:
viewtopic.php?f=25&t=49

[gbglace]

Ja genau den, dort wird sicher auch ne Lösung gefunden werden wie damit umzugehen sein wird. Ein mächtiger Docker wie EDOMI braucht ja sehr viel das der TWS selbst auch nutzt.

[StefanW]

Ich bespreche das mit meinen Entwicklern

lg

Stefan

[tger977]

also, den Port 8080 kann ich in EDOMI auf einen anderen port umbiegen. Websocket / Visu geht jetzt damit auch.

Einzig der KNX Zugriff geht derzeit noch nicht (port 3671). Ich habe zwar auch dafür eine Einstellmöglichkeit in der EDOMI Ini, aber das scheint mit anderen Portnummern nicht zu funktionieren oder es gibt da noch ein anderes Problem. Oder kann das noch an dem Tunnelanzahlproblem liegen? Allerdings habe ich als KNX Gateway sowohl auf dem Wiregate mit seriellem TPUart+eibd als auch mit dem TW+TPUart2 bisher kein Erfolg.

Ich probiere und suche weiter...

[StefanW]

Der port 3671 ist der von der KNX Assoc. vorgesehene Port für den IP-Tunnel.

Unser eigener KNX Stack mit dem Tunneling Interfaces reagiert bei Anfragen auf diesen Port.

Der Punkt ist womöglich, diesen Port geshared zu öffnen, nicht exklusiv für sich alleine. Der eibd z,B, will den Port für sich alleine, daher muss man ihm das beibringen, den Port geshared zu öffnen.

Ich kennen edomi nicht, womöglich ist das ein Ansatz? Benötigt edomi den Port ausgehend (um einen Tunnel anzusprechen) oder eingehend bei sich? Weil wenn letzteres, dann "kämpfen" womöglich zwei Applikationen (unser Stack und edomi) um den Port.

lg

Stefan

[tger977]

das Problem ist schon, dass ich in Portainer keinen Container erzeugen kann wenn ich den Port 3671 mappen möchte, da dieser durch den TW selbst schon belegt ist... Man müsste also Portainer beibringen den Port geshared zu öffnen...

Hinzugefügt nach 44 Minuten 13 Sekunden:
ich habe jetzt mal einfach anstatt 3671:3671 einen anderen port 3669:3669 für den Container gemappt. Da der Timberwolf ja derzeit nur einen Tunnel kann war nun die Idee diesen Port auf meine Wiregateschnittstelle x.x.x.x:3671 (kann bei anderen ja dann eine andere IP-Schnittstelle sein...) weiter zu leiten. Geht das irgendwie und hat jemand eine Idee?

[jockel]

Was mir nicht klar ist, aber ich kenne Edomi auch nicht: Warum wird der Port 3671 für eingehende Verbindungen gebraucht? Hast Du vielleicht irgendwo einen Link zur Installation in der die Verbindung mit dem KNX Bus beschreibt? Wenn der Port nach außen von Docker auf eine. anderen gemappt wird, sollte Edomi nichts davon mitbekommen.

Mehrere verschiedene Anwendungen die auf dem gleichen Interface und Port hören wird nicht funktionieren, aber mit Sicherheit auch nicht nötig sein.

[tws88_user]

Ich habe mir jetzt 72h fast am Stück die Haare mit diesem Thema Docker/Portainer und insbes. „Portmapping“ gerauft. Meine Güte .... eh ich erstmal gechecked habe, wie man überhaupt eine in einem Container laufende App im Browser öffnet....

Zum Schluss habe ich es geschafft, einen Container per vorgegebenen Template sowie einen aus einem externen Image (aber dennoch DockerRegistry) durch Klicking powered by Portainer@TWS zum Laufen zu bringen. Viele Fragen bleiben noch, bspw. Portmapping/Bereitstellung für Container, die auf KNX und anderes zugreifen, Backup von Containern. Beibehaltung von Einstellungen, Daten usw. bei Update (oder anderem Grund, einen Container zu killen, removen etc.). Fragen über Fragen. Aber soweit großes Lob für euch, Stefan! Ich kann es wie immer nicht präzise darlegen, fühle aber großes Potenzial in den Funktionen.