knxd und OpenHAB

[Tatwaffe23mm]

So, habe jetzt 0.11.18 installiert, aber das gleiche Ergebnis.

 knxtool groupsocketlisten ip:localhost

macht keine Mucks und

knxtool groupswrite ip:localhost 1/0/80 1

macht das was es soll.

[misa]

Läuft der bus-monitor bei Dir?

knxtool vbusmonitor1 ip:

[Tatwaffe23mm]

Hallo misa, nein tut er gerade nicht.

pi@knxpi:~ $ knxtool vbusmonitor1 ip:localhost
Open failed: [B]Connection refused[/B]

Update: Es fehlte die -i Option. Ich weiß nur nicht, warum ich die jetzt auf einmal brauche. Vorher ging es ja auch ohne.

knxd -e 1.1.0 -E 1.1.245:4 -c -DTRS[B] -i [/B]-b tpuarts:/dev/knx1

[misa]

-i brauchst Du meines Wissens nach, wenn Du den knxd übe die CMD-Line startest.
Beim Start über systemd läuft das automatisch

[Tatwaffe23mm]

Hi misa, ich starte den knxd grundsätzich als service mit systemctl.

Laut Hilfe bringt das -i den Port 6720 zum hören. K.A., warum das jetzt notwendig war. Ich dachte immer alles läuft über Port 3671.

-i, --listen-tcp[=PORT] listen at TCP port PORT (default 6720)

Nun ja, der Busmonitor "funktioniert" jetzt zwar, aber er empfängt nach wie vor keine Telegramm, die auf dem Bus zirkulieren, nur wenn ich etwas per knxtool oder OH2 sende, bekomme ich auf dem Monitor Einträge.
Da ich den Pi aber dringend am Bus brauche, werde ich mir jetzt wohl oder übel ein Einbau-IP-Gateway kaufen, denn aktuell wird der knxd auch nicht mehr von der ETS erkannt, was mich immer mehr zu einem HW-Defekt tendieren lässt.

[Smurf]

Also mal langsam. Wenn die ETS deinen knxd nicht sieht, dann läuft er entweder nicht, oder du hast ein Multicastproblem. Letzteres geht nicht von selber weg wenn man den knxd durch Hardware ersetzt. Wenn du trotz Multicastproblem mit dem knxd reden willst (oder der in einem anderen Subnetz hängt), musst du der ETS die IP-Adresse des knxd-Rechners manuell eintragen.

Bitte prüfe die Frage, ob Telegramme zirkulieren, mit "knxtool vbusmonitor1 ip:". Wenn er dabei keine Daten liefert, obwohl du einen Schalter drückst, dann stimmt was mit deinem Businterface nicht. Neben Hardwareproblemen ist beim Pi immer noch, dass jemand vergessen hat, die auf dem seriellen Port lauschende Konsole und/oder das Bluetoothmodul des Pi3 komplett zu deaktivieren. Das kann auch mal funktionieren-und-dann-plötzlich-nicht-mehr.

Port 3671 (UDP) und Port 6720 (TCP) sind vollkommen unterschiedliche Dinge. Ersteren kann man nur mit Argumenten ansteuern, die wiederum davon abhängen, was du tun willst. Soll eine ETS mit dem knxd reden, brauchst du -DTRS (im Normalfall). Hast du nur "externe" Hardware, brauchst du "ip:" (Multicast) oder "ipt:" (Tunnel).

Soll knxtool oder sonst ein dediziert mit dem knxd-sprechendes Programm verwendet werden, das sich mit Port 6720 verbinden will, brauchst du "-i". Mit systemd ist das "-i" unnötig, wenn der knxd vom systemd gestartet wird, tut aber auch nicht weh.

Und: "ETS geht nicht" ist mit Sicherheit kein Hardwaredefekt – es sei denn, der knxd hat sich beendet, weil er deinen TPUART oder sonst ein Interface nicht erreichen konnte. Ob das der Fall ist, steht im Log. "sudo journald -uknxd -n30" ist dein Freund.

