Wie TFA Drop Regenmesser anbinden?

Begonnen von sido, 01 Februar 2020, 23:29:12

Vorheriges Thema - Nächstes Thema

sido

Hallo,
ich habe einen Drop Regenmesser von TFA.
Daten empfange ich mit meinem nanoCUL 433 sowohl mit der culfw, als auch mit der SignalDuino Firmware.
Standardmäßig wird der Regenmesser jedoch nicht von FHEM erkannt.
Auf der Seite https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle habe ich mich schon schlau gelesen und tatsächlich den Link zu einer genauen Protokollbeschreibung des Sensors und Implementierung in C gefunden:
https://github.com/merbanan/rtl_433/blob/master/src/devices/tfa_drop_30.3233.c
Wie gehe ich aber nun weiter vor, um den Sensor in FHEM verfügbar zu machen? Programmieren kann ich eigentlich...
Kann mir jemand den entscheidenden Hinweis geben?
Gruß,
Sido

Ralf9

Bitte verschiebe dieses Thama nach Sonstige Systeme, da passt es besser hin,
und poste einige RAW-Nachrichten vom Signalduino (verbose 4 reicht)

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sido

Hallo Ralf,
das Protokoll sollte ja nicht das Problem sein, da es in dem Link, den ich gepostet hatte, ja komplett beschrieben ist. Hier trotzdem ein Auszug:

2020.02.02 10:58:51 4: mySduino: Read, msg READredu: MU;P0=-30220;P1=247;P2=-750;P3=722;P4=-489;P5=491;P6=-236;P7=-2184;D=01232141456565656145656141456565614141456141414145656141414141456561414141456561414145614561456145614141414141414145614145656145614141732321414565656561456561414565656141414561414141456561414141414565614141414565614141456145614561456141414141414141456141;CP=1;R=55;O;
2020.02.02 10:58:52 4: mySduino: Read, msg READredu: MS;P0=-251;P1=481;P2=236;P3=-495;P4=-2176;P5=752;P6=-714;D=245656232310101010231010232310101023232323102310231023102323232323232323102323101023102323;CP=2;SP=4;R=51;O;m2;
2020.02.02 10:58:52 4: mySduino: Read, msg READredu: MU;P0=-251;P1=481;P2=236;P3=-487;P4=-2176;P5=752;P6=-714;D=245656232310101010231010232310101023232310232323231010232323232310102323232310102323231023102310231023232323;CP=2;R=51;
2020.02.02 10:58:52 4: mySduino: Read, msg READredu: MU;P0=-484;P1=493;P2=-241;P3=252;D=0121230303030121230303012301230123012303030303030303012303012123012303030;CP=3;R=54;
2020.02.02 10:58:52 4: mySduino: Read, msg READredu: MU;P0=-241;P1=493;P2=252;P3=-484;D=01023232323101023232310231023102310232323232323232310232310102310232323;CP=2;R=53;
2020.02.02 10:58:52 4: mySduino: Read, msg READredu: MU;P0=-1668;P1=242;P2=-496;P3=506;P4=-222;D=012341234121214341234341212343434121212341212121234341212121212343412121212343412121234123412341234121212121212121234121234341234121212;CP=1;R=55;
2020.02.02 10:59:36 4: mySduino: Read, msg READredu: MU;P0=130;P1=-497;P2=-251;P3=-11512;P4=243;P5=-730;P6=728;P7=481;D=01020345654141727272724172724141727272414141724141414172724141414172414141414141727241414172417241724172414141414141414172724141414141724141;CP=4;R=53;
2020.02.02 10:59:36 4: mySduino: Read, msg READredu: MU;P0=-1664;P1=257;P2=-473;P3=483;P4=-244;D=012341234121212121212121234341212121212341212;CP=1;R=52;
2020.02.02 10:59:36 4: mySduino: Read, msg READredu: MU;P0=-473;P1=483;P2=-244;P3=257;D=012303030303030121230303012301230123012303030303030303012123030303030123030;CP=3;R=54;
2020.02.02 10:59:36 4: mySduino: Read, msg READredu: MU;P0=-1672;P1=255;P2=-481;P3=501;P4=-238;D=012341234121212341234341212343434121212341212121234341212121234121212121212343412121234123412341234121212121212121234341212121212341212;CP=1;R=54;
2020.02.02 10:59:38 4: mySduino: Read, msg READredu: MU;P0=-1676;P1=248;P2=-489;P3=492;P4=-238;P5=-2188;P6=742;P7=-722;D=01234123412121212121212123434121212121234121212123434121212123412121212121234341212123412341234123412121212121212123434121212121234121567671212343434341234341212343434121212341212121234341212121234121212121212343412121234123412341234121212121212121234341;CP=1;R=54;O;
2020.02.02 10:59:38 4: mySduino: KeepAlive, ok, retry = 0

