KNX IP Interface MDT SCN-IP000.02

[rdorsch]

Hallo,

ich habe vor geraumer Zeit knxd mit dem MDT KNX IP Interface MDT SCN-IP000.02 in Betrieb genommen, derzeit läuft knxd 0.14.23. Dafür, dass ich wegen dringenderen anderen Arbeiten die Config im Wesentlichen ohne viel Sinn und Verstand aus dem Forum kopiert habe, funktioniert knxd verdammt zuverlässig. Einziges Problemchen derzeit: wenn ich ein neues Gerät an den KNX Bus hänge, muss ich knxd vor dem Programmieren der physikalischen Adresse ausschalten.

Jetzt steht ein Upgrade auf Debian buster und 0.14.30 an, die erste Version, die ich nicht selbst komplieren muss :-)

Bevor ich damit starte und riskiere, dass knxd erstmal nicht mehr tut, will ich die aktuelle Config aufräumen (oder zumindest verstehen), so dass das Upgrade möglichst keine große Unterbrechung nach sich zieht.

Hier meine aktuelle Config:
10.8.3.1 KNX IP Interface


MDT SCN-IP000.02:

• IP Address: 192.168.5.2
• Individual Address 1. 1.241
• Tunneling Addresses
  • 1. 1.250
  • 1. 1.251
  • 1. 1.252
  • 1. 1.253

10.8.3.2 ETS Setup


ETS Setup:

• Linie 1.1.* wird verwendet
• Physikalische Adresse MDT KNX IP Interface MDT SCN-IP000.02: 1.1.241
• 1.1.227 und 1.1.228-235 werden in der ETS nicht verwendet
• 1.1.250...1.1.253 wird in ETS nicht verwendet
• Bus-Schnittstelle: IP Tunneling
  • Server: 192.168.5.2
  • Individual Address: 1.1.241
  • Port: 3671

10.8.3.3 knxd


Interface mit knxd

→ Zum Programmieren physikalischer Adressen muss der knxd abgeschaltet sein.


Derzeitige Optionen (knxd 0.14.23-1, Debian stretch on armhf):

KNXD_OPTS="-e 1.1.227 -E 1.1.228:8 -t 65535 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt"

knxd nutze ich wie folgt:

• knxtool vbusmonitor1 ip:localhost : Monitoring von allem Traffic auf dem KNX bus
• knxtool groupswrite ip:127.0.0.1 <group addr> <val> : Boolsche Werte setzen
• knxtool groupwrite ip:127.0.0.1 <group addr> <val>: Numerische Werte setzen

Ein paar Fragen:

• Die -B Option finde ich in der knxd Doku
  https://github.com/knxd/knxd/wiki/Co...ine-parameters
  nicht (mehr). Ist sie nicht mehr gültig?
• Ich verstehe -E 1.1.228:8 nicht. Ich hätte eher -E 1.1.250:4 vermutet, da dies ja die im IP Interface konfigurierten Tunnel-Adressen sind (?) Oder macht das keinen Sinn?
• Wer nutzt die Adressen vom -E Parameter? knxtool vbusmonitor1 scheint ja (was so bleiben soll!) alle Nachrichten auf dem Bus zu sehen, egal ob sie für die -e bzw. -E Adressen bestimmt sind oder nicht...
• Macht es Sinn von dem Upgrade auf eine Konfig-File umzusteigen?
• Was kann dazu führen, dass das Programmieren einer physikalischen Adresse mit ETS nicht funktioniert, wenn knxd aktiv ist?

Bin für jeden Hinweis dankbar :-)

Relevante Erklärungen aus der knxd Doku, damit Option leichter nachvollziehbar sind:

knxd [global-section] [address-section] [cache-section] [multicast-server-section] [local-listener-section] [interface-sections]

address-section (not used for tunneling clients):

-e, --eibaddr=EIBADDR set our EIB address to EIBADDR (default 0.0.1)

-E, --client-addrs=ADDRSTART:n assign addresses ADDRSTART through
ADDRSTART+n to clients

local-listener-section:

Comparable to the multicast server, the local listener allows clients to connect to knxd. Unlike with the multicast server, the clients must directly connect to the knxd's computer, whereas the multicast server is reachable over its well-known multicast address.

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

-u, --listen-local[=FILE] listen at Unix domain socket FILE (default /run/knx)


You can define multiple TCP and/or UNIX socket listeners. If you need to listen to the old /tmp/eib socket, it's best to use a second -u option. A symlink will work also.

interface-sections:

For each interface there are possible interface modifiers and a (physical) interface parameter. You may have multiple physical interfaces. As with the multicast server, the interface sections consist of two parts each: [interface modifiers] and interface

interface modifiers

-t, --trace=MASK set trace flags (bitmask)