[Tatwaffe23mm]

Hallo Smurf,

Ich gehe mal kurz alle Punkte durch:

• Läuft der knxd
  • ja, der knxd läuft
• Hängt der Pi im selben Netz?
  • ja
• Werden Multicast-Pakete geroutet?
  • Bis vor enigen Tagen auf jeden Fall, da der Discovery-Mode funktionierte. Aktuell weiß ich es nicht mit Gewissheit. An der Netzwerkkonfiguration habe ich nicht herumgespielt. Muss ich erst googeln, wie das geht.
• Zeigt der Busmonitor einen Tastendruck an
  • Nein, der Busmonitor zeigt nichts an
• Bluetooth PI3
  • Ist ein Raspberry Pi, Model B+
• Läuft eine serielle Konsole auf AMA0?

  • pi@knxpi:~ $ sudo systemctl status serial-getty@ttyAMA0.service
    		● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
    		  Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: enabled)
    		  Active: inactive (dead)
    		    Docs: man:agetty(8)
    		          man:systemd-getty-generator(8)
    		          http://0pointer.de/blog/projects/serial-console.html

  • Das würde ich als Nein deuten.

Ich denke, dann bleibt es wohl bei 4. HW-Defekt. Vorher werde ich aber noch das Multicast-Routing prüfen. Danke für Deine Hinweise, besonders die letzten beidn Absätze waren recht erhellend für mich.


Nachtrag:

Warum zeigt sudo netstat -tulpn | grep knxd

pi@knxpi:~ $ sudo netstat -tulpn | grep knxd
tcp        0      0 0.0.0.0:6720            0.0.0.0:*               LISTEN      2791/knxd
udp        0      0 0.0.0.0:47327           0.0.0.0:*                           2791/knxd
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           2791/knxd

drei offene Ports an?

[Tatwaffe23mm]

...
Und: "ETS geht nicht" ist mit Sicherheit kein Hardwaredefekt – es sei denn, der knxd hat sich beendet, weil er deinen TPUART oder sonst ein Interface nicht erreichen konnte. Ob das der Fall ist, steht im Log. "sudo journald -uknxd -n30" ist dein Freund.

In den Logs konnte ich keine Hinweise auf einen nicht erreichbaren TPUART order beendeten knxd finden, insofern Danke für den Wink.

Ich würde mich mit der Diagnose "Multicast-Routing-Problem" ja nicht so schwer tun, wenn ich wüsste, dass ich etwas an den Netzwerkeinstellungen des Pi geändert hätte. Habe ich aber nicht.

Hast Du vielleicht noch einen Hinweis, wie ich sehen kann, ob das Multicast-Routing überhaupt funktioniert?

[Tatwaffe23mm]

Kann es sein, dass das Loopback-Device auch in die Multicast Gruppe eingetragen werden muss?

Bei mir gibt netstat -ng folgendes aus:

pi@knxpi:~ $ netstat -ng
IPv6/IPv4-Gruppenmitgliedschaften
Schnittstelle   RefZäh Grupp
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      239.255.255.250
[B]eth0            2      224.0.23.12[/B]
eth0            1      224.0.0.252
eth0            2      224.0.0.251
eth0            1      224.0.0.1
lo              1      ff02::1
lo              1      ff01::1
eth0            1      ff02::1:3
eth0            2      ff02::fb
eth0            2      ff02::1:ffcf:4579
eth0            2      ff02::1
eth0            1      ff01::1

[Tatwaffe23mm]

Ich habe jetzt was gefunden, wie ich den Multicast-Empfang zumindest rudimentär prüfen kann:

Ich habe von meinem Ubuntu Rechner aus mit iperf -c 224.0.23.12 -p 3671 -u UDP Pakete vom Port 3671 aus auf die MCAST-Adresse gesendet.

Am Pi habe ich dann noch den knxd abgeschaltet, einen (anderen) Multicast-Server mit iperf aufgesetzt und ebenfalls auf Port 3671 gelauscht.

 iperf -s -u -B 224.0.23.12 -p 3671 -i 1 -e
