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
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
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
Es funktioniert!
Vielen Dank...
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
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
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 ;)
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:
- https://github.com/RFD-FHEM/RFFHEM/issues/166 (https://github.com/RFD-FHEM/RFFHEM/issues/166)
- https://forum.fhem.de/index.php?topic=85746.0 (https://forum.fhem.de/index.php?topic=85746.0): verweist auf TFA 47.3003, wenn ich das richtig interpretiere ist TFA 47.3003 die Station zum TFA 30.3161 Sensor
- https://github.com/fhem/fhem-mirror/blob/31fb56726380da3689b2badedbec8a26ae51b7bb/fhem/FHEM/14_CUL_TCM97001.pm (https://github.com/fhem/fhem-mirror/blob/31fb56726380da3689b2badedbec8a26ae51b7bb/fhem/FHEM/14_CUL_TCM97001.pm): Zeile 40
- https://forum.fhem.de/index.php?topic=53554.0 (https://forum.fhem.de/index.php?topic=53554.0)
- https://forum.fhem.de/index.php/topic,58397.msg679875.html#msg679875 (https://forum.fhem.de/index.php/topic,58397.msg679875.html#msg679875)
- Andere Baustelle, aber ggf. interessant: https://github.com/merbanan/rtl_433/blob/c13d53e767461aab7ccdd9b1de5476571bc7b8cf/README.md (https://github.com/merbanan/rtl_433/blob/c13d53e767461aab7ccdd9b1de5476571bc7b8cf/README.md)
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
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 40Wenn 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
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
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
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
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
Hallo, wie weit funktioniert es mit dem TFA 30.3161 jz bei euch?
Bei mir wird nämlich überhaupt nichts angezeigt.
Lg :)
siehe hier
https://forum.fhem.de/index.php/topic,101425.msg1081660.html#msg1081660
Gruß Ralf