interface:

-b, --layer2=driver:[arg] a Layer-2 driver to use (knxd supports more than

one)


Supported interface drivers are:

ipt connects with the EIBnet/IP Tunneling protocol over an EIBnet/IP gateway. The gateway must be configured to route the necessary addresses

[...]


Filters:
A filter is a module which is inserted between the knx router itself and a specific driver. You specify filters with a "filters=" option in the driver's or server's section.

On the command line, -B|--filter=NAME told knxd to apply this filter to the next-specified driver.

Each filter names a section where that filter is configured. If a filter doesn't need any configuration you may just use the name of the filter. Thus,

-B foo -B bar -b some-driver

translates to

[some-driver]

filters=foo,bar

[...]
single

This filter allows knxd to connect to devices which only expect (or accept)

a single device. Thus, on outgoing packets knxd will remember the sender's

address in order to re-address any replies (if they're addressed

individually).

• address (--arg=address=N.N.N)
  The "single" filter typically uses knxd's address. However, that address is also used for multicast and thus is on the wrong line.
  
  Thus, you can use this option to assign a different address.

If you use this filter behind an "ipt:" driver, the address it uses will be replaced with the one assigned by the remote server.

Danke und Gruß
Rainer

[Tru]

KNXD_OPTS="-e 1.1.227 -E 1.1.228:8 -t 65535 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt"

Das müsste weiterhin gleich funktionieren.

Ein paar Fragen:

• Die -B Option finde ich in der knxd Doku
  https://github.com/knxd/knxd/wiki/Co...ine-parameters
  nicht (mehr). Ist sie nicht mehr gültig?
• Ich verstehe -E 1.1.228:8 nicht. Ich hätte eher -E 1.1.250:4 vermutet, da dies ja die im IP Interface konfigurierten Tunnel-Adressen sind (?) Oder macht das keinen Sinn?
• Wer nutzt die Adressen vom -E Parameter? knxtool vbusmonitor1 scheint ja (was so bleiben soll!) alle Nachrichten auf dem Bus zu sehen, egal ob sie für die -e bzw. -E Adressen bestimmt sind oder nicht...
• Macht es Sinn von dem Upgrade auf eine Konfig-File umzusteigen?
• Was kann dazu führen, dass das Programmieren einer physikalischen Adresse mit ETS nicht funktioniert, wenn knxd aktiv ist?

• Die -B Option gibt es weiterhin
• die -E Option verwaltet die Adressen der Clients, welche über knxd mit dem Bus kommunizieren. Damit sind diese Clients auch vom Bus her individuell unterscheidbar. Die -e Option ist die eigene Adresse des knxd. Aber ohne die Angabe von -S zusammen mit -R und/oder -T ist dein knxd für Clients als Server nicht ansprechbar. Mit den Tunneladressen deiner IP Schnittstelle hat es nichts zu tun (muss sich aber natürlich unterscheiden).
• Bringst du allenfalls Adressen und GA durcheinander? Die Adressen des -E Parameters ordnet knxd den einzelnen Clients zu. knxtool ist ein solcher (lokaler) Client.
• du kannst weiterhin mit der Parameter-Zeile arbeiten oder über knxd_args ein Konfig-File erstellen und nutzen. Ich persönlich lese die Parameter-Zeile leichter.
• deine wichtigste Frage kann ich leider nicht beantworten. Ich selber besitze nicht mal eine ETS und habe damit überhaupt keine Erfahrung. Ich docke mit knxd lediglich am Bus an, damit ich mit Freeware meine eigenen Sachen machen kann (Visu / Logikengine / Auswertungen). Könnte es sein, dass du noch eine weitere IP Schnittstelle am Bus hast?

Gruss, Othmar

[Smurf]

Jedes Interface verwaltet seine eigenen Adressen. Der knxd die der Clients die sich mit ihm verbinden, dein IP-Interface dito. Deshalb müssen die sich unterscheiden, und deshalb brauchst du auch das "-B single", weil das MDT-Interface dem knxd genau eine Adresse zuweist und im Zweifelsfall auch nur die sehen will (und nicht die der Programme, die sich mit dem knxd verbinden).

Wenn die Bereiche kollidieren, dann wird der knxd Daten der anderen Clients des MDT nicht weiterleiten.

[rdorsch]

Danke für die hilfreichen Antworten, aber natürlich werfen sie neue Fragen auf :-)

