KNX Telegramm

[no sleep]

Ihr werft ja hier Einiges durcheinander...
Den Weinzierl vergesst ihr mal ganz schnell wieder, das ist eine proprietäre Ansteuerung per TCP, die nur mit diesem Gerät funktioniert.
Die Kommunikation per KNX-Routing bzw. Tunneling funktioniert grundsätzlich per UDP.
Dabei werden auch keinerlei Startbits o.ä. Übertragen, sondern die Hex-Bytes "nackt" in einem Stück als komplettes Telegramm, so wie sie sind.
Jetzt müsst Ihr euch für ein Verfahren (Tunneling oder Routing, hängt auch vom KNX-Gateway ab) entscheiden und das "drumherum" bauen. Ein einfach so ins LAN gepustetes KNX-Telegramm wird ohne den passenden Kontext sicherlich nicht von den Gateways akzeptiert werden.

[pheno]

Hallo Sascha,

danke für die Aufklärung!
Das wir hier einiges Durcheinanderwerfen war mir schon klar

Ich habe das IP-Interface vom EIB-Markt welches wohl baugleich mit dem Weinzierl 730 ist.

Nur in einem Punkt muss ich dir widersprechen mein IP-Interface kommuniziert via UDP auf dem Port 3671 (siehe tcpdump) und nicht per TCP:

12:12:34.400662 IP (tos 0x0, ttl 64, id 64488, offset 0, flags [none], proto UDP (17), length 44, bad cksum 0 (->fb76)!)
    tank.lispworks-orb > 192.168.1.12.efcp: [bad udp cksum f3ef!] UDP, length 16
        0x0000:  4500 002c fbe8 0000 4011 0000 c0a8 0105  E..,....@.......
        0x0010:  c0a8 010c 0e58 0e57 0018 838b 0610 0207  .....X.W........
        0x0020:  0010 0c00 0801 c0a8 0105 0e58            ...........X
12:12:34.402131 IP (tos 0x0, ttl 16, id 40771, offset 0, flags [none], proto UDP (17), length 36)
    192.168.1.12.efcp > tank.lispworks-orb: [udp sum ok] UDP, length 8
        0x0000:  4500 0024 9f43 0000 1011 8824 c0a8 010c  E..$.C.....$....
        0x0010:  c0a8 0105 0e57 0e58 0010 4b9d 0610 0208  .....W.X..K.....
        0x0020:  0008 0c00 0000 0000 0000 0000 0000       ..............

192.168.1.12 ist mein IP-Interface, dass andere ist mein MacMini-Server.
Das Verfahren zur Kommunikation, dass ich verwenden möchte soll weder Tunneling noch Routing sein. Ich möchte direkt 1:1 auf den UDP Port die Telegramme senden.

Also wenn ich dich richtig verstanden habe, dann benötige ich folgendes für eine erfolgreiche Übertragung eines KNX Telegramms:

- UDP-Verbindung mit IP-Interface auf Port 3671
- KNX-Telegramm in HEX-Zeichen-Darstellung

Fehlt sonst noch etwas?
Was meinst du allerdings mit deiner Aussage

Ein einfach so ins LAN gepustetes KNX-Telegramm wird ohne den passenden Kontext sicherlich nicht von den Gateways akzeptiert werden.

Sorry, aber für mich ist das ein wenig unspezifisch.
Vielen Dank schon mal für deine Hilfe!
gtx,

Manolo

[no sleep]

Ich habe das IP-Interface vom EIB-Markt welches wohl baugleich mit dem Weinzierl 730 ist.

Nur in einem Punkt muss ich dir widersprechen mein IP-Interface kommuniziert via UDP auf dem Port 3671 (siehe tcpdump) und nicht per TCP:

Meine Aussage bezog sich auf Fuxp's Link, in dem der Object-Server des 770 erklärt wurde. Das ist wie gesagt ein proprietärer Ansatz.

Das Verfahren zur Kommunikation, dass ich verwenden möchte soll weder Tunneling noch Routing sein. Ich möchte direkt 1:1 auf den UDP Port die Telegramme senden.

