KNXD im Docker und MDT IP router SCN-IP100.02

[Frank6320]

Hi,
ich starte ein Dockerimage basierend auf dem von Henfri.
localhost und 127.0.0.1 habe ich vorher probiert bei groupswrite mit gleichem Ergebnis.
Den Router konnte ich aus dem Docker heraus anpingen.
viele Grüße
Frank

[Smurf]

Ah. Hast du dem Docker gesagt, er soll UDP-Pakete auf Port 6720 durchlassen/weiterschicken/was-auch-immer?
Wahrscheinlich nicht.

Ich finde Docker ehrlich gesagt ziemlich sinnfreie Ressourcenverschwendung, erstens auf dem Rechner an sich – und zweitens, weil gefühlt *jeder*, der ihn verwenden will, erstmal ein Problem damit hat … und Leute fragt, die sich zwar mit der verpackten App, aber mit Docker selber nicht die Bohne auskennen. Oder umgekehrt, aber wenigstens davon bekomme ich nix mit …

[Frank6320]

Hi,
es dauert nicht mehr lange und ich muss ins Irrenhaus wegen dem Docker Scheiß. Hab noch ne Baustelle zwischen fhem und mariadb im docker mal sehen wann das läuft. Irre was ich deswegen an Zeit verschwende...
Zurück zu knxd in docker
Das Dockerfile lautet:

FROM debian:jessie
MAINTAINER Hendrik Friedel hendrik@friedels.name
RUN apt-get -y update
RUN apt-get -y install git-core build-essential debhelper autotools-dev autoconf automake libtool \
libusb-1.0-0-dev pkg-config base-files base-files libev-dev \
init-system-helpers dh-systemd libsystemd-dev libsystemd-daemon-dev

# now build+install knxd

RUN git clone https://github.com/knxd/knxd.git && cd knxd && git checkout tags/v0.12.6 && \
dpkg-buildpackage -b -uc && cd .. && dpkg -i knxd_*.deb knxd-tools_*.deb


#EXPOSE 4720 6720 3671/udp
##### NOTE AND README ######
#start this container with --net=host instead of binding ports

CMD [knxd -e 1.1.200 -E 1.1.201:4 -u /tmp/eib -t 1023 -DTRS -b ipt:192.168.178.23]

Den Start per:

 henfri:
build: ./henfri
restart: always
network_mode: "host"
ports:
- 4720:4720
- 6720:6720
- 3671:3671/udp
# networks:
# - host
command: knxd -e 1.1.200 -E 1.1.201:4 -u /tmp/eib -t 1023 -b ipt:192.168.178.23

:


Ich sehe jetzt Dinge auf dem Bus:

knxd: Layer 8 [ 4:ipt:192.168.178.23 223.443] unknown addr 1.1.1
knxd: Layer 0 [ 4:ipt:192.168.178.23 223.443] Send(010): 06 10 04 21 00 0A 04 72 11 00
knxd: Layer 1 [ 4:ipt:192.168.178.23 240.109] Heartbeat
knxd: Layer 1 [ 4:ipt:192.168.178.23 240.109] Send(010): 72 00 08 01 C0 A8 B2 5A 0E 58
knxd: Layer 0 [ 4:ipt:192.168.178.23 240.109] Send(016): 06 10 02 07 00 10 72 00 08 01 C0 A8 B2 5A 0E 58
knxd: Layer 0 [ 4:ipt:192.168.178.23 240.110] Recv(008): 06 10 02 08 00 08 72 00
knxd: Layer 1 [ 4:ipt:192.168.178.23 270.139] Heartbeat
knxd: Layer 1 [ 4:ipt:192.168.178.23 270.140] Send(010): 72 00 08 01 C0 A8 B2 5A 0E 58
knxd: Layer 0 [ 4:ipt:192.168.178.23 270.140] Send(016): 06 10 02 07 00 10 72 00 08 01 C0 A8 B2 5A 0E 58
knxd: Layer 0 [ 4:ipt:192.168.178.23 270.140] Recv(008): 06 10 02 08 00 08 72 00
knxd: Layer 0 [ 4:ipt:192.168.178.23 283.438] Recv(023): 06 10 04 20 00 17 04 72 12 00 29 00 BC E0 11 01 00 01 03 00 80 24 8A
knxd: Layer 1 [ 4:ipt:192.168.178.23 283.438] Send(004): 04 72 12 00
knxd: Layer 1 [ 4:ipt:192.168.178.23 283.438] Recv L_Data low from 1.1.1 to 0/0/1 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 24 8A
knxd: Layer 9 [ 4:ipt:192.168.178.23 283.438] Enqueue L_Data low from 1.1.1 to 0/0/1 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 24 8A
knxd: Layer 8 [ 4:ipt:192.168.178.23 283.438] unknown addr 1.1.1
knxd: Layer 0 [ 4:ipt:192.168.178.23 283.438] Send(010): 06 10 04 21 00 0A 04 72 12 00
knxd: Layer 0 [ 4:ipt:192.168.178.23 284.438] Recv(023): 06 10 04 20 00 17 04 72 13 00 29 00 BC E0 11 01 00 02 03 00 80 5D BD
knxd: Layer 1 [ 4:ipt:192.168.178.23 284.438] Send(004): 04 72 13 00
knxd: Layer 1 [ 4:ipt:192.168.178.23 284.438] Recv L_Data low from 1.1.1 to 0/0/2 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 5D BD
knxd: Layer 9 [ 4:ipt:192.168.178.23 284.438] Enqueue L_Data low from 1.1.1 to 0/0/2 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 5D BD
knxd: Layer 8 [ 4:ipt:192.168.178.23 284.438] unknown addr 1.1.1
knxd: Layer 0 [ 4:ipt:192.168.178.23 284.438] Send(010): 06 10 04 21 00 0A 04 72 13 00

