Fehlerhafte Implementierung TFA 47.3003 Funk-Regenmess-Station "Monsun"

Begonnen von Heinzelmann, 14 März 2018, 23:10:30

Vorheriges Thema - Nächstes Thema

Heinzelmann

Hallo zusammen,

ich habe mir die TFA Funk-Regenmesser ,,Monsun" 47.3003 gekauft und habe bislang die Daten erfolgreich mit einem Signalduino (nano mit CC1101 Chip) in FHEM eingelesen. Das hat soweit alles gut funktioniert. Die Signale wurden automatisch erkannt (als KW9010 mit dem Modul CUL_TCM97001).

Eigentlich ist die Empfangsstation eine TFA Dorstmann KW9015

Die KW9010 misst Temperatur und Feuchtigkeit, die KW 9015 misst Temperatur und Niederschlagsmenge.


Der Regenmesser besteht aus einem Temperatursensor und einer Wippe. Jeder Ausschlag der Wippe erhöht die Humidity um 1. Der Temperaturwert wurde sofort richtig ausgewertet.

Man konnte sich also in FHEM einen Deltawert berechnen lassen den man mit dem Volumen der Wippe multiplizierte um sich die Niederschlagsmenge in mm plotten zu lassen. TOP

Das Problem begann nun als der Wert für Humidity von 99 auf 100 gestiegen ist. Das Modul akzeptiert nämlich keine Werte für Humidity größer als 99 (macht ja auch keinen Sinn, denn der Wert wird ja "eigentlich" als relative Feuchte benutzt). Es werden seitdem keinerlei valide Werte von der Funkstation empfangen, ich denke sie werden einfach verworfen, da der Wertebereich für Humidity überschritten wurde, man kann das im Logfile auch gut nachvollziehen...

Wie kann ich jetzt für Humidity Werte größer als 99 erlauben? Kann ich das selber verändern oder muss ich mich an einen Entwickler wenden?

Danke und mit freundlichen Grüßen, Hannes

Heinzelmann

Hallo zusammen,

ich habe diesen Thread mal nach "Sonstiges" verschoben, da ich den Hinweis bekommen habe, dass die Fehlerbeschreibung hier besser aufgehoben ist.

Mit freundlichen Grüßen, Hannes

arneman

Hi,

ich habe ebenfalls eine tfa 47.3003. Die Signale werden durch einen SIGNALduino empfangen.

Bei mir laufen die Signale in ein Device "Unknown" vom Typ CUL_TCM97001.

Ich erhalte einen State der z.B. so aussieht: "Code: 700B30EAC0" - diesen habe ich (mit etwas Aufwand) enkodiert.

Vorgehensweise:

  • Hex Code (z.B. 700B30EAC0) in Binär wandeln
  • Binären Code umdrehen (reverse). Also 1. Zeichen ist danach das letzte Zeichen etc.

Die Temperatur steckt dann in Stelle 17-28 (Hex zu Dezimal). Die Dezimalstelle muss noch um 1 verschoben werden (=> /10). Negative Temperatur Werte werden allerdings als Differenz zum maximal ausdrückbaren Wert übermittelt (siehe Beispiele in angehängter Text Datei).

Die Regenwerte sind in Stelle 8-16 (Hex zu Dezimal). Es handelt sich um eine hochzählende Zahl, die je Einheit 0,45 mm Regen entspricht. Ich vermute, dass es nach 255 wieder bei 0 weitergeht.

Sicherlich stecken irgendwo auch noch Batteriestand Informationen und evtl. gibts auch noch eine Checksumme.

Ich habe mir folgende Routine geschrieben (eher zum Debuggen), die mittels Notify auf das Unkown Device angetriggert werden kann.