• Ist es ok, dass die knxd Adresse (-e 1.1.241) gleich der physikalischen Adresse (1.1.241) der KNX IP Schnittstelle ist? Oder müsste ich hier eine der Tunnel-Adressen verwenden? Und wenn ja, welche?
• Wenn nein, in welchem Szenario würde ich die Tunnel-Adressen nutzen?
• Stimmt es, dass Zieladressen, die als GA kodiert sind (DAF=1, multicast) immer an alle Busteilnehmer kommuniziert werden müssen?
• Ist der einzige Sinn und Zwecke der -E Adressen, dass Zieladressen mit (DAF=0, unicast) richtig geroutet werden?
• Wie funktioniert das bei -B single? knxd erhält Telegramme mit der Zieladresse des knxd. Wie kann er unterscheiden, für welchen seiner Clients ein Telegramm ist?
• Bekommt jede knxtool Instanz (d.h. jede knxtool group(s)write und knxtool vbusmonitor) eine eigene Adresse aus dem -E Bereich? D.h. meine Konfig erlaubt maximal 8 knxtool Instanzen gleichzeitig?

Danke und Gruß
Rainer

[Smurf]

Nein. Ja. Ist dem knxd egal.

Du nutzst physische Adressen gar nicht.

Das ist ein Bus. Da geht per Definition alles an Alle.

Nein. Ein weiterer Zweck ist das Unterdrücken von auf dem Bus im Kreis laufenden Paketen (oder Schlimmeres) bei Busschleifen. Die sind eigentlich verboten aber …

Er merkt sich von wem die Anfrage kam. Außerdem sind die meisten Telegramme eh gruppenadressiert, das Problem tritt nur beim Programmieren auf.

Ja. Korrekt.

[Tru]

oops, da habe ich zulange gebraucht und der Experte war schneller ...

Ist es ok, dass die knxd Adresse (-e 1.1.241) gleich der physikalischen Adresse (1.1.241) der KNX IP Schnittstelle ist? Oder müsste ich hier eine der Tunnel-Adressen verwenden? Und wenn ja, welche?
Wenn nein, in welchem Szenario würde ich die Tunnel-Adressen nutzen?

Nein, das ist nicht OK. Jedes Gerät am Bus benötigt eine eigene physikalische Adresse. knxd stellt dabei ein eigenes Gerät dar (-e Adresse) und vertritt die über ihn angeschlossenen Geräte (-E Adressen). Deshalb müssen alle diese Adressen noch frei sein. Physikalische Adressen dienen nach meiner Auffassung neben der Programmierung der Filterung von Telegrammen und helfen zu vermeiden, dass ein Telegramm vom einen Interface wieder über dieses Interface zurückgeschickt wird. Wofür die Tunneladressen der Schnittstelle genau verwendet werden, entzieht sich meiner Kenntnis, vielleicht zur individuellen Parametrierung?

Ja, jedes knxtool bekommt eine eigene Adresse (dabei wird rotiert) und du kannst in deiner Konfig maximal 8 Instanzen parallel betreiben.

Wie das mit -B single genau funktioniert, weiss ich auch nicht genau, ich benötige das nicht. Aber nach meiner Auffassung ist das dem knxd egal. Er muss ja einfach alle Telegramme an alle angeschlossenen Interfaces schicken, ausser an jenes woher das Telegramm gekommen ist. Die Zieladresse ist nach meiner Auffassung ja auch nicht die physikalische Adresse sondern die GA und jedes Gerät muss selbst wissen ob es auf die GA hört oder nicht. Das Wesen eines Buses ist doch, dass jedes angeschlossene Gerät jedes Telegramm sieht (ausser es wird irgendwo gefiltert) und die Zieladresse entscheidet dann, wer sich angesprochen fühlt. Aber wie in meiner ersten Antwort bereits angedeutet, bin ich auch nur Laie und nicht überall 100% sattelfest.

Gruss, Othmar

[Smurf]

nach meiner Auffassung neben der Programmierung der Filterung von Telegrammen und helfen zu vermeiden, dass ein Telegramm vom einen Interface wieder über dieses Interface zurückgeschickt wird.
Wofür die Tunneladressen der Schnittstelle genau verwendet werden, entzieht sich meiner Kenntnis, vielleicht zur individuellen Parametrierung?

… oder, schlimmer, über ein anderes Interface. Noch schlimmer wird es, wenn der Gatewayzähler im Paket auf 7 steht, weil er dann laut Standard nicht runtergezählt wird (eine Forderung, die der knxd geflissentlich ignoriert, weil Schwachsinn).

Die Schnittstelle macht genau dasselbe wie der knxd, nämlich jedem Client eine eigene phys.Adr zu verpassen – folglich braucht auch jeder Tunnel eine eigene. Der knxd hat das früher nicht getan, und die dafür nötigen Krücken aus dem Code zu entfernen hat mir durchaus Spaß gemacht.

[rdorsch]

Nochmal vielen Dank für die hilfreichen Antworten, der Nebel lichtet sich langsam, glaube ich.

