[FR] Wiregate-Container KNX-Zugriff über IP-Router

[pbm]

Hallo zusammen,

bezugnehmend auf dieses Thema: viewtopic.php?p=22172#p22172

Zur Zeit wird der eibd im aktuellen Wiregate-Container mit folgendem Befehl gestartet.

/usr/bin/eibd -u -i ipt:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0

In meinem Fall (TWS 2400 mit USB-TP-UART mit einem Tunnel) benötige ich den Zugriff des Wiregate-Containers auf den KNX über meinen KNX-IP-Router.

Das funktioniert aber nur, wenn der Befehl folgendermaßen geändert wird.

/usr/bin/eibd -u -i iptn:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0


Vielleicht kann @Gabi das auch kurz und knapp beantworten:

Kommt eine neue Container-Version, ist meine Änderung wieder weg...
Ist es möglich, dass der eibd immer mit "iptn" gestartet wird, oder spricht etwas dagegen?
(beim Cometvisu-Container wird auch mit "iptn" gestartet (wenn auch der knxd))

- Falls ja: Ist es möglich, das in der nächsten Container-Version mit einzubauen?

- Falls nein: Ist es möglich statt dem fixen Parameter "ipt" eine Variable einzuführen, die dann im Konfigfenster der App editierbar wird:

Dropdown für Variable $KNXMODUS = 'ip'; 'ipt'; 'iptn'

und in /usr/bin/start_services.sh dann die Zeile ändern:

/usr/bin/eibd -u -i $KNXMODUS:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0


Braucht das überhaupt irgendwer?!?

[StefanW]

Hallo Peer,

ich kenne die Kommandozeilenparameter von eibd nicht auswendig und verstehe Deinen FR nicht.

Womöglich geht es anderen auch so. Was man nicht versteht, dafür kann man auch nicht voten. Wür mich gilt, was ich nicht verstehe, kann ich auch nicht in Auftrag geben.

Darum bitte alle Vor- und Nachteile des FR auch erklären.

lg

Stefan

[pbm]

Hallo Stefan,

die Ausgangslage ist folgende:

Mit einem TWS 2400 und einem „TP-UART mit nur einem Tunnel“, kann die KNX-Verbindung von Docker-Containern nicht genutzt werden.
(Das ist meines Wissens die aktuell mögliche/lieferbare Kombination mit dem TWS2400)

Da man den KNX-Zugriff aber mindestens für den Wiregate-Container in der Übergangszeit benötigt, muss eine andere Lösung gefunden werden.

Ein Weg ist die Nutzung eines KNX-IP-Routers.

In der von ElabNET gelieferten Wiregate-Container-Konfiguration funktioniert die Verbindung zu einem KNX-IP-Router nicht.

Daher habe ich in der Container-Konfiguration eine Änderung vorgenommen,
die jedoch wieder überschrieben wird, wenn eine neue Container-Version veröffentlicht werden sollte.
(Oder die aktuelle nochmal deployed wird)


Mögliche Lösung:

Im nächsten Wiregate-Container-Image von ElabNET die Datei „/usr/bin/start_services.sh“ ändern:

von /usr/bin/eibd -u -i ipt:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0

auf /usr/bin/eibd -u -i iptn:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0


Vorausgesetzt, es ist möglich, dass diese Parameteränderung für alle Anwendungsfälle funktioniert.
(beim Cometvisu-Container wird auch mit "iptn" gestartet (dort wird aber der knxd verwendet))

Wenn das nicht alle Anwendungsfälle abdeckt, wäre folgende Möglichkeit eine Alternative:

Statt dem fixen Parameter "ipt", soll eine Variable eingeführt werden, die im Konfig-Fenster der App editierbar ist:

Dafür ein Dropdown für die neue Variable $KNXMODUS = 'ip'; 'ipt'; 'iptn' im Parameter-Fenster einbauen.

In der /usr/bin/start_services.sh dann die Zeile ändern:

/usr/bin/eibd -u -i $KNXMODUS:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0

Warum das mit dem geänderten Parameter funktioniert, weiß ich auch nicht.
Ich hab einfach beim Cometvisu-Container abgeguckt...

Ich hoffe, das ist jetzt verständlich, auch wenn es nahezu der gleiche Inhalt meines vorherigen Posts war.

Falls noch Unklarheiten bestehen, bitte eine Präzise Frage dazu stellen.
Ich weiß nicht, wie ich es sonst besser erläutern soll...

[Robert_Mini]

Vielleicht kann ja @Chris M. was dazu sagen, was der Unterschied ipt zu iptn ist und ob beim CV Container iptn "absichtlich" verwendet wurde.