sub tfa473003_decode {
  sub tfa473003_decode {
  my $device = shift;  #device that should store the readings
  my $code = shift;    #the current code
 
  my $only_id = ReadingsVal($device,"id",undef);
  my $debug = ReadingsVal($device,"debug",0);
 
  if($debug)
  {
    Log 3, "tfa473003, device: $device, code: $code";
  }
 
  #extract code
  $code = substr($code,6);
 
  #continue only if code has 10 digits
  if(length($code) != 10) { return; }
 
  #convert hex to bin
  # sprintf has issues with large numbers, split into 2 parts
  my $code_bin_0 = sprintf( "%b", hex( substr($code,0,5) ) );
  my $code_bin_1 = sprintf( "%b", hex( substr($code,5) ) );
  my $code_bin = substr("00000000000000000000$code_bin_0",-20); #add leading zeros
  $code_bin .= substr("00000000000000000000$code_bin_1",-20); #add leading zeros
 
  #reverse bin code
  my $code_bin_rev = reverse($code_bin);
 
  #crc check
  my $crc = 0;
  my $crc_signal = substr($code_bin_rev,4,4);
  foreach my $i (2 .. 9) {
     my $part = oct("0b".substr($code_bin_rev,$i*4,4)); #extract binary block
$crc += $part;
  }
  $crc = sprintf ("%b", $crc); #bin to dec
  $crc = substr($crc,-4); #only the last 4 digits matters
  if($crc != $crc_signal) {
    Log 3, "tfa473003, device: $device, ERROR: CRC is wrong! crc_signal: $crc_signal, crc: $crc";
return;
  }
 
  #id
  my $id_bin = substr($code_bin_rev,36,4); #32,8 28,12
  my $id_dec = oct("0b$id_bin");
  if(!defined($only_id) && $debug)
  {
    Log 3, "tfa473003, device: $device, device_id: $id_dec, ('setreading $device id $id_dec' if you want to ignore all other devices) ";
  }

  #continue only if only_id is equal to current id (if set)
  if (defined($only_id) && $only_id ne $id_dec) {
    if ($debug) { Log 3, "tfa473003, id wrong, is $id_dec ($id_bin), should be $only_id"; }
return;   
  }
 
  #temp (17-28)
  my $temp_bin = substr($code_bin_rev,17,11);
  my $temp_dec = oct("0b$temp_bin");
  if (substr($code_bin_rev,16,1) eq "1" )  #negativ values
  {
  $temp_dec = (2048-$temp_dec)*-1;
  }
  $temp_dec /= 10; #decimal point
   
  #rain (8-16)
  my $rain_bin = substr($code_bin_rev,8,8);
  my $rain_dec = oct("0b$rain_bin");
  #calc difference to last value
  my $rain_dec_old = ReadingsVal($device,"rain_count",$rain_dec);
  my $rain_diff = $rain_dec - $rain_dec_old;
  if ($rain_diff < 0) { $rain_diff += 255 + 1 ; } #handle overflow
  #convert to mm
  my $rain_mm = $rain_diff * 0.45;
  my $rain_mm_old = ReadingsVal($device,"rain_mm",0);
  my $rain_mm_sum = $rain_mm+$rain_mm_old;
 
 
  #store results
  my $cmd = 'sleep 0.01;'; #without "sleep 0.01" readings wont be logged
  if($debug)
  {
    $cmd .= "setreading $device code_bin $code_bin;";
    $cmd .= "setreading $device code_bin_rev $code_bin_rev;";
    $cmd .= "setreading $device id_bin $id_bin;";
    $cmd .= "setreading $device temp_bin $temp_bin;";
    $cmd .= "setreading $device rain_bin $rain_bin;";
    $cmd .= "setreading $device rain_diff $rain_diff;";
  }
 
  $cmd .= "setreading $device id_dec $id_dec;";
  if (!$rain_diff) { $cmd .= "setreading $device temp $temp_dec;"; } #avoid wrong temps, same behavior like display
  $cmd .= "setreading $device rain_count $rain_dec;";
  $cmd .= "setreading $device rain_mm $rain_mm_sum;";

  fhem($cmd);
}


Ich habe mir ein Dummy angelegt, in dem die Werte gespeichert werden sollen. Das Reading "debug" kann 1 oder 0 sein und schaltet das ausführliche logging ein. Das reading "id" enthält die zu berücksichtigende ID (des regenmessers). Am besten am Anfang nicht setzen, debug einschalten und dann die richtige id aus dem reading "id_dec" entnehmen (und mittels "setreading Regenmesser_tfa id xxx" setzen)
define Regenmesser_tfa dummy
attr Regenmesser_tfa event-on-change-reading .*
attr Regenmesser_tfa group Regenmesser
attr Regenmesser_tfa icon weather_rain_gauge
attr Regenmesser_tfa room Außen
attr Regenmesser_tfa stateFormat rain_mm_quarterhour mm, temp°
setstate Regenmesser_tfa 2018-06-17 16:40:15 debug 0
setstate Regenmesser_tfa 2018-06-17 12:20:22 id 14


Notify, das bei einer Änderung in Unknown die Decodierung und Speicherung im zuvor angelegten Dummy anstößt
define Notify_Regenmesser notify (Unknown:Code.*) { tfa473003_decode("Regenmesser_tfa",$EVENT) }

EDIT: 25.08.2018:
Zeile:
my $id_bin = substr($code_bin_rev,28,12);
geändert zu:
my $id_bin = substr($code_bin_rev,32,8); #28,12

EDIT: 07.05.2019:
Zeile:
my $id_bin = substr($code_bin_rev,32,8); #28,12
geändert zu:
my $id_bin = substr($code_bin_rev,36,4); #32,8 28,12

Umwandlung zu binär nun 1 Schritten (da manchmal Überlauf)

EDIT: 12.10.2019:
Hinzu: Debug Ausgabe der ID des Signals im FHEM Log
Hinzu: CRC Check

Heinzelmann


arneman

Ich habe gerade noch eine Änderung eingefügt. Die ID der Station ist wohl nur 8 Bit, nicht 12. Also my $id_bin = substr($code_bin_rev,32,8); #28,12

Heinzelmann

#5
Da ich bei mir zwischendurch ein paar Übertragungsfehler hatte, habe ich mich mal an die CRC Prüfung gemacht.
Sie funktioniert (analog zu dem KW9010) wie im Excel beschrieben. Mit deinen Beispieldaten kommt das alles hin...

Ich kann leider nicht ordentlich programmieren. Kann man das irgendwie aus dem Code vom KW9010 übernehmen?

Mit freundlichen Grüßen, Hannes

arneman

Zitat von: Heinzelmann am 26 August 2018, 15:14:07
Da ich bei mir zwischendurch ein paar Übertragungsfehler hatte, habe ich mich mal an die CRC Prüfung gemacht.
Sie funktioniert (analog zu dem KW9010) wie im Excel beschrieben. Mit deinen Beispieldaten kommt das alles hin...

Ich kann leider nicht ordentlich programmieren. Kann man das irgendwie aus dem Code vom KW9010 übernehmen?

Mit freundlichen Grüßen, Hannes

Done - Endlich mal Urlaub ;)