Aber nochmal ein Satz Verständnisfragen (habe auch mal einen Blick in den code geworfen, aber die passenden Stellen nicht gefunden :-/ ):

• Werden physikalische Ziel-Adressen nur bei der Programmierung verwendet?
• Heißt das, dass nur die ETS Telegramme mit physikalischen Adressen schickt? Stimmt es, dass Antworten auch physikalsiche Ziel-Adressen verwenden müssen? Wobei mir noch nie ein Gerät über den Weg gelaufen ist, das Antworten verschickt, ich sehe immer nur Geräte, die Telegramme an ein GAauf den Bus schicken...
• Wenn das IP interface die Tunnel-Adressen an die Clients (z.B. knxd) verteilt, wieso muss ich dann die Adresse nochmal per -e an knxd mitteilen?
• Warum ist es egal, welche Tunnel-Adresse ich knxd mitteile?
• Was passiert, wenn die Adresse keine Tunneladresse ist, die ich knxd mitteile (ist aktuell so)?
• Zum single filter:
  • Sorgt knxd immer dafür, dass nur eine Lese-Anfrage auf dem Bus aussteht (zumindest an ein Zielgerät)? Und damit werden alle Antworten an knxd Clienten abgewickelt....
  • Ist eine Adressierung der knxd Clienten per physikalischer Adresse ist nicht möglich, da die ETS diese gar nicht kennt? Deshalb gibt es keine Lese- und Schreib-Telegramme an die physikalische Adresse von knxd Clienten

[Klaus Gütter]

Noch schlimmer wird es, wenn der Gatewayzähler im Paket auf 7 steht, weil er dann laut Standard nicht runtergezählt wird (eine Forderung, die der knxd geflissentlich ignoriert, weil Schwachsinn).

Das stimmt auch seit fast 2 Jahren nicht mehr (Application Note 189): HopCount 7 wird wie jeder andere Wert dekrementiert.

[Klaus Gütter]

Werden physikalische Ziel-Adressen nur bei der Programmierung verwendet?

Theoretisch ist so eine Punkt-zu-Punkt-Kommunikation (=physikalische Ziel-Adresse) auch im Betrieb möglich und erlaubt. In der Praxis kommt das aber tatsächlich nicht vor.

Stimmt es, dass Antworten auch physikalische Ziel-Adressen verwenden müssen?

Antworten auf was? Typischerweise (es gibt ein paar Ausnahmen) verwendet die Antwort die gleiche Kommunikationsart (Punkt-zu-Punkt=phys.Adresse / Multicast=Gruppenadresse / Broadcast) wie die Frage.

[thesing]

Klaus Gütter Gibt es irgendeine Möglichkeit als Privatperson auf die aktuellen Application Notes Zugriff zu erhalten? AN 189 ist der Spezifikation 2.1 nicht vorhanden. Oder gibt es eine Chance, dass die Spezifikation ein Update erhält?

[Klaus Gütter]

thesing Weiß ich nicht, am besten bei der KNX ein Support Ticket dazu
aufmachen.

[rdorsch]

Antworten auf was? Typischerweise (es gibt ein paar Ausnahmen) verwendet die Antwort die gleiche Kommunikationsart (Punkt-zu-Punkt=phys.Adresse / Multicast=Gruppenadresse / Broadcast) wie die Frage.

Ich habe verstanden ein KNX-Telegramm ist entweder eine Schreiboperation (Befehl-Teil im Datenfeld: 0b0010), eine Leseoperation (0b0000) oder eine Antwortoperation (0b0001), ich habe angenommen, dass sich die Antwort auf eine Lese-Operation bezieht. Allerdings habe ich nie gesehen, dass ich Kommunikationsobjekte eines KNX-Gerätes lesen könnte. Daher vermute ich, dass diese auch nur von der ETS in der Praxis verwendet werden. Wäre aber gut, wenn jemand bestätigen könnte, dass das tatsächlich so ist.

[Smurf]

Das stimmt auch seit fast 2 Jahren nicht mehr (Application Note 189): HopCount 7 wird wie jeder andere Wert dekrementiert.

Fein, das zu erfahren. Dummerweise sind die meisten Gateways da draußen (und/oder ihre Firmware) älter.

[Smurf]

Allerdings habe ich nie gesehen, dass ich Kommunikationsobjekte eines KNX-Gerätes lesen könnte. Daher vermute ich, dass diese auch nur von der ETS in der Praxis verwendet werden. Wäre aber gut, wenn jemand bestätigen könnte, dass das tatsächlich so ist.

Das wird von Visualisierungen etc. verwendet (ggf. als Fallback zum Cache des knxd …) um den aktuellen Status deiner Geräte auszulesen wenn du die Visu neustartest.