Wozu? Du wirst kein KNX-zertifiziertes Gerät finden, das auf diese Telegramme reagieren wird. Es gibt nur die beiden Varianten Routing bzw. Tunneling.

Also wenn ich dich richtig verstanden habe, dann benötige ich folgendes für eine erfolgreiche Übertragung eines KNX Telegramms:

- UDP-Verbindung mit IP-Interface auf Port 3671
- KNX-Telegramm in HEX-Zeichen-Darstellung

"HEX-Zeichen-Darstellung"? Die Hex-Werte stellen die Bytes so dar, wie sie übertragen werden, also keine ASCII-Interpretation o.ä.. Du könntest die Zahlen auch dezimal oder oktal schreiben, den Geräten ist das egal, da sich die Bytes dadurch nicht ändern.

Fehlt sonst noch etwas?
Was meinst du allerdings mit deiner Aussage
Sorry, aber für mich ist das ein wenig unspezifisch.

Wie gesagt: "rohes" Übertragen des Telegrammes geht nicht, dafür muß man zwingend entweder KNX-Routing bzw. KNX-Tunneling implementieren. Der EMI-Frame wird also nochmal in das Routing- bzw. Tunneling-Protokoll gekapselt und erst dann wird das, was Du da vor hast, funktionieren.
Beachte, das meistens nur die höherpreisigen Geräte Routing unterstützen.

[pheno]

Hallo Sascha,

danke nochmal! So langsam komme ich auf Spur
Das die Übertragung natürlich in bits erfolgt ist mir auch klar.

Also werden die Bytes des Telegramms in Hex-Darstellung in das Duale Zahlensystem umgewandelt und dann allesamt auf den Bus geschickt!?!

Das ganze muss dann praktisch gekapselt werden in einer KNX-Tunnel/-Routing Implementierung korrekt?
SB, EB & PB brauchen wir dabei nicht und die Pausenbits auch nicht.
Übernimmt das dann mein IP-Interface?

Ich werde mich dann mal schlau machen wie ich einen KNX-Tunnel oder -Router softwareseitig implementiere, damit ich meine KNX-Telegramme verschicken kann. Natürlich auch um die Quittung zu empfangen.
thx,

Manolo

[iwan]

Hallo

Routing dürfte einiges einfacher zu implementieren sein.
So wie ich das verstanden habe ist das "einfaches" Multicast auf 224.0.23.12.

Gruss
Iwan

[no sleep]

Also werden die Bytes des Telegramms in Hex-Darstellung in das Duale Zahlensystem umgewandelt und dann allesamt auf den Bus geschickt!?!

Auf den Bus natürlich bitweise, da der Bus ja nicht 8 Bit breit ist.
Das muß Dich aber nicht interessieren, da Du nur IP-seitig arbeitest.

Das ganze muss dann praktisch gekapselt werden in einer KNX-Tunnel/-Routing Implementierung korrekt?

Richtig.

SB, EB & PB brauchen wir dabei nicht und die Pausenbits auch nicht.
Übernimmt das dann mein IP-Interface?

Genau.

Ich werde mich dann mal schlau machen wie ich einen KNX-Tunnel oder -Router softwareseitig implementiere, damit ich meine KNX-Telegramme verschicken kann. Natürlich auch um die Quittung zu empfangen.

Bei KNX-Routing gibt's IP-seitig keine Quittung.

Viel Erfolg!

[AurischH]

Such doch mal im Internet unter den Stichwörtern "knx calimero". Der dort verwendete Code ist sehr leicht zu verstehen.

Mit wenigen Bytes, die Du an Dein IP-Gateway schickst, kann Du schon beispielsweise Lampen schalten. Dafür muss man den Aufbau des UDP-Datagrams gar nicht verstehen. Ich würde Dir natürlich dennoch raten, den genauen Aufbau zu entschlüsseln.

[pheno]

Hey Sascha & AurischH,

SUUUUUUPER!

Danke das hilft mir weiter...wenn das so weiter geht, dann komme ich meiner Lösung schon näher

Über Calimero habe ich bereits etwas gelesen, das war glaube ich in Java, dass versteh sogar ich!!!

