KNX Telegramm

[Fuxp]

Das ist eben genau dass dass mich auf die falsche Fährte gelockt hat...das ist der Telegrammaufbau beim TP und hat nichts mit KNXIp / Routing zu tun, aber dennoch Danke!

[pheno]

Aloha,

beschäftigt habe ich mich auch damit und viel gelesen.
Calimero teste ich gerade.

Hier gibt es noch jede Menge Info's rund um den Common EMI Frame und cEMI:

Knowledge Base - OpenRemote Knowledge Base

gtx,
Manolo

[swenga]

Routing-Beispiel:


cemi:
0x11
0x00
0xBC
0xE0
Es folgen 2 Byte fuer den Absender
Jetzt 2 Byte fuer den Empfänger/GA
Ein Byte mit Type-Indication und Länge
(Bit 7: 0 für GA, 1 für Adressat, Weiterleitung auf Bit5+4 (normal 0), Länge auf Bit 3..0)
Ein NullByte
Danach folgt das erste Datenbyte, dass allerding den TP-ähnlichen Typ-Header davor hat, also:
Bit 7..6: Wert 2 für Wert schreiben
Bit 0: fuer einen 1-Bit Wert
oder aber Folgebytes für alle Werte mit Länge grösser 1.

Danach ist dem cEMI-Paket die Routing Indication davorzusetzen
0x06 Header
0x10
0x05 Service Type Routing
0x30
Es folgen 2 Byte mit der Länge des Gesamtpakets, also 6+cEMI-Length

und absenden....

[Fuxp]

Und Schwupp es funktioniert....das gibts doch einfach nicht :-)
Ihr seit GENIAL!!!

Das ist nun mein CEMI Frame

06100530001129008ce0ff010001010081

Das Funktioniert soweit Wunderbar!! (am Schluss 80 = 0)

also Header Teil ist: 0610053000

Und das eigentliche cEMI: 1129008ce0ff010001010081

Mein cEMI Stimmt jetzt aber nicht wirklich mit euren überrein...

[AurischH]

Dir ist ein kleiner Fehler in der Header-Interpretation unterlaufen:

Das Byte 0x11 gehört nicht zum cEMI-Frame sondern noch zum Header (Low-Byte von total length, also 17 Bytes).

Damit lautet Dein cEMI-Frame:

29008ce0ff010001010081

Und das stimmt fast überein mit der Vorgabe von swenga.

Swenga verwendet ein "L-Data request" (0x11) und Du ein
"L-Data indication" (0x29). Ich würde hier auch ein Request erwarten, weil ein Indication immer vom Bus kommt.

Der letzte Unterschied liegt im Controlbyte: Der Unterschied zwischen 0x8c und 0xbc liegt nur in den Einstellungen der Bits "repeat" und "broadcast". swenga verwendet hier jeweils 1. Muss nochmal schauen, was ETS verschickt...

[pheno]

Aloha!

Vielleicht ist das noch anschaulicher.
Das ist ein TCP dump eines Switch Befehls (On) von 0.0.0 --> 2/0/14.
Header (6 Bytes) + Connection Header (4 Bytes) + cEMI Frame (11 Bytes):

4500: 0100 0101 0000 0000 
0031: 0000 0000 0011 0001 
0c80: 0000 1100 1000 0000 
0000: 0000 0000 0000 0000 
4011: 0100 0000 0001 0001 
eac1: 1110 1010 1100 0001 
c0a8: 1100 0000 1010 1000 
011e: 0000 0001 0001 1110 
c0a8: 1100 0000 1010 1000 
010c: 0000 0001 0000 1100 
2713: 0010 0111 0001 0011 
0e57: 0000 1110 0101 0111 
001d: 0000 0000 0001 1101 
0c52: 0000 1100 0101 0010 
0610: 0000 0110 0001 0000 Header length (0x06)  | Protocol version 1.0
0420: 0000 0100 0010 0000 Service Type Hi (0x04)| Service Type Lo (0x32) <-- Tunneling Request
0015: 0000 0000 0001 0101 Total Length Hi (0x00)| Total Length Lo (0x15)
0449: 0000 0100 0100 1001 Header length (0x04)  | Channel ID (0x49) <-- Connection Header
0400: 0000 0100 0000 0000 Sequence count (0x01)*| Reserved 
1100: 0001 0001 0000 0000 Message Code (0x11) | Additional Info Length (0x00)
84e0: 1000 0100 1110 0000 Control Byte 1      | Control Byte 2 (DRL)
0000: 0000 0000 0000 0000 SRC Address Hi      | SRC Address Lo (0.0.0)  individual address
100e: 0001 0000 0000 1110 DST Address Hi      | DST Address Lo (2/0/14) group address
0100: 0000 0001 0000 0000 TPDU-Length 2 Bytes | EIB DATA (DPT 1 Switch)
81  : 1000 0001           EIB DATA (Write On command)

