KNX/EIB Aufbau eines KNXnet IP Telegramms

[fraengg]

Hallo,

ich bin seit ein paar Tagen damit beschäftigt, die einzelnen Felder eines IP-Telegramms, welches von der ETS an einen IP-Router (Hager TH210 -> Baugleich wie Siemens N148) versendet und von da auf den KNX-Bus geroutet wird. Das IP-Telegramm hat eine Länge von 21 Bytes und mein Problem dabei ist, dass ich nirgends einen exakten Aufbaubeschrieb dessen finden kann.

Ich habe dann ein kleine Software geschrieben, welche diese Kommunikation nachbildet, was auch ganz ordentlich funktioniert. Ich weiss aber bei etlichen Felder nicht genau, was sie bedeuten und was sie machen.

Einige Felder konnte ich durch Analyse mit Wireshark (Sniffen der UDP-Datagramme auf der Ethernetschnittstelle) identifizieren. Ich muss aber alle wissen. Ich habe meine Fragen und Unklarheiten als PDF an diesen Eintrag angehängt.

Kann mir da jemand weiterhelfen?

Besten Dank für alle Antworten bereits zum Voraus!

Gruss
Frängg

[Uwe!]

Hast Du hier ab Seite 15 schon mal geguckt?

Uwe

[MarkusS]

Zur Beantwortung Deiner Fragen brauchst Du wahrscheinlich das KNX-Handbuch (kostet EUR 1.000,--) bzw. die DIN EN 13321-2 (Open data communication in building automation, controls and building management ― Home and building electronic systems Part 2: KNXnet/IP Communication - Inhalt http://www.beuth.de/cmd?workflowname...&languageid=de) - letzterer sollte zumindest in einer DIN-Auslegestelle http://www.beuth.de/php/partner_neu....se&gesamt=true kostenlos einsehbar sein, ansonsten kannst Du den um EUR 150,-- kaufen.

Gruss
Markus

[makki]

Zum Glück gibt's im Jahr 2008 Veröffentlichungsmöglichkeiten ohne ausbeuther dazwischen

hier bzw hier müsstest Du eigentlich alles relevante finden.
Edit: was Du suchst findest Du unter Stichwort cEMI
Edit2: Wusste doch ich hatte da mehr, hab nur zuviele Bookmarks Hier ist das ganze nochmal schöner, mit allen Details und in Deutsch erklärt..

Makki

[fraengg]

Besten Dank für die Antworten! Meine Fragen haben sich somit geklart.

In der Zwischenzeit bin ich noch auf das Projekt Calimero gestossen, welches für meine Anforderungen genau das richtige zu sein scheint. Da der Steuerungsserver (den ich mit KNX verbinden muss) bereits auf einer OSGi-Architektur basiert, eigent sich die Java-Library "Calimero" hervorragend.

Danke nochmals!

Gruss
Frangg

[swenga]

Hallo zusammen,

auch wenn sich der originale Thread erledigt hat, moechte ich kurz hier anknuepfen. Fuer mein Gateway zur Einbindung der Wärmepumpe habe ich auch angefangen, das KNXnetIP-Protokoll zu implementieren. Ich nutze einen Weinzierl IP730, vermute aber dass das Verhalten zu den anderen IP-Gateways durchaus identisch ist.

Ich habe die zugrundeliegenden Tätigkeiten (Connect Request, Tunneling Acknowledgements) soweit alle erschlagen und die Kommuniktaion funktioniert. Per Sniffer die ETS zu beobachten ist recht hilfreich

Ein paar Auffälligkeiten habe ich dennoch bemerkt. Ich hoffe hier in der Expertenrunde wird sich dazu Licht ins Dunkel bringen lassen.

1) Vor dem eigentlichen Nutzdaten des Pakets, wie es auch auf dem TP läuft, kommen vier Bytes. Das erste Byte der CEMI-Message ist, wenn es vom Bus kommt, immer 29h. Die ETS sendet an den IP-Gateway allerdings eine 11h. Wenn ich eine 29h sende, verwirft das Gateway dieses Paket. Kennt da jemand die Enumerations?
Das zweite Byte ist immer 0x00.
Das dritte Byte ist das Steuerfeld aus der KNX-TP-Welt. Hier ist mir aufgefallen, dass der HS immer "bevorzugt" sendet....
Das vierte Byte konnte ich wahlweise mit 0xC0 oder 0xE0 beobachten. Wenn ich Pakete versende, funktioniert es mit beiden Werten. Kennt da jemand die Bedeutung?

2) Danach kommen die Nutzdaten, beginnend mit der Sendeadresse. Im Routingzaehler wird über das Destination Flag zwischen Gruppenadresse (1) oder physikalische Adresse (0) unterschieden. Wenn ich das Destination-Bit setze, verwirft das Gateway mein Paket. Auch die ETS setzt dieses Bit nicht (für die normale Kommunikation mit dem Bus, Programmierung habe ich noch nicht gesnifft). Alle Pakete, die vom Bus kommen, haben es ebenso nicht gesetzt obwohl sie Gruppenadressen beinhalten. Liegt hier eine gewollte Abweichung vor, bei IP invertiert zum Protokoll auf dem TP oder so?

3) Sehe ich das richtig, dass der Datentyp im Paket nicht übertragen wird und die Auswertung sozusagen nur davon abhängig ist, dass dieselbe Paketlänge (1bit, 1-,2-,4- oder 14byte) beim Sender und Empfänger beachtet wird? Die ETS zeigt mir bei meinen gesendeten Werten Dezimal oder Hexwerte an, sobald ich aber einmal die Gruppenadresse mit der ETS im richtigen Datentyp versendet habe, decodiert sie den Empfang auch richtig.

Allgemeines: Das Übertragungssicherungsbyte ist bei KNXnet IP scheinbar verschwunden. Es reicht wohl die Layer3/4-Sicherung, die UDP/IP ja mit sich bringt.
Obwohl ein vom IP gesendetes Paket vom Gateway mittels Tunneling Ack bestätigt wird, sendet der Gateway das Paket nochmals als EIB-Paket zurück in den IP.
Der Gateway unterstützt maximal eine IP-Verbindung, Connection Requests von weiteren Teilnehmern werden abgelehnt. Schade, da UDP sehr wohl ein dezentrales Netz aus mehreren KNX/IP-Teilnehmern gestatten würde. Würde ein Router mehrere KNXnetIP-Verbindungen zulassen? Ansonsten wird wohl ein kleiner KNXnet/IP-Proxy notwendig sein....

Vielen Dank und frohe Feiertage,

mfg

Swen

[Klaus Gütter]

Hallo Swen,

das KNX-Telegramm ist in der cEMI-Message etwas anders codiert als auf dem Bus. Das kannst du leicht rausbekommen, wenn du Telegramme sowohl auf IP-Ebene wie auch auf TP anschaut. Tipp: deine letzte Frage bei 1) und dein Problem 2) haben damit zu tun (Routingzähler und Zieladresstyp-Bit befinden sich an einer anderen Stelle).

Zu 3: ja.

Warum das Übertragungssicherungsbyte nicht übertragen wird, sollte klar werden, wenn man sich bewusst macht, an welcher Stelle im KNX-Stack man sich befindet.

Gruß, Klaus Gütter

[swenga]

Hallo Klaus,

danke fuer die schnelle Antwort. Gleich mal geschaut und siehe da: Byte 4 des cEMI-Datensatzes enthält im Bit 7 das Destination Flag und im Bit 5 eine Null wenn das Paket über einen Linienkoppler kam, ansonsten eine 1.

Noch einmal das Thema Gateway: Ist dieses zurückspiegeln des über IP empfangenen EIB-Telegramms ein korrektes Verhalten? Würde ein IP-Router mehrere Tunnel-Verbindungen akzeptieren?

mfg

Swen

[Chris M.]

Würde ein Router mehrere KNXnetIP-Verbindungen zulassen? Ansonsten wird wohl ein kleiner KNXnet/IP-Proxy notwendig sein....

Beim Stöbern durch die EIB/KNX OpenSource-Projekte bin auch über ein Programm gestolpert, dass genau so eine Proxy-Funktionalität bietet. (Hm, war es evtl. eibd? Habe den Link nicht abgespeichert...)

[makki]

Ja, KNXnet/IP Routing funktioniert mit Multicast und lässt natürlich mehrere Verbindungen zu. Und ja, der eibd kann das, hat dabei allerdings Limitationen (physikalische Quell-Adresse wird auf 0.0.0 "geNATted"). Welche Auswirkungen das in der Praxis hat ist mir (noch) nicht bekannt..

Ich spüre da gerade einen potentiellen Kandidaten für den lange überfälligen KNXnet/IP Dissector für den Wireshark Wäre (gerade bei sowas) halt extrem praktisch, ich hab mir mangels C da erst diese Woche wieder ein paar Stunden sinnfrei die Zähne ausgebissen..

Makki

[swenga]

Hallo Makki,

ich habe in der Zwischenzeit ein wenig gegooglet. Scheinbar scheinen die IP-Schnittstellen (alos Tunneling Mode) generell nur einen Partner zuzulassen (Thema zeitgleich programmieren und Busmonitor geht nicht). Das Thema Rückspiegeln ist bei nru einem Partner sowieso nicht schlimm bei zwei oder mehr eher aergerlich.

Ich hatte gehofft, dass die Tunneling-Implementierung etwas einfacher sei und daher diese gewählt. War aber doch auch nicht so einfach

Ich habe jetzt mal nach den Nachrichten für das Routiung geschaut. Generell ist die verfügbare Dokumentation recht duenn. Aber es gibt wohl die "Routing Indiaction", Service Type 0x0530 sowie die "Routing Lost Message", 0x0531. Letztere scheint nicht zur Aufrechterhaltung der Kommunikation erforderlich zu sein (zumenidest nicht in einer 1zu1-Notwendigkeit wie Tunneling Request und Ack). Multicast ist kein Thema, da habe ich bereits Applikationen für gemacht. Die MC-Adresse für KNX 224.0.23.12 ist auch bekannt. Also muss ich meine Schnittstelle noch in einen Router "verwandeln" (BTW, brauch jemand eine?). Es könnte also sein, dass Routing einfacher ist als Tunneling....