Also ich hab' jetzt ja 'n Päckchen zu lesen und wenn ich neue Erkenntnisse habe, dann schreibe ich wieder.
Bei dummen Fragen natürlich auch.

Danke...und nochmals Danke
Manolo

[Fuxp]

Hallo

Routing dürfte einiges einfacher zu implementieren sein.
So wie ich das verstanden habe ist das "einfaches" Multicast auf 224.0.23.12.

Gruss
Iwan

Hast du da irgend ne Quelle dafür? Danke dir!

[iwan]

Hier wurde auch schon mal drüber diskutiert.
Wenn du dir das ganze mit Wireshark (KNX Dissector) anschaust siehst du so einiges.
Habe mich auch schon mal damit beschäftigt, jedoch bis jetzt keine Zeit was umzusetzen.

Gruss
Iwan

[Fuxp]

Ich bin nun einige Schritte weiter...die ganzen Telegramme die hier am Anfang erklärt wurden sind für den BUS...was wir brauchen (was hier auch schon gesagt wurde!!!) ist das cEMI.

Der Aufbau des cEMI ist mir immer noch einwenig Schleierhaft, eine genauer Doku wäre sehr hilfreich.

Schwierigkeiten bestehen bei mir konkret nun, das cEMI Frame ins Routing Protokoll zu kriegen, das soll gemäs Calimero Projekt relativ einfach sein...leider blicke ich noch nicht ganz durch (Obwohl Code einigermassen verstanden) kann da jemand noch nen Springenden Tipp geben? Und falls jemand ein cEMI - DEMO Frame hat wäre das auch sehr hilfreich...

Danke an alle die mithelfen, die gefunden Informationen werde ich dann sauber Zusammenfassen und ein kleines WIKI erstellen was dann evtl. hier publiziert werden könnte?

Vielen Dank an ALLE!!

[AurischH]

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)

Das IP-Gateway schickt darauf hin zunächst ein TunnelingAck-Telegramm und dann sofort ein TunnelingRequest-Telegramm mit message code = 0x2e für CONFIRMATION. Das wiederum sollte mit einem TunnelingAck vom Client beantwortet werden.

Wenn das Gateway ein Telegramm empfängt (z.B. weil ein Taster betätigt wurde), so wird dieses per TunnelingRequest mit message code 0x29 für INDICATION weitergegeben (auch das muss per TunnelingAck beantwortet werden).

Wenn Du jetzt noch den Heartbeat (alle 60 Sekunden ein ConnectionStateRequest-Telegramm) realisierst, bist du schon fertig :-)

Ich habe das vor Kurzem in c# realisiert, um eine eigene Visualisierung aufzubauen. Außerdem bin ich dabei ein Proxy zu realisieren, um z.B. gleichzeitig mehrere Visualisierungen betreiben zu können. Mein GIRA-IP-Gateway lässt nämlich immer nur eine Tunneling-Verbindung zu. Ok, dass könnte man auch noch anders realisieren, aber man muss ja in Übung bleiben... :-). Weiß nicht, ob man ein Proxy wirklich gebrauchen kann. schön ist nur, dass man z.B. parallel ETS nutzen kann ohne die Visualisierung abzuschalten.

Viele Grüße,
H. Aurisch

[AurischH]

Die genaue Bedeutung der Controlbits hängt vom Medium und vom Message code ab. Ich muss das mal ordentlich zusammenschreiben...
Mein (Halb-)wissen stammt allerdings nur aus den Sourcen von Calimero - mir fehlt leider die kostenpflichtige KNX-Dokumentation...

[Fuxp]

Vielen Dank für deine Mühe, genau sowas habe ich gesucht, :-) Jetzt müsste ich noch wissen wies beim Routing aussieht...weil beim Tunneling kann ja immer nur ein Gerät Connecten..ich möcht es unbedingt mit Routing realisieren...

Hast du noch Infos was sich zum Tunneling ändert?

Danke dir vielmals für deine Mühe!!!

[Hennessy]

Mein (Halb-)wissen stammt allerdings nur aus den Sourcen von Calimero - mir fehlt leider die kostenpflichtige KNX-Dokumentation...

Hast Du hier schon gschaut?
Basic of EIB and other usefull Information

Da hat's massig Infos ...