KNX-RF mit CUL

[tostmann]

CUL etc. beherrschen nun auch Wireless M-Bus.
Somit ist ein Empfang von KNX-RF Datagrammen (im S-Mode) möglich.
Ein guter Einstieg ist: http://www.knx-professionals.nl/UploadBestanden/01%20Joost%20Demarest%20-%20KNX%20Association.pdf

Ein CUL (mit culfw-HEAD aus svn) wird mit "brs" auf s-mode Empfang eingestellt und dumped dann empfange Datagramme byteweise in Hex nach Prefix "b":

b1144FF0200C501001E39E8220005FF000DE0008118F3
b1144FF0200C501001E39E8220005FF000DE20080D3A7
b1144FF0200070001F34D8ED90005FF0005EA0080A829
b1144FF0200C501001E39E8220005FF000DE40081C9F4
b1144FF0200C501001E39E8220005FF000DE6008002A0
b1144FF0200070001F34D8ED90005FF0005EE0080792E
b1144FF0200C501001E39E8220005FF000DE800818798
b1144FF0200070001F34D8ED90005FF0005E00081FC16

Hier ein Waveline Medienkonverter 6770 und ein Schaltaktor 6701

Vielleicht hat ja jemand Verwendung dafür und baut ein FHEM Modul.

[kaihs]

Ich bringe das Thema mal wieder hoch, da sich aktuell KNX-RF mit WMBUS ins Gehege kommt.

Beide werden von der culfw als b Pakete gemeldet, da beide die selben unteren Protokollschichten verwenden.
Die Applikationsschicht ist aber unterschiedlich und das WMBUS Modul kann mit den KNX-RF Daten nichts anfangen.

Die von tostmann verlinkte Dokumentation ist nicht mehr verfügbar und eine frei verfügbare Beschreibung von KNX-RF kann ich nicht finden.
Es scheint aber so zu sein, dass die eigentlichen Nutzdaten sehr ähnlich zum kabelgebundenen KNX sind. Daher könnte das vorhandene EIB Modul mglw. damit umgehen, wenn man funkspezifischen Daten entfernt.
Hat jemand genauere Informationen über KNX-RF?

Ich suche gerade nach einer Möglichkeit WMBUS und KNX-RF auseinander zu halten.
Es scheint so zu sein, dass Byte 2 und 3 eines KNX-RF Pakets immer 44FF sind, kann das jemand bestätigen?

[quicklink_dev]

Hi kaihs,
kann ich bestätigen mit Byte 2 und 3. Siehe Grafik im Anhang bzw. dieses PDF: http://www.radiocrafts.com/uploads/knx_user_manual_0_30.pdf auf Seite 8.

Ich versuche noch nähere Infos dazu zu bekommen.

[quicklink_dev]

Hallo,
so habe jetzt mehr Infos zu den KNX-RF Blöcken; als Beispiel dieses Telegramm: 1144FF02820905010D0D68700005FF010AEC0081D989

Block 1 - 10byte - CRC1
11 - Length
44 - C-Field according to IEC870-5 (always the same)
FF - ESC (always the same)
02 - RF-Ctrl (02=battery state of sender OK --> bit 0 = Undir = 0:frame sent by bidirectional device, 1:frame sent unidirectional device  / bit 1 = battery state of sender 0:weak; 1:OK)
820905010D0D (KNX serial no. of the sender / 6 octets)

6870 - CRC

Block 2 - 16 byte - CRC2
00 KNX-Ctrl
05FF Source-Address
010A Destination-Address
EC L/NPCI
00 TPCI
81 APCI

D989 - CRC

Kann damit jemand was anfangen bzw. das EIB-Modul entsprechend erweitern? Wäre klasse 

[Andi291]

Abend!

Also ich hab mir das mal oberflächlich angesehen - ein Spaziergang wird das nicht. Und ich hab nichts zum Testen

Aufgehoben wäre das ganze am besten in der 00_TUL. Ich würde nicht an den bestehenden Zeilen rumschrauben, sondern ein zusätzliches Device anlegen, und die aufrufenden Methoden verändern.

Durchsuch doch bitte mal die 00_TUL. Suche nach "TPUART" vs. "EIBD". Sinngemäß gehört dann noch ein TPUART_RF mit dazu...

Grüße, Andi