Vom RAW zum device

Begonnen von VolkerGBenner, 07 Dezember 2018, 14:12:09

Vorheriges Thema - Nächstes Thema

VolkerGBenner

Hallo,
ich habe meinem CUL 433Mhz mal ein paar ältere Funksteckdosen bzw. deren Handsender zu schmecken gegeben. Im Log bekomme darauf z.B. folgende Einträge
2018.12.07 13:55:08 4: CUL_Parse: buswareCUL omAAAAA012
2018.12.07 13:55:08 5: buswareCUL: dispatch omAAAAA012
2018.12.07 13:55:08 5: CUL_REDIRECT (mAAAAA012) length: 9 RSSI: -65
2018.12.07 13:55:08 5: CUL_REDIRECT (mAAAAA012) match Manchester COODE length: 9
2018.12.07 13:55:08 5: CUL_REDIRECT decode Oregon 2 (AAAAA012)
2018.12.07 13:55:08 5: bitdata: 10101010101010101010000000010010
2018.12.07 13:55:08 5: CUL_REDIRECT decode Oregon 3 (AAAAA012)
2018.12.07 13:55:08 5: bitdata: 10101010101010101010000000010010
2018.12.07 13:55:08 5: CUL_REDIRECT decode Hideki (AAAAA012)
2018.12.07 13:55:08 5: buswareCUL: search in 10101010101010101010000000010010

2018.12.07 13:55:08 5: protocol does not match, ignore received package (AAAAA012) Reason: Not a hideki protocol
2018.12.07 13:55:09 5: CUL/RAW: /omAAAAA013

2018.12.07 13:55:09 4: CUL_Parse: buswareCUL omAAAAA013
2018.12.07 13:55:09 5: buswareCUL: dispatch omAAAAA013
2018.12.07 13:55:09 5: CUL_REDIRECT (mAAAAA013) length: 9 RSSI: -64.5
2018.12.07 13:55:09 5: CUL_REDIRECT (mAAAAA013) match Manchester COODE length: 9
2018.12.07 13:55:09 5: CUL_REDIRECT decode Oregon 2 (AAAAA013)
2018.12.07 13:55:09 5: bitdata: 10101010101010101010000000010011
2018.12.07 13:55:09 5: CUL_REDIRECT decode Oregon 3 (AAAAA013)
2018.12.07 13:55:09 5: bitdata: 10101010101010101010000000010011
2018.12.07 13:55:09 5: CUL_REDIRECT decode Hideki (AAAAA013)
2018.12.07 13:55:09 5: buswareCUL: search in 10101010101010101010000000010011

2018.12.07 13:55:09 5: protocol does not match, ignore received package (AAAAA013) Reason: Not a hideki protocol
2018.12.07 13:55:45 5: CUL/RAW: /omAAA6A02A

2018.12.07 13:55:45 4: CUL_Parse: buswareCUL omAAA6A02A
2018.12.07 13:55:45 5: buswareCUL: dispatch omAAA6A02A
2018.12.07 13:55:45 5: CUL_REDIRECT (mAAA6A02A) length: 9 RSSI: -53
2018.12.07 13:55:45 5: CUL_REDIRECT (mAAA6A02A) match Manchester COODE length: 9
2018.12.07 13:55:45 5: CUL_REDIRECT decode Oregon 2 (AAA6A02A)
2018.12.07 13:55:45 5: bitdata: 10101010101001101010000000101010
2018.12.07 13:55:45 5: CUL_REDIRECT decode Oregon 3 (AAA6A02A)
2018.12.07 13:55:45 5: bitdata: 10101010101001101010000000101010
2018.12.07 13:55:45 5: CUL_REDIRECT decode Hideki (AAA6A02A)
2018.12.07 13:55:45 5: buswareCUL: search in 10101010101001101010000000101010

2018.12.07 13:55:45 5: protocol does not match, ignore received package (AAA6A02A) Reason: Not a hideki protocol


Wie kann ich daraus ein device erstellen? Was ist da die Vorgehensweise?
Muss ich mir da ein eigenes Modul erstellen oder kann es reichen ein bestehendes zu erweitern.

Die Steckdosen waren (glaub ich) von Lidl und es steht Globaltronics drauf. Model GT-7000 (2007). Sie sind optisch identisch mit Quigg DMV-7009 AS.


1x  RasPiB3+  mit RPI-RF-MOD und piccu3
1x HM-TC-IT-WM-W-EU, 1x HM-CC-RT-DN, 1xHM-SEC-SCo,
HM-LC-Sw4-DR, HM-WDS30-OT2-SM, HM-Dis-WM55, 7x HmIP-eTRV-B,

rudolfkoenig

Da die Daten mit o am Anfang gemeldet werden, landen sie im CUL_REDIRECT Modul.
Wie von da aus weitergeht, kann ich es nicht sagen.

Prinzipelles Vorgehen bei zweistufigen Modulen:
- im IO-Modul (z.Bsp. 00_CUL.pm) ist eine Liste von moeglichen Clients konfiguriert ($hash->{Clients})
- in jedem Client (z.Bsp. 10_FS20.pm) ist eine Regexp definiert, was dieses Client versteht ($hash->{Match})
- das IO-Modul gibt die empfangenen (RAW) Daten an die globale Dispatch Funktion weiter, die die ParseFn des "passenden" Clients aufruft, d.h. falls Match passt.