knxd 0.1.0 im CometVisu-Docker-Container

[daywalker1180]

Hallo Leute,

ich habe auf einem RPi3 das CometVisu-Docker Image runtergeladen.

Mein Plan wäre gewesen für mein Wiregate 1, welches immer noch (>10 J.!) brav täglich seinen Dienst verrichtet, ein Backup-System zu schaffen falls es mit der Hardware einmal ein Problem gibt.
Zur Anbindung habe ich mir einen TPUART USB-Adapter gekauft (TUL Stick von Busware, https://shop.busware.de/product_info...products_id/59).
Auf meinem betagten Wiregate läuft noch der eibd, Anbindung ebenfalls über einen solchen Stick.

Allerdings kann ich im Docker-Container die gleiche Parametrierung des Wiregate für den knxd 0.1.0 nicht verwenden, da werden einige
Parameter nicht akzeptiert, aber vor allem die URL

tpuarts:/dev/tul

bzw. wie man ihn dann halt immer über die udev Regeln getauft hat, gefällt diesem knxd-0.1.0 gar nicht.

Da beim Aufruf von knxd --help steht:

Usage: knxd [OPTION...] URL
knxd -- a commonication stack for EIB/KNX
(C) 2005-2011 Martin Koegler <mkoegler@auto.tuwien.ac.at>
supported URLs are:
ip:[multicast_addr[port]]
ipt:router-ip[:dest-port[:src-port[:nat-ip[:data-port]]]]]
iptn:router-ip[:dest-port[:src-port]]

und dann nix mehr, heißt das für mich dass es da keinen tpuarts gibt.

Ist im Docker-Container eine kastrierte knxd-0.1.0-Version drinnen, die ohne die Unterstützung von tpuarts kompiliert wurde?
Wie könnte ich diese Unterstützung da reinkriegen?
(Am Kompilieren des knxd habe ich mich schon mal versucht und bin daran gescheitert, dafür reichen mein C Kenntnisse und die der Toolchain fix nicht aus).

Vielen Dank für eine Info
LG
Martin

[makki]

Ja, da fehlt der tpuarts-Support im Kompilat des eibd/knxd (was aber einfach ist, keine grossen Dependencies wie USB etc..) das tpuarts bzw. TUL ist einfach nur ein "CDC ACM", kann jeder Kernel "out of the box". HTH

P.S.: ein RasPI Spielzeug als Backup für ein WireGate zehrt aber doch etwas ein meinem Stolz

Grüsse Makki

[henfri]

Hallo,

Ist im Docker-Container eine kastrierte knxd-0.1.0-Version drinnen, die ohne die Unterstützung von tpuarts kompiliert wurde?
Wie könnte ich diese Unterstützung da reinkriegen?
(Am Kompilieren des knxd habe ich mich schon mal versucht und bin daran gescheitert, dafür reichen mein C Kenntnisse und die der Toolchain fix nicht aus).

Du könntest das Dockerfile (link) des cometvisu-containers nehmen und dort einfach das, was du beim KNXd brauchst anpassen. Danach baust du mit docker build -t my_cv ./ und docker kompiliert für Dich.

Edit: Ich sehe gerade, dass der Container auch nix anderes macht als

 [TABLE]
 	 		[TR]
 			[TD]git clone https://github.com/knxd/knxd.git && cd knxd && git checkout ${BUILD_BRANCH} \[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]&& dpkg-buildpackage -b -uc[/TD]
 		[/TR]
 	 [/TABLE]

Ich weiß nicht, wie man dem dpkg-buildpackage beibringt den TPUART Support mit einzukompilieren.

Alternativ probierst du mal meinen knxd-container aus. Aber ohne Gewähr. Ich weiß nicht, ob der das kann. Aber du findest es ja schnell raus.

Gruß,
Hendrik

[Chris M.]

Einen knxd-0.1.0 kenne ich nicht, ist aber hier egal. Der Docker Container verwendet die Version 0.0.5.1.
Kompiliert wird das ganze mit diesen Parametern: https://github.com/CometVisu/Docker/...erfile#L39-L42

Wie Du dort siehst ist da nur die Netzwerk-Verbindung eingebaut, also IP Tunnel und IP Routing.

Hintergrund ist, dass gerade aus einem Container heraus Netzwerk die quasi natürliche Schnittstelle ist, so wie KNX USB Schnittstellen regelmäßig Ärger machen und ein Einkompilieren den Container dicker machen, obwohl das fast niemand braucht.

Die Lösung wäre also entweder die Schnittstelle auf ein KNX IP Tunnel oder KNX IP Router zu wechseln.
Oder auf dem RPi einen selbst kompilierten knxd laufen zu lassen, der die USB Verbindung übernimmt und die KNX IP Tunnel Verbindung dem Container bereit stellt.

[makki]

Wenn man da in Zeile 39 dem configure nun ein --enable-tpuarts statt --disable-tpuarts gibt ist alles gut (sofern man aus dem Docker auf den seriellen Port vom CDC ACM kommt, keine Ahnung..)

[henfri]

Genau das suchte ich...
welches dockerfile hab ich denn da erwischt?
Den seriellen Port kannst du wie jedes Verzeichnis in den Container rein mounten.

[daywalker1180]

Vielen Dank Leute für die vielen Hinweise und Anregungen!

Ich bin im Endeffekt den Weg gegangen den Chris vorgeschlagen hat:

Die Lösung wäre also entweder die Schnittstelle auf ein KNX IP Tunnel oder KNX IP Router zu wechseln.
Oder auf dem RPi einen selbst kompilierten knxd laufen zu lassen, der die USB Verbindung übernimmt und die KNX IP Tunnel Verbindung dem Container bereit stellt.

Hab auf einem RPi den aktuellen knxd aus den Paketquellen installiert, den TUL Stick dort als Anbindung hergenommen und mittels Environment-Variable

KNX_INTERFACE=iptn:192.168.1.xxx

verbunden. Aufgefallen ist mir, dass man beim iptn: keinen Port angeben darf (also zB iptn:192.168.1.xxx:3671) dann schlägt der Tunnelaufbau fehl (der KNXD antwortet mit ICMP 96 Destination Port noch reachable).
Das funktioniert derweil mal, ist aber eher eine PoC Phase als ich es gleich für einen Echtbetrieb heranziehen würde.
Den neuen KNXD mit der CometVisu direkt zusammenzuhängen funktioniert ja nach meinem letzten Versuch (ca. ein Jahr her) nicht, weiß nicht ob sich das seither geändert hat (denke aber nicht).

P.S.: ein RasPI Spielzeug als Backup für ein WireGate zehrt aber doch etwas ein meinem Stolz

Ja Makki da hast Du natürlich recht, aber irgendwo muß man ja mal anfangen ... ob das wirklich das Ersatzsystem wird weiß ich eh noch nicht.

Einen knxd-0.1.0 kenne ich nicht, ist aber hier egal. Der Docker Container verwendet die Version 0.0.5.1.

Chris, der knxd behauptet das von sich selbst, wenn man ihn im Container fragt... deshalb bin ich auf diese ominöse 0.1.0 gekommen
container-knxd.png

Nochmal Danke Euch allen!