Groupswrite schlägt aber weiterhin fehl.

Open failed: Connection refused

[henfri]

Hallo,

Wenn ich dei image starte mit dem Kommando:

knxd -e 1.1.200 -E 1.1.201:4 -u /tmp/eib -t 1023 -b ipt:192.168.178.23

Woher hast du das?

Ich starte mit:

docker-compose.yaml
version: "2"
services:
    knxd:
      image: henfri/knxd:v0.12.6
      network_mode: "host"
      command: knxd -e 1.0.200 -E 1.0.201:8 -DTRS -c -i --send-delay=120 -B single -b ipt:192.168.177.8
      restart: always

Wenn du davon etwas änderst, bitte nenn den Grund.

Dann im Container:

#knxtool groupswrite ip:localhost 1/1/180 1
Send request
#knxtool groupswrite ip:localhost 1/1/180 0
Send request

QUOTE=Smurf ;n1558752]Ah. Hast du dem Docker gesagt, er soll UDP-Pakete auf Port 6720 durchlassen/weiterschicken/was-auch-immer?
Wahrscheinlich nicht.[/quote]
Ja, dafür ist net=host nötig (zumindest habe ich keine Alternative gefunden).

Ich finde Docker ehrlich gesagt ziemlich sinnfreie Ressourcenverschwendung, erstens auf dem Rechner an sich – und zweitens, weil gefühlt *jeder*, der ihn verwenden will, erstmal ein Problem damit hat … und Leute fragt, die sich zwar mit der verpackten App, aber mit Docker selber nicht die Bohne auskennen. Oder umgekehrt, aber wenigstens davon bekomme ich nix mit …

Wenn es eine statisch gelinkte knxd gäbe, die man einfach herunterladen könnte, dann bräuchte man in meinen Augen Docker auch nicht.
Aber zumindest vor einiger Zeit war das Kompilieren (damals noch vom eibd) eine Katastrophe.

Ich bin OSS fan. Aber auf Autos (Autovergleiche sind ja immer gut) angewandt würde das bedeuten, dass es Open-Source Autos gibt, bei denen Tante Hilde dann erstmal die Zylinder selbst in den Motorblock packen müsste. Mit dem dafür nötigen Spezialwerkzeug (compiler bei Software) muss sie sich auch erstmal vertraut machen.

Nachdem ihr das gelungen ist, sieht sie, dass der Motor der Version 1.7.2.1 nicht mit dem Getriebe der Version 1.2.3 kompatibel ist. Sie kauft also ein Getriebe in der Version 1.2.4. Aber damit ist der Schaltknauf nicht kompatibel. Also muss sie den Schaltknauf auch updaten. Dafür muss sie sich aber wieder mit einem Spezialwerkeug vertraut machen.