Ralf9

Zitat von: heigu am 13 Juli 2020, 16:37:33
Wertes Forum,

Wie sieht es mit der Unterstützung des TFA 30.3161 (Regensensor + Temperatur) aus?

Ich versuche die Werte über den Signalduino in FHEM zu empfangen. Dabei wird der TFA 30.3161 als CUL_TCM97001 eingeordnet und dann abwechselnd mal als AURIOL_240 oder als Unknown erkannt. Der TFA 30.3161 steht testweise direkt neben dem Empfänger, also sind Übertragungsprobleme eher unwahrscheinlich.

Der TFA 30.3161 wird schon an verschiedener Stellen erwähnt:

Wenn ich das nun richtig interpretiere, ist der TFA 30.3161 sowohl im Signalduino als auch im CUL_TCM97001 Code enthalten, funktioniert aber bei mir nicht korrekt.

Stimmt diese Interpretation?

Was kann ich tun bzw. wem kann ich helfen das zu ändern?

Gruß,
heigu
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

ZitatWenn ich das nun richtig interpretiere, ist der TFA 30.3161 sowohl im Signalduino als auch im CUL_TCM97001 Code enthalten, funktioniert aber bei mir nicht korrekt.
Im CUL_TCM97001 ist nur der KW9010 enthalten, der KW9015 fehlt noch.

ZitatWas kann ich tun bzw. wem kann ich helfen das zu ändern?
Du kannst helfen, wenn Du hier raw Nachrichten postet, sie sehen ungefähr so aus:
2020.07.14 16:56:13.625 4 : sduino/msg: MS;P0=-3733;P1=481;P2=-1967;P3=-9046;D=13101012101212101212121212101010121210121210121212121212121212121210121210;CP=1;SP=3;
2020.07.14 16:56:13.625 4 : sduino: Decoded MS Protocol id 0.3 dmsg sD20E48009000 length 40


Wenn Du auch die Station hast, kannst Du auch die Temperatur dazu schreiben.

Interessant sind auch raw Nachrichten von einem Batteriewechsel, gedrückter Tx Taste und mit fast leeren Batterien.

Ich habe mal hier angefangen den KW9015 einzubauen
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm

Es passt noch nicht ganz, es muß noch verbessert und optimiert werden.
Der KW9015 wird noch als KW9010 erkannt, das Atribut model muß dann in KW9015 geändert werden.

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

heigu

Hallo Ralf9, wertes Forum,

danke Ralf9 für Deine Vorarbeit. In der Anlage habe ich 30 Nachrichten vom TFA 30.3161 angehängt. Ich habe leider keine Basisstation und kann so nicht die exakte Ausgabe mitschreiben.
Rahmenbedingungen:

  • Batterien neu
  • Bei Beginn der Aufzeichnung wurden die Batterien eingelegt
  • Keine Wippenbetätigung während der gesamten Aufzeichnung
  • Umgebungstemperatur laut anderen Thermometer bei 22.4°C

Ich hoffe das hilft schon mal weiter. Ich werde später noch Aufzeichnungen mit Wippenbetätigung machen. Bzw. was gewünscht wird.

Gruß,
heigu
Raspberry 3B, Fedora & Docker
FHEM in Docker, SIGNALduino (Nano + c1101), Viessmann Optolink, Shelly 3EM
InfluxDB, Grafana

heigu

Wertes Forum,

hier ist nun der zweite Teil meiner Messreihe für heute:


  • TFA 30.3161 ist seit der ersten Messreihe durchgelaufen, FHEM nicht (deshalb der niedrige Nachrichtenzähler)
  • Nach den ersten beiden Nachrichten wurde die Wippe immer nach zwei Nachrichten betätigt
  • Es wurde immer ein Wippenschlag ausgeführt
  • Neue Position der Wippe ist in der Datei vermerkt
  • Umgebungstemperatur laut anderen Thermometer beginnend bei 22.4°C und enden bei 22.8°C
  • Ich habe leider keine Basisstation und kann so nicht die exakte Ausgabe mitschreiben

Gruß,
heigu
Raspberry 3B, Fedora & Docker
FHEM in Docker, SIGNALduino (Nano + c1101), Viessmann Optolink, Shelly 3EM
InfluxDB, Grafana

Ralf9

Danke, damit kann ich den KW9015 (TFA 30.3161)  ins CUL_TCM97001 einbauen.
So wies aussieht ist beim KW9015 der Kanal immer 0, damit kann ich eine Unterscheidung zwischen KW9010 und KW9015 einbauen.

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

heigu

Hallo Ralf,

vielen Dank für den Einbau!

Ich habe meinen TFA 30.3161 gerade nochmal auseinander genommen. Ich finde keine Möglichkeit den Kanal zu ändern (keine Codierschalter oder ähnliches auf der Platine vorhanden). Der Kanal scheint fest vergeben zu sein.

Gruß,
heigu
Raspberry 3B, Fedora & Docker
FHEM in Docker, SIGNALduino (Nano + c1101), Viessmann Optolink, Shelly 3EM
InfluxDB, Grafana

Mexx13

Hallo, wie weit funktioniert es mit dem TFA 30.3161 jz bei euch?
Bei mir wird nämlich überhaupt nichts angezeigt.
Lg  :)
Fronius Gen24 8.0 Plus, BYD HVM 11.0, Ochner Europa 333 Genius, USR W630 Modbus RTU to TCP, Fritzbox
Raspberry PI, DB-Log, Open-VPN, Jeelink-LaCrosse, Signalduino-WH1080, Busware SCC, CUL 868MHz -Homematic, ESP8266,...

Ralf9

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