------------------------------------------------------------
Server listening on UDP port 3671 with pid 21250
Binding to local address 224.0.23.12
Joining multicast group  224.0.23.12
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 224.0.23.12 port 3671 connected with 192.168.178.31 port 34411
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total  Latency avg/min/max/stdev PPS
[  3] 0.00-1.00 sec   129 KBytes  1.06 Mbits/sec   0.977 ms    0/   90 (0%) 15.611/14.777/27.954/ 2.566 ms   90 pps
[  3] 1.00-2.00 sec   128 KBytes  1.05 Mbits/sec   0.701 ms    0/   89 (0%) 15.578/14.785/22.542/ 1.380 ms   89 pps
.
.
.
[  3] 9.00-10.00 sec   128 KBytes  1.05 Mbits/sec   1.256 ms    0/   89 (0%) 15.507/14.673/21.682/ 1.422 ms   89 pps
[  3] 0.00-10.01 sec  1.25 MBytes  1.05 Mbits/sec   1.256 ms    0/  893 (0%) 15.543/14.673/39.421/ 2.210 ms   89 pps

Es kommen dort Multicast-Pakete an. Die Netzwerkkarte ist also korrekt konfiguriert.


Mein Problem scheint zu sein, dass irgendein Prozess den Zugriff des knxd auf ?den TPUART?, blockiert. Wie kann ich rausbekommen, wer oder was da alles mitmischt?

Denn

pi@knxpi:~ $ knxtool vbusmonitor1 ip:localhost
Open failed: Connection refused

bringt noch immer diesen Fehler. Witzigerweise kann ich von meinem Ubuntu-Rechner aus die Lampen per knxtool schalten. Von meinem Pi aus nicht.


NACHTRAG:
Auf der Suche nach dem Fehler habe ich mit netstat noch einmal die Ports überprüft.

pi@knxpi:~ $ sudo netstat -uanp | grep knxd
udp        0      0 0.0.0.0:51791           0.0.0.0:*                           22445/knxd
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           22445/knxd

Wieso stehen da zwei Prozesse?

[Tatwaffe23mm]

So, die connection refused Meldung habe ich jetzt wegbekommen. Und zwar mit:

sudo systemctl [B]mask [/B]serial-getty@tty[B]ACM0[/B].service

Da lief dich noch irgendwas drauf, obwohl der Status disabled war.



Smurf, was sagt mir diese Fehlermeldung?

Jan 19 21:11:33 knxpi knxd[1731]: Layer 1 [4:mcast             56.277] Send(070): 08 01 C0 A8 B2 03 93 43 36 01 02 00 11 00 00 00 01 02 03 04 05 06 E0 00 17 0C B8 27 EB CF 45 79 6B 6E 78 64 00 00 00 00 00 00 0
Jan 19 21:11:37 knxpi knxd[1731]: Layer 2 [5:tpuarts:/dev/knx1 60.118] Watchdog Status(001): 02
Jan 19 21:11:37 knxpi knxd[1731]: Layer 1 [4:mcast             60.281] Recv(016): 08 01 C0 A8 B2 13 C4 87 08 04 01 02 08 06 07 00
Jan 19 21:11:37 knxpi knxd[1731]: Layer 8 [4:mcast             60.282] [B]Unexpected service type: 020b[/B]
Jan 19 21:11:37 knxpi knxd[1731]: Layer 1 [4:mcast             60.283] Recv(008): 08 01 C0 A8 B2 13 C4 87

knxtool vbusmonitor1 ip: zeigt mir allerdings noch immer nicht die auf dem Bus zirkulierenden Telegramme an, sondern nur die, die ich vom Pi oder einem anderen Rechner aus über das Netzwerk sende.

[Tatwaffe23mm]

So, um das hier abzuschließen: Der TUL - TPUART Stick war defekt. Ich habe jetzt einen anderen getestet und es läuft wieder alles so, wie es soll.

[misa]

Tip top und Gratulation. Ist aber auch eher selten.