lg
Robert

[StefanW]

Hallo Peer,

Ist es möglich, dass der eibd immer mit "iptn" gestartet wird, oder spricht etwas dagegen?

Nach meinen Informationen wird damit der Zugriff im NAT-Modus aktiviert, das ist für andere IP-Schnittstellen nicht immer die geeignete Variante, daher womöglich nicht die beste Idee das grundsätzlich so zu machen.

Wir haben zwar Ideen zur Umsetzung, aber das ist ziemlich aufwändig und da sind noch einige FRs vorher dran, die mehr Votes haben.

Leider gibt es keine einfache und universelle Lösung

lg

Stefan

[pbm]

@StefanW

hab gedacht, dass meine Vorschlag:

Statt dem fixen Parameter "ipt", soll eine Variable eingeführt werden, die im Konfig-Fenster der App editierbar ist:

Dafür ein Dropdown für die neue Variable $KNXMODUS = 'ip'; 'ipt'; 'iptn' im Parameter-Fenster einbauen.

In der /usr/bin/start_services.sh dann die Zeile ändern:

/usr/bin/eibd -u -i $KNXMODUS:$KNXHOST:$KNXPORT -d/var/log/eibd.log -e 0.0.0

eine ziemlich einfache und universelle Lösung sein könnte.


Versuche gerade mir selbst einen Workaround zu schaffen.

In /etc/wiregate/init.sh habe ich folgendes:

Code: Alles auswählen

#!/bin/bash
sed -i s/ipt:/iptn:/ /usr/bin/start_services.sh

Das ändert für meinen Anwendungsfall den Start-Paramter des eibd, beim re-deployment des Containers.

Da dies allerdings zur Laufzeit des Scripts /usr/bin/start_services.sh passiert,
wird noch der alte Befehl ausgeführt und es ist danach noch ein reboot notwendig, damit der eibd im richtigen Modus gestartet wird.

Hab es im init.sh über "shutdown -r 1" probiert, um eine Minute später den Container zu rebooten.
Funktioniert allerdings nicht...
Auch mit "systemctl reboot" geht das im Container nicht. Das muss wohl irgendwie anders gemacht werden... Wenn es innerhalb des Containers überhaupt geht?!

Wenn da noch jemand einen Ansatz hat, immer her damit!

(das läuft natürlich nur solange ElabNET nicht die Stelle im /usr/bin/start_services.sh ändert.
Aber ich geh mal davon aus, falls ElabNET an der Stelle was ändert, dann ist es, weil mein FR berücksichtigt wurde... )

[blaubaerli]

Hallo Peer,

wie gesagt, es gibt die Möglichkeit, den Container eigenständig in der Portainer-Umgebung zu installieren. Du nutzt dann halt nicht den Weg über die App. Dann hast du den Freiheitsgrad und kannst das Startkommando eigenständig bestimmen und hast das Thema damit Umgangen.

Hallo Stefan (@StefanW), der Gedanke mit der zusätzlichen Variable würde ja für alle anderen die das nicht brauchen auch nichts ändern, da man ja hier den Defaultwert so stehen lassen könnte, dass es jetzt genau das identische Verhalten ergibt, wie jetzt im statisch vorgegebenen Skript im Container. Aber Kleinvieh macht bekanntlich auch Mist .

Beste Grüße
Jens

[StefanW]

Hallo Stefan (@StefanW), der Gedanke mit der zusätzlichen Variable würde ja für alle anderen die das nicht brauchen auch nichts ändern, da man ja hier den Defaultwert so stehen lassen könnte, dass es jetzt genau das identische Verhalten ergibt, wie jetzt im statisch vorgegebenen Skript im Container. Aber Kleinvieh macht bekanntlich auch Mist

Wir haben das selbstverständlich besprochen mit der Variable. Das gesamte Entwicklerteam hat eine halbe Stunde darüber nachgedacht (was durchaus zusammen mehrere Mannstunden macht und auch ein paar hundert Euro gekostet hat).

Auch einfache (erscheinende) Leistungsmerkmale sind manchmal aufwändig zu realisieren, auch weil man jede solcher Lösungen dann auch 20 Jahre lang supporten, erklären, im Kopf behalten und dokumentieren muss. Das für einen FR der nicht einen einzigen Vote bekommen hat ist zuviel.

Ich bitte das zu akzeptieren. Es mag künftig mehr Ressourcen geben, so dass wir das noch einbauen können, aber hier und jetzt sehen wir andere Prioritäten.

lg

Stefan