OSS ist gut. Aber es wäre besser wenn man nicht alles selbst kompilieren müsste.
Die Kritik mag nicht (mehr) auf den knxd, v.a. unter Debian zutreffen.

 henfri:
build: ./henfri
restart: always
networks:
- fhem-network
command: knxd -e 1.1.200 -E 1.1.201:4 -u /tmp/eib -t 1023 -b ipt:192.168.178.23

Warum build? Warum willst du das Docker image selbst bauen?
Siehe oben, dann nimmst du das vom Docker hub - geht auch schneller.

Ich hab das doch hier ausführlich beschrieben.
Hier machst du was anderes, als ich dir geschrieben hab.
Du kannst gerne was anderes machen. Wenn du weißt was du tust. Bis dahin, geh doch einfach den eingetretenen Pfad.

funktioniert das ganze nur bei Vollmond und dann doch wieder nicht in docker?
es dauert nicht mehr lange und ich muss ins Irrenhaus wegen dem Docker Scheiß. Hab noch ne Baustelle zwischen fhem und mariadb im docker mal sehen wann das läuft. Irre was ich deswegen an Zeit verschwende...

Du musst kein Docker verwenden. Siehe hier.

Was mache ich falsch?

Siehe oben.

Groupswrite schlägt aber weiterhin fehl.

Sorry, aber:
1) keine Fehlermeldung
2) Kommando nicht angegeben

Warte kurz.

Diagnose:
Dann machst du noch was falsch.

Genauer wird die Glaskugel mit 1&2.

Viele Grüße,
Hendrik

[Frank6320]

Hallo Henfri

danke für deine Hinweise. Ich erwarte eigentlich den eingetretenen Pfad zu nehmen wenn ich knxd Befehle verwende, die vorher bei knxd ohne Docker funktioniert haben. Daher habe ich nicht deine Befehle benutzt.

Ich habe jetzt auf dein image umgestellt. Das Kommando im stack lautet

 command: knxd -e 1.1.200 -E 1.1.201:4 -DTRS -c -i --send-delay=120 -B single -b ipt:192.168.178.23

ich kann jetzt Kommandos auf den Bus geben und Lampen schalten.

Aber es scheint mir den bus zu zerschießen. Kann keine Rollo mehr bewgen, da Kommados scheinbar verfielfältigt werden. Auf dem busmmonitor sind alle Befehle jetzt in 4facher Ausfertigung zu finden. Siehe Bild im Anhang.

Ich glaube es liegt weinger am image als an der richtigen Konfig des knxd wenn er in einem Docker ist

viele Grüße

Frank

[Smurf]

-DTRS -c -i --send-delay=120 -B single -b ipt:192.168.178.23

Standardproblem. Schleife im Bus. Sowohl dein Adapter als auch dein knxd lauschen auf Multicast *und* reden direkt miteinander.

Das hat noch nie funktioniert. Mach eines dieser Features aus, d.h. entweder deinem Adapter das Multicasten verbieten, oder dem knxd, oder das "-B single -b ipt:X.X.X.X" entfernen. Ich an deiner Stelle würde Ersteres tun.

Dass dieses Problem deine Rollosteuerung zerschießt, ist im Übrigen so auch nicht vorgesehen. KNX-Befehle sollen idempotent sein, es hat egal zu sein ob sie einmal oder viermal ankommen. Da musst du mit dem Empfänger dieser Pakete mal ein ernstes Wort reden.

[Frank6320]

Hi,

ich bin jetzt bei

knxd -e 1.1.200 -E 1.1.201:4 -t 1023 -DTRS -u /tmp/eibd

Der bus ist wieder nüchtern. Ich kann schalten und sehe auch nichts mehr doppelt. Wunderbar.

Die Rollos gingen nicht in dem Sinn, dass sie nur kurz geruckt haben. Die GA für den Start kann auch stoppen.

Jetzt stelle ich fest, dass FHEM den knxd nicht ansprechen kann. Beide container sind in --net=host. Alle ports sind also offen. Weder -i noch -u geht. Obwohl der TUL auf initialized steht.
Es bleibt spannend.

[henfri]

-u /tmp/eibd

Warum?

Jetzt stelle ich fest, dass FHEM den knxd nicht ansprechen kann. Beide container sind in --net=host. Alle ports sind also offen. Weder -i noch -u geht. Obwohl der TUL auf initialized steht.
Es bleibt spannend.