Bei der Entwicklung ist es immer hilfreich, zwei Endstellen bei der Kommunikation zuzuschauen. Da ich keine zwei Router einsetzen/kaufen möchte, wäre die ETS die Option. Meine 3.0f hat auf jeden Fall die Kommunikationsoption. Funktioniert der ETS-Buszugriff über Routing, wer hat da Erfahrungen? Nicht verwechseln, alle Router lassen zusätzlich noch den Buszugriff über Tunneling zu.

mfg

Swen

[Uwe!]

ich habe in der Zwischenzeit ein wenig gegooglet. Scheinbar scheinen die IP-Schnittstellen (alos Tunneling Mode) generell nur einen Partner zuzulassen (Thema zeitgleich programmieren und Busmonitor geht nicht).

Hallo Sven,
bin auf dem Gebiet nicht besonders firm un hoffe daher jetzt nichts misszuverstehen. Aber ich kann mit meiner IP-Schnittstelle (N148/21) defintiv den Busmonitor parallel zur Programmierung laufen lassen.

Uwe

[swenga]

Hallo Uwe,

das ist interessant. Ganz sicher N148, also die Schnittstelle und nicht der Router N146? Und Du hast Den Busmonitor, nicht den Gruppenmonitor offen und verbunden und kannst Deine Programmiertelegramme lesen? Und zu guterletzt (weil ich abergläubisch bin ;-) ): In der Menüleiste des Busmonitors mittig ist die aktive Verbindung des Monitors, diese ist mit der in der Fußleiste der ETS identisch? Dann wär das ein Ding....

Ich mach manchmal auch so ein Setup, wo ich die IP-Schnittstelle zum Programmieren und die EIBlib-Schnittstelle des HS für den Busmonitor nutze. Bloss hat die ETS dann eben zwei (unterschiedliche) Verbindungen offen.

Danke schonmal fuers nachschauen.

mfg

Swen

[BliBlaBlo]

Erstmal ein Hallo ans KNX-User Forum

Ich beschäftige mich seit ca. einer Woche mit KNXnet/IP und bin der Aufbau des KNXnet/IP Telegramms macht auch mir Kopfzerbrechen.

Ich habe denk ich mir schon einiges verstanden wie die Kommunikation funktioniert aber der cEMI Teil macht mir noch Sorgen.

Ich habe mir das Buch bzw. die Norm (Open data communication in building automation, controls and building management ― Home and building electronic systems Part 2: KNXnet/IP Communication) von der UNI ausgeborgt aber leider nichts gefunden was den genauen Aufbau eines cEMI Packetes erklärt.

Das habe ich mal mit Wireshark von der ETS gesnifft (Kommunikation mit einem Weinzierl IP 730):

2b090301 02060401 8b3079bc db0c0a03 e10080fc

2b = Messagecode
09 = Additional Info Length
== 03 01 06 06 04 01 54 06 8c
dabei ist 03 ein Code, 01 die Länge und somit 02 die Daten
dann ist 06 ein Code, 04 die Länge und 01 8b 30 79 die Daten
bc = CTRL1 // glaub ich aber nicht so recht weil...
db 0c = Source Addr
0a 03 = Destination Addr (und das stimmt ganz sicher weils von 1/2/3 gekommen ist)... und somit ist CTRL2 nicht da...?!?
e1 = was das e davon bedeute weiß ich nicht, aber ich denke der 1er ist die länge der daten
00 = TPCI
80 = APCI (davon ist der 0er die Daten?!?)
FC = Checksumme?

Wäre toll wenn jemand ein bisschen Licht in mein Dunkel bringen könnte

Lg

[swenga]

Bist Du Dir sicher, dass du auf dem richtigen Port gelauscht hast? Die Byte-Sequenz gibt mir totale Rätsel auf.... Steckt da irgendwo noch Layer 3/4 drin oder ist das nur der UDP-Payload-Anteil?

Ein IP730 ist eine Schnittstelle, also Tunneling. Hierbei gibt es zwei Verbindungen, die Control-Session und die Data-Session. Es wird Interface-seitig immer Port 3671 genutzt, die lokalen Ports sind individuell.

Der Nutzdatenblock muesste beginnen mit:
06 10
dann kommt der Service Type, also wahlweise:
04 20 Tunneling Request (nur in der Data Session)
04 21 Tunneling ACK (nur Data)
02 09 Connect Request (nur Control)
02 06 Connect Response (nur Control)

Das 0206 sehen wir, aber dahinter kommt die Paketlänge, die ist mit 0401h=1025d ein wenig schräg...

Prüf mal bitte, dass nur der Inhalt des UDP-Pakets angezeigt wird. Beim Aufbau der Verbindung sendet die ETS einen Connect-Request an das Interface auf Port 3671 (mit ihrem Data-Port als Argument, das Interface antwortet mit dem Connect Response. Danach sendet die ETS (von einem anderen Quell-Port, aber wieder Zielport 3671!!!) die Nutzdaten via Tunneling Requests.

mfg Swen