Die einzig noch offene Frage ist...wofür sind die ersten 28 Bytes?
gtx,
Manolo

[makki]

Die einzig noch offene Frage ist...wofür sind die ersten 28 Bytes?

Ohne es jetzt gelesen zu haben würde ich blind auf 20 Byte IP + 8 Byte UDP-Header tippen..

Edit: der IP-Parser im Kopf ist doch nochmal angesprungen: 192.168.1.30:10003 -> 192.168.1.12:3671, macht Sinn
Und jetzt hab ichs doch gelesen: Stimmig, der DPT steht aber definitiv nicht im cEMI..

Makki

[swenga]

Und jetzt hab ichs doch gelesen: Stimmig, der DPT steht aber definitiv nicht im cEMI..

Hallo Makki,

wobei man bei Länge 1 nicht so recht viel Wahl hat

Alle anderen Längen sind dann aber *%&/GRMPF!!!, da fuer den DPT zwangsläufig der GA-Katalog aus dem ETS-Export genutzt werden muss.

mfg

[Fuxp]

Bei deinem Dump Blick ich Grad bei den Adressen nicht durch...

Wo ist denn bei dir die 2/0/14??

[swenga]

Bei deinem Dump Blick ich Grad bei den Adressen nicht durch...

Wo ist denn bei dir die 2/0/14??

Bitte keine ganzen Beiträge zitieren, das ist nicht Sinn-steigernd!

Ansonsten:
100e: 0001 0000 0000 1110 DST Address Hi | DST Address 2/0/14
0001 0 = 2
000 = 0
0000 1110 = 14
mfg

[Fuxp]

Hi an alle, das klappt schonmal alles Wunderbar...
Hab noch 2 Fragen, über den ETS gehe ich mit dem IP/Router von Feller. Das heisst ich mache das ganze über Routing...

Um Werte zu setzen klappt das super, das Problem ist aber, ich kann keine lesen...heisst dass ich keine Chance habe über Routing UDP Multicast Werte zu lesen???

Möchte dass zuerst mittels ETS machen und das cEMI dann sniffen um in meinem Programm ebenfalls eine Abfrage zu machen...weiss jemand woran dass das liegen könnte?

[AurischH]

Natürlich funktioniert auch Lesen. Hierzu musst Du lediglich Deinen Komponenten auch die Möglichkeit geben, eine Antwort zu senden. Setze einfach mal das Lesen-Flag eines Tasters in ETS.

[pheno]

Aloha,

ich beschäftige mich immer noch mit dem Versenden von KNX Telegrammen.
Habe auch schon viel gelesen und Research betrieben.

Inzwischen habe ich gelernt, dass einem Data Request (z.B. ein DPT1.001) ein Connect Request vorausgehen muss. Diesem entnehme ich dann die Channel-ID, die u.a. auch für den Data Request verwendet wird.

Nun meine Frage. Wieso wird im Connect Request der Endpoint (bestehend aus 8 Bytes?) zweimal hintereinander gesendet?
Hat das einen speziellen Grund?

Ich frage nur, weil ich immer gerne versuche (fast) alles mit Logik zu begründen.
Thx,
Manolo

[makki]

Nun meine Frage. Wieso wird im Connect Request der Endpoint (bestehend aus 8 Bytes?) zweimal hintereinander gesendet?

1x für den Control und 1x für den Data Endpoint auf dem Client.
Das dröselt der Wireshark-Dissector übrigens auch schön auf..

Makki

[pheno]

Danke makki!

Okay das hab' ich kapiert

...aber bei einem Client Request sind die beiden HPAI's doch beide gleich.
In welchem Fall sind sie denn unterschiedlich?
Wenn der Request nochmals getunnelt wird?
Danke,
Manolo