knxd.conf Einstellung für ABB IPs2.1 Schnittstelle möchte nicht kommunizieren

[AFeldt]

Guten Tag zusammen,

nachdem ich mit einigen Stolpersteinen einen VM HyperV mit Debian Buster und SmartHomeNG jetzt soweit lauffähig hinbekommen habe, möchte die Kommunikation mit meiner KNX Umgebung nicht funktionieren.

Meine LAN-Schnittstelle ist die ABB IPS2.1 mit neuster Firmware.
Phy.Addr. 1.1.250
LAN-IP: 192.168.10.235
SubNet: 255.255.255.0
GW: 192.168.10.254


in der knxd.conf ist folgender Parameter
KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.10.235"

Mit "sudo systemctl status knxd.service" kann man den Status sehr gut erkennen und es werden keine Fehler gemeldet.
Auch die knxd.sockets funktionieren einwandfrei

Allerdings werden mit "knxtool groupsocketlisten ip:localhost" keine Aktivitäten auf dem KNX-Bus (wenn ein Schaltaktor etc. Befehle im KNX-Bus umsetzt), angezeigt.
Wenn ich über die SmartVISU HTML Oberfläche aber Schaltflächen ändere, wird auf der Console der Befehl:
Write from 0.0.2 to 1/5/4: 00 angezeigt, aber nicht im KNX umgesetzt, aber es passiert nichts.

Auch mit "knxtool groupswrite ip:localiost 1/5/4 1" (soll Küchenlicht schalten) etc. passiert nichts.

Hat jemand eine Idee?

Gruß aus dem Rheinland

[Tru]

Hat jemand eine Idee?

Ich habe deine Aktivitäten in den anderen Threads gesehen und hätte dir gerne geholfen, wenn ich mit der ABB Schnittstelle vertraut wäre und selber knxd innerhalb einer VM beherrschen würde. Ich kann dir immerhin bestätigen, dass deine Parameter für den knxd grundsätzlich mal in Ordnung sind. Du könntest allerdings das Logging Level erhöhen mit -B log vor dem -b Parameter.

Ich kann dir immerhin Ideen für die Analyse geben.

Zur Schnittstelle, von der ich überhaupt nichts weiss, etwas zum Abklären:

verlangt die Schnittstelle, dass ein Tunnelclient (also der knxd) eine von der Schnittstelle zugewiesene physikalische Adresse verwendet oder dürfen die physikalischen Adressen frei verwendet werden? Im ersten Fall müsste der knxd nach meinem Verständnis mit der zugewiesenen Adresse konfiguriert werden und mit "-B single" ausschliesslich diese Adresse für die Tunnelkommunikation verwenden, inklusive für die Clients welche über den knxd angeschlossen werden. Im zweiten Fall hingegen muss lediglich darauf geschaut werden, dass die Adressen von -e und -E alle sonst unbenutzt sind. Der knxd wird sie dann dynamisch seinen Clients zuordnen und auf dem Bus ist dann jeder knxd-Teilnehmer individuell identifizierbar.

lässt dein VM-Host alle IP-Pakete in beide Richtungen für alle Ports sauber durch? Das Wesen des knx-Tunnels ist, dass es sich um ein Peer-To-Peer Kommunikation handelt, wo beide Seiten Pakete schicken, welche auf der anderen Seite natürlich unverändert ankommen müssen.

Zur Analyse würde ich einen Netzwerksniffer anwerfen und schauen was an der ABB-Schnittstelle einerseits und innerhalb der VM am knxd andererseits an Tunnelverkehr auftritt. Du müsstest dann Verkehr für die UPD Ports 3671 und 3672 in beide Richtungen sehen.

Falls jemand besser Bescheid weiss mag er mich gerne korrigieren. Ich nutze eine Schnittstelle ohne Einschränkung der verwendeten physikalischen Adressen (aber nur für einen einzigen Tunnel) und setze keine Virtualisierung ein.

[henfri]

Hallo,


Das Verhalten, welches du beschreibst spricht dafür, dass die Kommunikation vom der IP-SS zum KNXD nicht funktioniert. Daher siehst du dass etwas von der SmartVisu am KNXd ankommt, aber weiter geht es dann nicht.
Wenn du mit groupswrite das Küchenlicht schaltest, sollte die Smartvisu ebenfalls reagieren.

Davon ab, würde ich vorschlagen:
-sicherstellen dass beim Start des knxd die ETS nicht läuft und dadurch die SS blockiert.
-ping aus der VM auf die 192.168.10.235
-ETS starten. Dort als Interface den KNXd nehmen. Sind die Schaltbefehle aus SV oder groupswrite in der ETS sichtbar?
-es erstmal ohne VM testen

Gruß
Hendrik

[wvhn]

Zur Dokumentation hier die von AFeldt im SmarthomeNG-Forum geteilte Lösung:

Ich hatte ja erhebliche Probleme mit meiner SmarthomeNG überhaupt auf den KNX-Bus zu kommen und Befehle abzusetzen.
Durch den Einsatz eines Gira-IP-Routers 216700 und der richtigen knxd.conf Einstellung waren die Probleme behoben !!

Wir haben dem IP-Router die 192.168.10.250 in LAN und einen KNX-Gruppenadressenbereich von 1.1.59 - 1.1.63 vergeben.

Die knxd.conf lautet jetzt:

# für den Gira IP-Router
KNXD_OPTS="-e 1.1.60 -E 1.1.61:2 -D -T -S -b ipt:192.168.10.250"


mit dieser Konstellation hat es auf Anhieb funktioniert.