Es kann allerdings sein, dass hier in dem Protokoll noch mehr auf der 433er Frequenz unterwegs ist...
Ich würde gerne wissen, in welcher Source-Datei des SignalDuino Source-Codes ich das Protokoll aus der C-Datei implementieren würde...

Gruß,
Sido

Ralf9

Ich habe mir die RAW-Nachrichten mal angeschaut, so wies aussieht ist das ein noch unbekanntes Protokoll.
Als nächstes muss dann in der Protokollliste eine neue Protokolldefinition mit der ID 98 angelegt werden
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r34/FHEM/lib/SD_ProtocolData.pm

Dann wird die RAW-Nachricht in eine HEX Ziffernfolge gewandelt, z.B. u98#12345678..

Dann muß geschaut werden, ob dies in ein vorhandene Modul mit reinpasst oder ob ein neues Modul benötigt wird.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

#4
Ich habe mal eine neue Protocoll ID 98 54 erstellt:
"54" =>
{
name         => 'Drop TFA Rain',
id           => '54',
one          => [2,-1],
zero         => [1,-2],
start        => [3,-3],
clockabs     => 250,
format       => 'twostate',
preamble     => 'u54#',
},

Dies muss in die /FHEM/lib/SD_ProtocolData.pm eingefügt werden und dann ein fhem restart

Das ergibt dann
2020.02.02 12:16:18.636 4 : sduinoD/msg get raw: MU;P1=247;P2=-750;P3=722;P4=-489;P5=491;P6=-236;P7=-2184;D=1232141456565656145656141456565614141456141414145656141414141456561414141456561414145614561456145614141414141414145614145656145614141732321414565656561456561414565656141414561414141456561414141414565614141414565614141456145614561456141414141414141456141;CP=1;R=55;O;
2020.02.02 12:16:18.636 4 : sduinoD: Fingerprint for MU Protocol id 54-> Drop TFA Rain matches, trying to demodulate
2020.02.02 12:16:18.637 5 : sduinoD: dispatching bits: 001111011001110001000011000001100001100010101010000000010000 with anzPadding=3
2020.02.02 12:16:18.637 4 : sduinoD: decoded matched MU Protocol id 54 dmsg u98#3D9C430618AA010 length 57 RSSI = -46.5
2020-02-02 12:16:18.643 SIGNALduino sduinoD DMSG u54#3D9C430618AA010
2020.02.02 12:16:18.643 4 : sduinoD Dispatch: u54#3D9C430618AA010, -46.5 dB, dispatch



Edit:
Zitatstart        => [3,-3,3,-3],
damit es auch bei nicht so guten Empfangsverhältnissen funktioniert, ist es besser als start [3,-3] zu verwenden



FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sido

Hallo Ralf,
cool, danke. Jetzt kommt folgendes:

2020.02.02 14:00:23 4: Unknown, please report
2020.02.02 14:00:23 3: mySduino: Unknown code u98#3D9C430A1BAA01898, help me!
2020.02.02 14:00:23 4: mySduino: Read, msg READredu: MU;P0=-1656;P1=744;P2=-728;P3=258;P4=-474;P5=511;P6=-220;P7=-164;D=01212343456565656345656343456565634343456343434345656343437;CP=3;R=4;
2020.02.02 14:00:23 4: mySduino: Parse_MU, Fingerprint for MU Protocol id 98 -> Drop TFA Rain matches, trying to demodulate
2020.02.02 14:00:23 4: mySduino: Parse_MU, Decoded matched MU Protocol id 98 dmsg u98#3D9C430 length 28 dispatch(1/4) RSSI = -72
2020.02.02 14:00:23 4: SIGNALduino_unknown incomming msg: u98#3D9C430
2020.02.02 14:00:23 4: SIGNALduino_unknown rawData: 3D9C430
2020.02.02 14:00:23 4: SIGNALduino_unknown Protocol: 98
2020.02.02 14:00:23 4: SIGNALduino_unknown converted to bits: 0011110110011100010000110000
2020.02.02 14:00:23 4: SIGNALduino_unknown mySduino Protocol:98 | To help decode or debug, please add u98! (attr mySduino development u98)
2020.02.02 14:00:23 4: Unknown, please report


Wie soll ich nun weitermachen?

sido

Habe gerade nochmal in den C-Code, der oben verlinkt ist, geschaut. Die Nachricht muss wohl 68 Bits lang sein. Hier ist mal so eine:

