KNX Telegramm

[mmartin]

Hallo Michael,

ich kann Dir nur sagen, wie ein "normales" IP-Interface reagiert: Wenn Du ein Tunnel-Request (Group-Write) an das Interface schickst, antwortet es zuerst mit einem Tunnel-Ack. Danach sendet es selbst ein Tunnel-Request für die Confirmation, dass Du dann mit einem Tunnel-Ack beantworten musst.
Hierbei musst Du einige Sachen beachten: Gleiche Kanalnummer, mit der richtigen Sequenznummer antworten, Sequenznummern eigener Anfragen hochzählen, korrekte Adressierung HPAI ...

Wie sieht denn Dein Telegramm aus, das Du gesendet hast ?

Gruß,
Martin

P.S.: Sitzt Dein Client eigentlich auf der 192.168.56.1 (das steht jedenfalls in Deinem Connection-Request drin)

[micha149]

ich kann Dir nur sagen, wie ein "normales" IP-Interface reagiert: Wenn Du ein Tunnel-Request (Group-Write) an das Interface schickst, antwortet es zuerst mit einem Tunnel-Ack. Danach sendet es selbst ein Tunnel-Request für die Confirmation, dass Du dann mit einem Tunnel-Ack beantworten musst.

Ich bin ehrlich gesagt davon ausgegangen, dass sich EibD nach Außen hin wie ein echtes IP-Interface verhält. Aber ein TunelAck ist nicht zurück gekommen. Nur der eine Request, den ich hier gepostet habe.

Wie sieht denn Dein Telegramm aus, das Du gesendet hast ?

Ich habe die ChannelID aus der Connection-Response in dem Request verwendet und mit der Sequenznummer 0 begonnen. Den ersten Heartbeat schicke ich ja erst nach 60 Sekunden, oder? Hier mal das Datagram:

<Buffer 06 10 04 20 00 15 04 01 00 00 11 00 8C E0 00 00 08 03 01 00 81>

Wie müssten denn ein korrekter TunnelAck aussehen? Dann schicke ich den einfach mal auf die Connection-Resonse…

Grüße
Michael

[mmartin]

Hallo Michael,

probier mal aus dem 8C E0 ein BE E0 zu machen

die Flags für das Controlbyte 1 stimmen nicht.


Gruß,
Martin

[micha149]

Hallo Martin.

Habe das Control-Flag1 mal geändert. Das Verhalten ist aber immer noch das selbe.

Kann mir jemand verraten wie ein korrektes ACK Datagram aufgebaut wird?

[mmartin]

Hallo Michael,

ich habe Dir hier einmal ein Verbindungsaufbau (Connection Request/Response), Heartbeat (Connection State Request/Response) und ein Group-Write mit TunnelAck aus meinem Log kopiert (kein EIBD, sondern meine Eigenentwicklung). Hier kannst Du Dir aber mal die Reihenfolgen und Datagramme exemplarisch anschauen.

ConfluentiaBus  v1.3.5.36 (C) 2010-2013 by M.Mirgel

15.06.2013 08:54:31 INFO  Lokale IP Adresse auf 192.168.178.20 gesetzt
15.06.2013 08:54:41 INFO  Hydra v0.8.5.13
15.06.2013 08:54:46 INFO  1-Wire-Schnittstelle DS9097U /dev/ttyS0 gefunden
15.06.2013 08:54:46 CONFG Setze Speedmode von Adapter DS9097U /dev/ttyS0 auf flexibel
15.06.2013 08:54:47 DEBUG Sende Search-Request an Multicast-Adresse 224.0.23.12
15.06.2013 08:54:47 DEBUG Daten von /192.168.178.100: 06 10 02 02 00 4c 08 01 c0 a8 b2 64 0e 57 36 01 02 00 11 01 00 00 00 01 00 1e c0 da 00 00 00 00 00 0e 8c 00 13 5e 30 30 2d 30 45 2d 38 43 2d 30 30 2d 31 33 2d 35 45 00 20 20 20 20 20 20 20 20 20 20 20 00 08 02 02 01 03 01 04 01 
15.06.2013 08:54:47 DEBUG Search-Response von /192.168.178.100 (00-0E-8C-00-13-5E)
15.06.2013 08:54:47 INFO  Schnittstelle gefunden, Adresse: /192.168.178.100, Port 3671
15.06.2013 08:54:47 INFO  Sender erfolgreich gestartet
15.06.2013 08:54:47 INFO  Receiver erfolgreich gestartet
15.06.2013 08:54:47 INFO  Verbinde...
15.06.2013 08:54:47 DEBUG Sende Daten an /192.168.178.100:3671: 06 10 02 05 00 1a 08 01 00 00 00 00 00 00 08 01 00 00 00 00 00 00 04 04 02 00 
15.06.2013 08:54:47 DEBUG Daten von /192.168.178.100: 06 10 02 06 00 14 5e 00 08 01 00 00 00 00 00 00 04 04 11 01 
15.06.2013 08:54:47 CONFG Connection-Response von Schnittstelle erhalten
15.06.2013 08:54:47 INFO  Mit Kanal 94 verbunden
15.06.2013 08:54:47 CONFG Sende Heartbeat Connection-State-Request an die Schnittstelle
15.06.2013 08:54:47 DEBUG Sende Daten an /192.168.178.100:3671: 06 10 02 07 00 10 5e 00 08 01 c0 a8 b2 14 0e 57 
15.06.2013 08:54:47 DEBUG Warte 600 Sekunden auf nächsten 1-Wire-Lesevorgang mit Gruppenadresse 4/2/1
15.06.2013 08:54:47 DEBUG Daten von /192.168.178.100: 06 10 02 08 00 08 5e 00 
15.06.2013 08:54:47 CONFG Connection-State-Response von Schnittstelle erhalten
15.06.2013 08:54:47 CONFG Heartbeat Response von Schnittstelle
15.06.2013 08:54:47 CONFG Heartbeat ok
15.06.2013 08:54:47 INFO  KNX-Verbindung hergestellt
15.06.2013 08:55:00 INFO  Schreibe von 0.0.0 auf 3/1/0: Betriebsmodus Heizung: Frostschutz
15.06.2013 08:55:00 DEBUG Schreibe Frostschutz auf Betriebsmodus Heizung mit Sequenz 0
15.06.2013 08:55:00 DEBUG Sende Daten an /192.168.178.100:3671: 06 10 04 20 00 16 04 5e 00 00 11 00 be e0 00 00 19 00 02 00 80 04 
15.06.2013 08:55:00 DEBUG Warte auf Tunnel-Ack von Betriebsmodus Heizung
15.06.2013 08:55:00 DEBUG Daten von /192.168.178.100: 06 10 04 21 00 0a 04 5e 00 00 
15.06.2013 08:55:00 CONFG Tunneling-Acknowledge von Schnittstelle erhalten
15.06.2013 08:55:00 DEBUG Notifiziere wartenden Prozess auf Sequenz 0
15.06.2013 08:55:00 DEBUG Schreibvorgang auf 3/1/0 erfolgreich
15.06.2013 08:55:00 DEBUG Daten von /192.168.178.100: 06 10 04 20 00 16 04 5e 00 00 2e 00 bc e0 11 01 19 00 02 00 80 04 
15.06.2013 08:55:00 CONFG Tunneling-Request von Schnittstelle erhalten
15.06.2013 08:55:00 CONFG Frame von 1.1.1 an 3/1/0
15.06.2013 08:55:00 CONFG L-Data Confirmation auf Sequenznummer 0
15.06.2013 08:55:00 CONFG Confirmation von 3/1/0
15.06.2013 08:55:00 CONFG Sende Service-Ack Tunneling-Acknowledge an /192.168.178.100 auf Sequenz 0, Kanal 94
15.06.2013 08:55:00 DEBUG Sende Daten an /192.168.178.100:3671: 06 10 04 21 00 0a 04 5e 00 00 
15.06.2013 08:55:00 INFO  Bestätigung von 1.1.1 an 3/1/0 : Betriebsmodus Heizung: Frostschutz

Ich würde an Deiner Stelle (wenn nicht schon geschehen), Deine Installation mal überprüfen. Verbinde mal die ETS mit dem EIBD und starte den Gruppenmonitor (funktioniert auch in der Demoversion).
Erst wenn das funktioniert, würde ich an die Programmierung gehen.

Gruß,
Martin

[micha149]

Das ist klasse. Werde die Telegramme später mal durch gehen.

Die ETS hatte ich schon mal über KNXNet/IP mit der EibD verbunden. Nur mal zum Verständnis. Muss ich zwingend in den BusMonitor-Modus wechseln um alles vom Bus mitzubekommen? Mein Ziel ist es, dass ich alle Telegramme, die über den Bus laufen, in meiner Software verarbeite, zeitgleich aber auch die Möglichkeit habe zu senden.

LG Michael

[AurischH]

Hallo Michael,

Du hast nur versehentlich den Endpunkt des EIBD als Deinen Datenendpunkt angegeben. Daher erhältst Du keine Antwort.

Ein ConnectRequest besteht u.a. aus Deinem Control- und Deinem Datenendpunkt. Das sind zwei IP-Kommunikationsendpunkte, also IP-Adresse und Portnummer. Control- und Datenendpunkt können gleich sein, müssen es aber nicht. Du hast folgende Angaben gemacht:

c0 a8 38 01 a1 12 (=> 192.168.56.1:41234)
c0 a8 38 65 0e 57 (=> 192.168.56.101:3671)

Das sieht so aus, als ob Du den EIBD als Deinen Datenendpunkt angegeben hast, denn EIBD antwortet ja korrekt mit einem ConnectResponse und seinem Datenendpunkt. Und dieser lautet eben genau 192.168.56.101:3671.

VG
Horst

[micha149]

Damn. Ich dachte ich muss Server und Client angeben. Also EibD und mein Rechner. Habe mich schon gewundert, was der EibD mit seiner eigenen IP will. Was ist denn der Unterschied zwischen Control- und Datenendpunkt?

Gruß
Michael

[AurischH]

Die Kommunikation folgender KNXnet/IP-Frames läuft über den Datenendpunkt:

- TunnelingRequest
- TunnelingAck
- DeviceConfigurationRequest
- DeviceConfigurationAck

Die Endpunkte kannst Du aber auch gleich wählen. Die ETS vergibt zwei verschiedene Ports, eine KNXnet/IP-Schnittstelle i.d.R. nur einen Endpunkt mit Port 3671.

[tolgaue]

Für TunnelinRequest:

Um zum Beispiel eine Lampe einzuschalten, die auf Gruppenadresse 4/0/0 hört, muss das Telegram wie folgt aussehen:

Header (6 Bytes)
0x06: header length
0x10: protocol version 1.0
0x04: hi-byte service type (TunnelingRequest)
0x32: lo-byte
0x00: hi-byte total length
0x15: lo-byte (= Telegramlänge 21 Bytes)

ConnectionHeader (4 Bytes)
0x04: header length
0x??: channel-id (wird von ConnectResponse geliefert)
0x??: sequence-count (Requests werden durchnumeriert (0,1,...,255,0,1,...)
0x00: reserved

cEMI-Frame (11 Bytes)
0x11: message code, hier: REQUEST
0x00: add. info length (0 bytes)
0x8C: control byte
0xE0: DRL byte
0x00: hi-byte source individual address
0x00: lo-byte (wird durch das IP-Gateway ersetzt)
0x20: hi-byte destination address (hier: group address)
0x00: lo-Byte (also 4/0/0)
0x01: tpdu-length - 1 (also 2 Bytes folgen)
0x00:
0x81: schaltet die Lampe ein (80 aus)

Zusammen 21 Bytes (=header.total length)

Control byte
- standard frame (1 bit)
- unknown (1 bit)
- repeated (1 bit)
- broadcast (1 bit)
- priorität (2 bits) (0: system, 1: alarm, 2: hoch, 3: normal)
- ack requestet (1 bit)
- confirmation (1 bit)

DRL-Byte
- destination address group (1) oder individual (0) ( 1bit)
- routing counter (3 bits)
- data unit length (4 bits)

Für obiges Beispiel:
Control byte=0x8c = 10001100
- 1: standard frame
- 0: unknown
- 0: not repeated
- 0: no broadcast
- 3: priorität: normal
- 0: ack requestet
- 0: confirmation

DRL-Byte=0xe0 = 11100000
- 1: group address
- 6: routing counter: Standardwert
- 0: data unit length (immer 0)

Hallo!
Ich beschäftige mich auch gerade damit Tunneling Requests zu verstehen. Ich habe hierfür auch Zugang zu den Spezifikationspapieren (nicht alle, nur das was ich für meine Arbeit benötige) deshalb wollte ich gerne wissen in welchm Teil der Spezifikation der Header und ConnectionHeader Teil beschrieben ist.
Bedanke mich mal im voraus für nützliche Informationen. Externe Quellen gehen natürlich auch und notfalls muss ich mir das halt im Calimero mal anschauen

[AurischH]

Mir liegt das Dokument EVS-EN 13321-2:2012 vor (vom 12.12.2012).

Dort findest Du unter 5.2.5.3 die Beschreibung des Connection Headers (ab Seite 22).

Unter 5.2.2.3 ist der Header eines KNXnet/IP Frames beschrieben (Seite 18).

Viele Grüße,
Horst

[tolgaue]

Vielen Dank! Habe diese Dokumente nun von meinem Professor bekommen.