[Smurf]

"-u" landet irgendwo im lokalen Dateisystem. Der Docker hat aber sein eigenes. "-i" ohne Parameter ist auch Localhost, das lässt der Docker durch oder auch nicht, nimm die IP-Adresse des Rechners stattdessen. (Dito für knxtool und FHEM und so.) Vielleicht geht das. Oder auch nicht. (Ja, man kann das Ganze auch so konfigurieren, dass zwar beide ins Netz können, aber lokaler Traffic *nicht* möglich ist …)

Das sind alles, mit Verlaub, Kindergartenproblem in dem Sinne, dass die Leute mit diesen Problemen nicht wissen, wie Docker überhaupt funktioniert und wieso nicht. Alles gut, man muss nicht alles wissen – aber die Leute die Docker empfehlen sollten sich halt im Klaren sein dass das Zeug auch seine Tücken hat und es eben *nicht* zwangsläufig einfacher ist, sich ein Docker-Image mit knxd drauf runterzupfeifen und alles funktioniert, statt ihn selber zu bauen – falls die Distro ihn nicht eh bereits hat.

Ist ihnen aber anscheinend nicht.

[Frank6320]

Hi,

ok werde -i und -u noch mal ein wenig variieren.
Ja hatte nicht erwartet mir so viel Theater einzuhandeln. Hatte zwischendurch alles in proxmox. Da ist es stärker getrennt, so als wären es verschiedene Systeme. Das lief auf anhieb.
viele Grüße
Frank

[henfri]

Hallo,

aber die Leute die Docker empfehlen sollten sich halt im Klaren sein dass das Zeug auch seine Tücken hat und es eben *nicht* zwangsläufig einfacher ist, sich ein Docker-Image mit knxd drauf runterzupfeifen und alles funktioniert, statt ihn selber zu bauen – falls die Distro ihn nicht eh bereits hat.

Ist ihnen aber anscheinend nicht.

Ja, da hast du Recht. Man muss sich schon mit Docker befassen - allerdings muss man das Prinzip nur einmal verstehen, im Gegensatz zu den Compiler/Lib/Abhänigkeitsproblemen.
Ist vielleicht auch Geschmackssache.

Und was eben auch nicht ausbleibt: Man muss sich mit der Anwendung auseinandersetzen und wissen, was i und u machen.

ok werde -i und -u noch mal ein wenig variieren.

Was soll es bringen -i -u zu variieren?

Ja hatte nicht erwartet mir so viel Theater einzuhandeln. Hatte zwischendurch alles in proxmox. Da ist es stärker getrennt, so als wären es verschiedene Systeme. Das lief auf anhieb.

Hatte aber andere Nachteile, sonst würdest du ja nix ändern, oder?

Gruß,
Hendrik

[Frank6320]

Hi,

tja einfach mal probieren. auf /tmp/knx verweisen statt eib. Hat aber nicht geholfen. Wenn ich die Antwort hätte bräuchte ich es nicht. Mir leuchtet nicht ein wieso eine Kommunikation zu einer anderen ip oder innerhalb eines Systems funktionert, aber mit docker so ein Bohei entsteht.

[Smurf]

Docker hat für temporäre Verzeichnisse im Zweifelsfall ein eigenes Dateisystem. Das betrifft sowohm /tmp als auch /run. Wie oben bereits geschrieben …

[Frank6320]

Hi,

das ist ein gute Idee. Ich kann das Verzeichnis mal mounten zu beiden Containern. Mal schauen was passiert.
Gestern habe ioch noch einen eleganten Weg gefunden, damit FHEM mit dem KNX bus redet: Es gibt in FHEM schon direkt einen KNXTUL der ohne den knxd auskommt. Funktioniert super. Werde den dann wahrscheinlich benutzen, da dann kein extra Container notwendig wird.

[Frank6320]

Hi,

da Henfris Glaskugel die Lösung nicht aussupcken will, lüfte ich mal das Geheimnis wieso es bei mir Probleme gibt mit dem knxd.

Ich hatte nicht net=host verwendet. Ich hatte eine bridge verwendet, bei denen es dann Probleme mit dem udp ins äußere Netz gibt. Das ww ist scheinbar voll mit diesem Sachverhalt.

viele Grüße
Frank