2020.02.02 14:00:23 3: mySduino: Unknown code u98#3D8, help me!
2020.02.02 14:00:23 4: mySduino: Read, msg READredu: MU;P0=-1672;P1=740;P2=-724;P3=260;P4=-468;P5=504;P6=-230;D=012123434565656563456563434565656343434563434343456563434343456345634343434565634565656345634563456343434343434343456563434345634345656;CP=3;R=4;
2020.02.02 14:00:23 4: mySduino: Parse_MU, Fingerprint for MU Protocol id 98 -> Drop TFA Rain matches, trying to demodulate
2020.02.02 14:00:23 4: mySduino: Parse_MU, Decoded matched MU Protocol id 98 dmsg u98#3D9C430A1BAA01898 length 68 dispatch(1/4) RSSI = -72
2020.02.02 14:00:23 4: SIGNALduino_unknown incomming msg: u98#3D9C430A1BAA01898
2020.02.02 14:00:23 4: SIGNALduino_unknown rawData: 3D9C430A1BAA01898
2020.02.02 14:00:23 4: SIGNALduino_unknown Protocol: 98
2020.02.02 14:00:23 4: SIGNALduino_unknown converted to bits: 00111101100111000100001100001010000110111010101000000001100010011000
2020.02.02 14:00:23 4: SIGNALduino_unknown mySduino Protocol:98 | To help decode or debug, please add u98! (attr mySduino development u98)
2020.02.02 14:00:23 4: Unknown, please report

Ralf9

Mir fällt gerade kein Modul ein wo dies so richtig reinpasst.

Die Frage reiche ich an Sidey, elektron-bbs und HomeAuto_User weiter.
Liest Ihr hier mit?
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

elektron-bbs

Zur Zeit gehen die Daten in das Modul "90_SIGNALduino_un.pm". Es müsste auch schon ein Gerät "SIGNALduino_unknown_98" angelegt worden sein.
Dort kannst du ja auch schon mal kontrollieren, welche Daten empfangen werden. Die Nachrichten scheinen relativ oft "verstümmelt" zu sein. Sicher muss in der "SD_ProtocolData.pm" noch "length_min" und "length_max" angepasst werden.

Ich denke, das Protokoll passt dann letztendlich auch ins Modul "14_SD_WS.pm".
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

sido

Hallo elektron-bbs!
Super, das hilft mir schon enorm weiter. Ist ja wirklich sehr elegant gemacht, das Ganze mit SignalDuino.
Habe jetzt length_min auf 56 und length_max auf 68 gesetzt. Somit bekomme ich immer die Werte für den Regen.
Hast du schon in den C-Code geschaut, der oben verlinkt ist? Da ist das Protokoll ja recht klar beschrieben.
Ich werde jetzt erst mal versuchen, es so im Modul "90_SIGNALduino_un.pm" zu implementieren.
Gruß.
Sido

elektron-bbs

#10
Die Umsetzung sollte eigentlich kein Problem darstellen. Die Checksum kann ich nicht deuten:
Compute with reverse Galois LFSR with byte reflection, Generator 0x31 and key 0xf4
Ist das CRC8?

length_min auf 56 mag für die ersten Tests reichen, aber den Check würde ich für die endgültige Version schon mitnehmen.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

sido

Hier:
https://en.wikipedia.org/wiki/Linear-feedback_shift_register#Galois_LFSRs
Du meinst die Checksum-Berechnung sollte man final nicht weglassen, damit man prüfen kann, ob alles korrekt übertragen ist?

elektron-bbs

Auf jeden Fall, sonst wunderst du dich irgendwann über unplausible Readings. Bitfehler sind bei Funkübertragungen nicht selten.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

sido

Hallo elektron-bbs,
versuche mich gerade an der Prüfsummenberechnung. Ist hier in C definiert, falls du mal reinschauen magst (ist "lfsr_digest8_reflect"):
https://github.com/merbanan/rtl_433/blob/master/src/util.c
Komme mit der Parameterübergabe an die Perl sub noch nicht so ganz klar, aber wird schon...
Habe übrigens das Problem, dass mein SIGNALduino öfter mal vom STATE opened auf closed wechselt. Das passiert mir sowohl mit Version 3.3.1, als auch mit 3.4.0-dev. Weißt du woran das liegen kann?
Gruß,
Sido

elektron-bbs

Tja, es kann viele Ursachen geben, warum der SIGNALduino manchmal auf closed wechselt Ich habe z.B. die Erfahrung gesammelt, das man ihn mit zu langen oder fehlerhaften Sendebefehlen "abschießen" kann. Schlechte Stromversorgung kann man auch nie ausschließen.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway