[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen

[Ralf9]

Hier ist die aktuelle Version meiner modifizierten 14_CUL_TCM97001.pm

Ein update kann gemacht werden mit:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/master/fhem/controls_ralf9_CUL_TCM97001.txt

oder,
die 14_CUL_TCM97001.pm ins FHEM Verzeichnis kopieren
https://github.com/Ralf9/14_CUL_TCM97001/blob/master/fhem/FHEM/14_CUL_TCM97001.pm
und dann FHEM neustarten

Version ergibt dann:
14_CUL_TCM97001.pm 18358 2021-01-10 10:00:00Z Ralf9

changed:
10.01.2021
- Beim Model NC_WS Battery gefixt
28.08.2020
- update KW9010 and KW9015
15.07.2020
- KW9015 (TFA 30.3161) zugefügt
30.11.2019
- Auriol Z31743B zugefügt
27.11.2019
- Es gibt nun für das Prologue Protokoll einen alternativen devicecode (DEF) bei dem als longID die 2. und 3. Ziffer verwendet wird.
- Der short ID support wurde vereinfacht.
14.11.2019
- "TCM218943" und "Auriol_IAN" zugefügt

Gruß Ralf

[Ralf9]

Hallo,

Ich möchte das hier nochmals hochholen, da dieser Bug immer noch in der 14_CUL_TCM97001 ist.
Funkthermometer zeigen nur noch 'other' an

Das Problem ist hier:

Code Auswählen Erweitern

$msgtype = "other";
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/14_CUL_TCM97001.pm#L1690

Code Auswählen Erweitern

   if ($hashumidity == TRUE) {
      $msgtypeH = "humidity";
      $valH = $humidity;
      $state="$state H: $valH";
      Log3 $name, 4, "$iodev: CUL_TCM97001 $msgtype $name $id3 T: $val H: $valH";
    } else {
      $msgtype = "other";
      Log3 $name, 4, "$iodev: CUL_TCM97001 $msgtype $name $id3";
      #Log3 $name, 4, "CUL_TCM97001 $msgtype $name $id3 ";
    }

Wenn man ein "$hastemperature" einführt, müsste man eigentlich auf $msgtype und $msgtypeH verzichten können

Code Auswählen Erweitern

if ($hastemperature == TRUE) {
       readingsBulkUpdate($def, "temperature", $val);
}
if ($hashumidity == TRUE) {
     readingsBulkUpdate($def, "humidity", $valH);
}




Bei diesem Patch hat sich noch ein weiterer Bug eingeschlichen
https://svn.fhem.de/trac/changeset/18090/trunk/fhem/FHEM/14_CUL_TCM97001.pm

Code Auswählen Erweitern

@@ -899,5 +933,6 @@
}
     
-    if (checkCRC($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "TCM21....")) {
+### inserted by pejonp 3.2.2018 Ventus W132/W044   
+   if (checksum_W155($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "W044" || $readedModel eq "W132")) {

Hallo,
weiss nicht, ob ich hier richtig bin.
Benötige Hilfe zum 14_CUL_TCM97001.pm

Und zwar hänge ich noch immer auf Version $Id: 14_CUL_TCM97001.pm 16274 2018-02-25 20:42:39Z bjoernh, da in neueren Versionen mein TCM (TCM21....) Sensor nicht mehr gelesen wird.

Da ist scheinbar seit dem Eintrag mit "### inserted by pejonp 3.2.2018 Ventus W132/W044 " irgendwas durcheinander, da ich seit dem kein "
$readedModel eq "TCM21...."" mehr finde.

Kann das geprüft werden?
Danke und Gruss

Das Problem dabei ist, daß der TCM21.... und der W155 die gleiche Prüfsummenberechnung haben.


Gruß Ralf

[Ralf9]

Falls sich niemand anders findet, werde ich versuchen es einzubauen.
Das mit dem other müsste ich hinbekommen, bei dem "TCM21...." kann ich Hilfe gebrauchen.

Gruß Ralf

[Ralf9]

ich habe mal angefangen und den "TCM21...." wieder eingebaut

https://github.com/Ralf9/fhem-mirror/commit/02a438a0e19ac657895afa0673af514296804419
https://raw.githubusercontent.com/Ralf9/fhem-mirror/master/fhem/FHEM/14_CUL_TCM97001.pm

Gruß Ralf

[Ralf9]

Mit diesem Commit:
https://github.com/Ralf9/fhem-mirror/commit/498bc0ceb88c53812da9ed62920d71e5b7cc6cdf
habe ich den Fehler mit dem reading other behoben.
Bei Temperatursensoren ohne Feuchtigkeit gibt es nun wieder das reading temperature anstatt other.
Ich habe auch das reading batteryState hinzugefügt.
Bei Temperatursensoren habe ich die log Ausgaben erweitert:

Code Auswählen Erweitern

2019.06.23 22:55:08.190 4 : sduinoD: CUL_TCM97001 W044_133 ID: 133 T: 20.2 H: 38 Bat: ok CH: 1

Mit diesem Commit:
https://github.com/Ralf9/fhem-mirror/commit/909907f9e013254ecce6004a1b597a7e2a16ad6f
funktioniert nun der Auriol Z31743B IAN 91838 auch wieder mit der aktuellen Version
Fix von hjode, die Readings für lastDay und LastHour werden nun auch neu gesetzt, wenn der Tag oder die Stunde wechselt.
https://forum.fhem.de/index.php/topic,81731.msg737994.html#msg737994

Liest hier jemand mit der einen PFR_130 hat?

Dies ist die angepasste Version:
https://raw.githubusercontent.com/Ralf9/fhem-mirror/master/fhem/FHEM/14_CUL_TCM97001.pm

Gruß Ralf

[Ralf9]

Die Anpassungen sind mittlerweile im fhem update (SVN).
https://svn.fhem.de/trac/changeset/19762/trunk

Gruß Ralf

[FrankL]

Nachdem ich bei mir den Windmesser W132 über SIGNALduino ins FHEM eingebunden habe, war ich zunächst begeistert über die problemlose Erkennung des Sensors und die regelmäßige Übermittlung der Daten. Bei genauerer Prüfung habe ich jedoch festgestellt, dass die Windrichtung bei mir nicht zutreffend ermittelt wird. Den Windrichtungsmesser habe ich beim Batterie einlegen zutreffend eingestellt (Norden ausgerichtet). Basierend darauf ergaben sich bei den tatsächlichen Windrichtungen folgende Ergebnisse:

Windrichtung  nanoCUL_DMSG     windDirection     ReadingwindDirectionText
(real)
N          s276E00000000        0               N
NE         s276F68008000        4               SE
E          s276EB4008000        3               E
SE         s276FC2008000        1               N
S          s276E5A008000        5               S
SW         s276F0E008000        7               W
W          s276EE1008000        0               N
NW         s276FB9004000        5               S

Ich denke, dass hier ein Fehler in Zeile 1038 der 14_CUL_TCM97001.pm liegt:

Code Auswählen Erweitern

$windDirection =  (hex($a[5]) >> 1) | (hex($a[4]) & 0x1);

Entsprechend dem Datenblatt http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf habe ich bei mir die Berechnung wie folgt korrigiert:

Code Auswählen Erweitern

$windgrad =  (hex($a[3]) & 0x1)+ ((hex($aReverse[4])*2) + (hex($aReverse[5]))*32) ;
$windDirection = int($windGrad/45);
Wenn dann noch in Zeile 1686

Code Auswählen Erweitern

readingsBulkUpdate($def, "windDirectionDegree", $windgrad);
aktiviert bzw. geändert wird, wird auch das entsprechende Reading mit der passenden Gradzahl gefüllt. In diesem Zusammenhang habe ich festgestellt, dass die Zeile 428 wie folgt angepasst werden muss, da die Nordrichtung doppelt erfasst, obwohl die W132 Norden immer mit 0 Grad und nicht mit 360 Grad ausgibt. Sicherheitshalber kann Norden noch als $winddir_nam[8] ergänzt werden. In jedem Fall müsste aber die Zeile 428 aber wie folgt korrigert werden.
Zeile 428 alt:

Code Auswählen Erweitern

my @winddir_name=("N","N","NE","E","SE","S","SW","W","NW");
Zeile 428 neu:

Code Auswählen Erweitern

my @winddir_name=("N","NE","E","SE","S","SW","W","NW","N");

Weiterhin denke ich, dass die Windgeschwindigkeiten bei Geschwindigkeiten über 3 m/s (entspricht Bitvalue > 15 * 0,2) falsch bzw zu niedrig berechnet werden. Allerdings habe ich keine Möglichkeit das praktisch zu testen. Ich habe hier das oben angebenene Datenblatt angeschaut. Demnach müssten folgende Zeilen meines Erachtens bei der Berechnung korrigiert werden:

Zeile 1022 alt:

Code Auswählen Erweitern

$windSpeed = (hex($aReverse[6]) + hex($aReverse[7])) * 0.2;
Zeile 1022 neu:

Code Auswählen Erweitern

$windSpeed = (hex($aReverse[6]) + hex($aReverse[7]) * 16) * 0.2;
Zeile 1037 alt:

Code Auswählen Erweitern

$windGuest = (hex($aReverse[6]) + hex($aReverse[7])) * 0.2;
Zeile 1037 neu:

Code Auswählen Erweitern

$windGuest = (hex($aReverse[6]) + hex($aReverse[7]) * 16) * 0.2;

In diesem Zusammenhang habe ich auch festgestellt, dass die Berechnung des rain in der Zeile 1053 zum W174-Regenmesser unzutreffend ist. Richtig wäre hier

Code Auswählen Erweitern

$rain = (hex($aReverse[4]) + hex($aReverse[5]) * 16 + hex($aReverse[6]) * 256 + hex($aReverse[7]) * 4096) * 0.25;
Da die Berechnung des W174-Regenmesser jedoch bereits in die Zeilen 852 bis 932 ausgelagert worden ist und auch das Modell W174 in der Abfrage zur Zeile 935 nicht mehr enthalten ist, könnten die Zeilen 1052 bis 1057 insgesamt entfernt werden.

Es wäre schön, wenn jemand mit dem gleichen Windmesser W132 die Fehler bestätigen könnte, damit die vorgeschlagenen Korrekturen generell in einem Update umgesetzt werden könnten. Bei mir läufts mit den vorgeschlagenen Korrekturen (insbesondere zur Windrichtung) jetzt fehlerfrei. Hinsichtlich der Windgeschwindigkeit warte ich auf den nächsten Sturm. 

[jochen.baur@web.de]

Hallo Frank,

ich hab die werte für
$windSpeed = (hex($aReverse[6]) + hex($aReverse[7]) * 16) * 0.2;
und
$windGuest = (hex($aReverse[6]) + hex($aReverse[7]) * 16) * 0.2;

von Dir übernommen. Werte sehen gut aus. Aktuell geht leider nur leichter wind um zu sehen ob es auch bei >3m/s klappt. Aber die Korrektur an der Formel scheint plausible zur Spec.

Hoff die Änderungen werden bald eingearbeitet. Auch die Änderungen bei den anderen Werten scheinen aus meiner Sicht die richtig Korrektur zu sein.

Gruß
Jochen

[killah78]

Hallo Ralf,
sehe ich das richtig, dass ich hier Wünsche für das Modul äußern darf?
Ich hätte da zwei Wünsche zur Aufnahme neuer Temperatursensoren.

Für den ersten Sensor hatte ich mal bereits in diesem Thread geschrieben:
https://forum.fhem.de/index.php/topic,28519.msg742937.html#msg742937

Ist aber wohl untergegangen und hatte nie ein Feedback bekommen.
Vielleicht kannst du dir das nochmal ansehen, ob das übernommen werden kann. Im Anhang dazu meine aktuell verwendete geänderte Datei.

Mein zweites Anliegen ist auch ein Temperatursensor. Es handelt sich um:
-Infactory Sensor NC-3982
-Pearl Sensor for FWS-686
-ABE WS 1503
-Tchibo 65 722

Ist alles baugleich.
Der Code wird auch bereits im Signalduino als Protokol 0 empfangen, leider aber nicht durch das Modul entschlüsselt.
Hier wäre die Kodierung dazu:

Code Auswählen Erweitern


Bit 0 - 7: ID
Bit 8 - 11: CRC? (no simple Nibble-Summing though)
Bit 12: Transmit button (1) / Automatic send (0)
Bit 13: Battery, U < 2.50 V sets bit
Bit 14: Temp descending
Bit 15: Temp rising
Bit 16-27: Temp Code
Bit 28-35: Hum %
Bit 36-37: Always 00 - unkown
Bit 38-39: Channel (1-3)
Temp Code= ((Code/10)-90-32)*(5/9)

Beispiel:
IIIIIIII CRC? XB-+ TTTTTTTTTTTT HHHH HHHH ?? CC
00000001 0011 0000 011010100001 0011 0100 00 01: CH1 = 26,50°C, 34% RH
11110001 1100 0000 011010101101 0011 0110 00 10: CH2 = 27,17°C, 36% RH
11110001 1110 0000 011010110010 0011 0111 00 11: CH3 = 27,44°C, 37% RH
00011000 1000 0100 011010110110 0011 1000 00 01: CH1 = 27,66°C, 38% RH



Wäre das möglich, dies einzubauen???
Gruss
killah78

[Ralf9]

Hallo killah78,

ich schaue es mir mal an.
Dazu wären zum Testen rawmsg vom Signalduino hilfreich.

z.b. so etwa:
MS;P2=569;P3=-4138;P4=-2106;P5=-9091;D=2524232323232423242424242424242424232423242324232323242424242423232324242424;CP=2;SP=5;R=23;
s7A00AB838000
mit temp, hum und channel.

Nachrichten von einer negativen Temperatur, Batterie low,  Transmit button und einem anderen Kanal wären auch schön.
Die negative Temperatur kannst Du auch nachreichen, wenn es draussen Minusgrade hat

Gruß Ralf

[killah78]

Hallo Ralf,
vielen Dank.

Hier für den 2. Sensor (NC-3982):

Code Auswählen Erweitern

ch1, 22,9, 51
sduino_DMSG: s1ED565051100
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P0=-16046;P1=977;P2=-1041;P3=553;P4=-7915;P5=-1862;P6=-4143;D=34353535363636363536363536353635363536363535363536353535353536353635353536353535363012121212;CP=3;SP=4;R=36;O;
sduino_RSSI: -56
sduino_TIME: 2019-11-12 07:38:45

ch1, tx-button, 22,0, 47
sduino_DMSG: s1EDD65047100
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P0=-1024;P1=991;P2=558;P3=-7914;P4=-1857;P5=-4100;P6=-16022;D=26101010102324242425252525242525242525252425242525242425242524242424242524242425252524242425;CP=2;SP=6;R=40;O;
sduino_RSSI: -54
sduino_TIME: 2019-11-12 07:40:16

ch2, tx-button, 21,9, 46
sduino_DMSG: s1EDD64E46200
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P0=977;P1=-1043;P2=-7912;P4=560;P5=-4084;P6=-1847;P7=-16020;D=47010101014246464645454545464545464545454645464545464645464645454546464546464645454646464546;CP=4;SP=7;R=39;O;
sduino_RSSI: -54.5
sduino_TIME: 2019-11-12 07:40:48

ch3, tx-button, 21,9, 46
sduino_DMSG: s1E7D64E46300
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P0=-4087;P1=557;P2=-1868;P3=-16010;P4=990;P5=-1026;P6=-7912;D=16121212101010101212101010101012101210101212101212101010121210121212101012121210101345454545;CP=1;SP=6;R=50;O;
sduino_RSSI: -49
sduino_TIME: 2019-11-12 07:41:07

ch1, -14,5, 43
sduino_DMSG: s1EF63BF43100
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P0=-991;P1=-4138;P2=546;P3=-7940;P4=-1888;P5=965;P7=-16049;D=27505050502324242421212121242121212124212124242421212124212121212121242124242424212124242421;CP=2;SP=7;R=40;O;
sduino_RSSI: -54
sduino_TIME: 2019-11-12 09:19:09

CH1, -10,6, 61, good bat, ID35
sduino_DMSG: s234940561100
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P1=575;P2=-1851;P3=-4108;P4=-16056;P5=1000;P6=-1022;P7=-7886;D=17121213121212131312131212131212131213121212121212121312131213131212121213121212131456565656;CP=1;SP=7;R=22;O;
sduino_RSSI: -63
sduino_TIME: 2019-11-12 16:35:51


Das sollte alles mit Batteriewarnung sein, werde später noch einen Wert mit neuen Batterien nachreichen.

Für den erstgenannten Tchibosensor muss ich die Daten auch nachliefern, der sendet im Moment nicht aufgrund fehlender Batterien.

Gruss
killah78

Edit: Habe den Sensor mit neuen Batterien eingefügt, hat dadurch auch andere ID bekommen.
Edit2: Ich habe hier auch mal zwei Signalduino Rohdaten von dem erstgenannten Tchibosensor. Er war jetzt eine Zeit lang ohne Batterie im Schrank. Ich glaube, dass dieser immer nur über den nanoCUL reinkam. Jetzt wird er auch über den Signalduino mit Protokol 6 erkannt. Leider stimmt die Länge nicht mit meiner Kodierung in der angehängten Datei überein. Die Dekodierung an sich sollte aber passen.

Code Auswählen Erweitern


22,9, 24:
2019.11.12 17:05:12.831 4: sduino/msg READ: ^BMS;P0=-970;P1=254;P3=-1983;P4=-8045;D=14101310131010101310101010101010101010101313101010101010101313131010131013;CP=1;SP=$
2019.11.12 17:05:12.834 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.12 17:05:12.834 5: sduino: Starting demodulation at Position 2
2019.11.12 17:05:12.835 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.12 17:05:12.835 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5100180E5 length 36  RSSI = -59
2019.11.12 17:05:12.836 5: sduino Dispatch: u6#5100180E5, test ungleich: disabled
2019.11.12 17:05:12.844 5: sduino Dispatch: u6#5100180E5, -59 dB, dispatch
2019.11.12 17:05:12.844 5: sduino: dispatch u6#5100180E5
2019.11.12 17:05:12.845 4: SIGNALduino_unknown incomming msg: u6#5100180E5
2019.11.12 17:05:12.845 4: SIGNALduino_unknown rawData: 5100180E5
2019.11.12 17:05:12.845 4: SIGNALduino_unknown Protocol: 6
2019.11.12 17:05:12.845 4: SIGNALduino_unknown converted to bits: 010100010000000000011000000011100101
2019.11.12 17:05:12.846 4: SIGNALduino_unknown decoded protocolid: 6  EuroChron, sensor id=51, channel=, temp=22.9

2019.11.12 17:05:12.846 4: SIGNALduino_unknown sduino Protocol:6 | To help decode or debug, please add u6! (attr sduino development u6)
2019.11.12 17:05:12.846 4: Unknown, please report
2019.11.12 17:05:12.853 3: sduino: Unknown code u6#5100180E5, help me!


23,0, 23, tx-button:
2019.11.12 17:13:47.590 4: sduino/msg READ: ^BMS;P0=-2054;P1=236;P2=-1032;P3=-7760;D=13121012101212121012121210121212121212121012101010121212121010101212121010;CP=1;SP$
2019.11.12 17:13:47.594 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.12 17:13:47.594 5: sduino: Starting demodulation at Position 2
2019.11.12 17:13:47.595 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 1 1 1 0 0 0 1 1
2019.11.12 17:13:47.596 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110170E3 length 36  RSSI = -62.5
2019.11.12 17:13:47.596 5: sduino Dispatch: u6#5110170E3, test ungleich: disabled
2019.11.12 17:13:47.608 5: sduino Dispatch: u6#5110170E3, -62.5 dB, dispatch
2019.11.12 17:13:47.608 5: sduino: dispatch u6#5110170E3
2019.11.12 17:13:47.609 4: SIGNALduino_unknown incomming msg: u6#5110170E3
2019.11.12 17:13:47.609 4: SIGNALduino_unknown rawData: 5110170E3
2019.11.12 17:13:47.609 4: SIGNALduino_unknown Protocol: 6
2019.11.12 17:13:47.609 4: SIGNALduino_unknown converted to bits: 010100010001000000010111000011100011
2019.11.12 17:13:47.609 4: SIGNALduino_unknown decoded protocolid: 6  EuroChron, sensor id=51, channel=, temp=22.7

2019.11.12 17:13:47.609 4: SIGNALduino_unknown sduino Protocol:6 | To help decode or debug, please add u6! (attr sduino development u6)
2019.11.12 17:13:47.610 4: Unknown, please report
2019.11.12 17:13:47.619 3: sduino: Unknown code u6#5110170E3, help me!
[\code]

[Ralf9]

Ich habe hier auch mal zwei Signalduino Rohdaten von dem erstgenannten Tchibosensor. Er war jetzt eine Zeit lang ohne Batterie im Schrank. Ich glaube, dass dieser immer nur über den nanoCUL reinkam.

Welche Firmwareversion hat der Signalduino?
Hast Du einen Signalduino und einen nanoCUL?
Dann wäre es hilfreich, wenn Du bei einer Nachricht zu der rawmsg vom Signalduino auch die parallel vom nanoCUL empfangene DMSG posten könntest.

Code Auswählen Erweitern

CH1, -10,6, 61, good bat, ID35
sduino_DMSG: s234940561100
sduino_Protocol_ID: 0
sduino_RAWMSG: MS;P1=575;P2=-1851;P3=-4108;P4=-16056;P5=1000;P6=-1022;P7=-7886;D=17121213121212131312131212131212131213121212121212121312131213131212121213121212131456565656;CP=1;SP=7;R=22;O;

Dies ist bereits als Protocol id 51 im 14_SD_WS.pm Modul eingebaut

Code Auswählen Erweitern

2019.11.12 19:50:07.114 4 : sduinoD/msg get raw: MS;P1=575;P2=-1851;P3=-4108;P4=-16056;P5=1000;P6=-1022;P7=-7886;D=17121213121212131312131212131212131213121212121212121312131213131212121213121212131456565656;CP=1;SP=7;R=22;O;
2019.11.12 19:50:07.118 4 : sduinoD: Matched MS Protocol id 51 -> weather, bitLen=45
2019.11.12 19:50:07.118 4 : sduinoD: Decoded MS Protocol id 51 dmsg W51#2349405611 length 40 RSSI = -63
2019.11.12 19:50:07.118 4 : sduinoD: SD_WS_Parse protocol 51, rawData 2349405611
2019.11.12 19:50:07.118 4 : sduinoD: SD_WS_Parse decoded protocol-id 51 (Auriol IAN 275901, IAN 114324, IAN 60107), sensor-id 23
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 T: -10.6 H: 61
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 temperature: -10.6
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 humidity: 61
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 batteryState: ok
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 trend: rising
2019-11-12 19:50:07.120 SD_WS SD_WS_51_TH_1 sendmode: manual

So ist es im 14_SD_WS.pm Modul eingebaut

Code Auswählen Erweitern

# Auriol Message Format (rflink/Plugin_044.c):
# 0    4    8    12   16   20   24   28   32   36
# 1011 1111 1001 1010 0110 0001 1011 0100 1001 0001
# B    F    9    A    6    1    B    4    9    1
# iiii iiii ???? sbTT tttt tttt tttt hhhh hhhh ??cc
# i = ID
# ? = unknown (0-15 check?)
# s = sendmode (1=manual, 0=auto)
# b = possibly battery indicator (1=low, 0=ok)
# T = temperature trend (2 bits) indicating temp equal/up/down
# t = Temperature => 0x61b  (0x61b-0x4c4)=0x157 *5)=0x6b3 /9)=0xBE => 0xBE = 190 decimal!
# h = humidity (4x10+9=49%)
# ? = unknown (always 00?)
# c = channel: 1 (2 bits)

Gruß Ralf

[killah78]

Hallo Ralf,
ja, funktioniert perfekt. Kaum macht man es richtig, schon funktioniert es.
Ich habe Protokoll 51 eingeschaltet, schon wird es korrekt empfange.

Zum Tchibosensor war ich jetzt etwas verwirrt, weil ich ihn nicht mehr so empfange, wie bisher.
Das liegt aber daran, dass ich die 14_CUL_TCM97001.pm nie upgedatet hatte und immer auf der Version 16274 stehen geblieben war.
Wenn ich diese jetzt (mit meinen Modifikationen) zurückgespielt habe, wird der Sensor wieder empfangen und zeigt mir die korrekten Werte.
In der neuesten Version wird der Sensor als "AURIOL" empfangen, zeigt aber die falschen Werte an.
Seltsam ist auch, dass nanoCUL und Signalduino einen unterschiedlichen Code generieren.
Hier mal ein Log zum Empfang:

Code Auswählen Erweitern

2019.11.13 18:23:10.217 5: CUL/RAW: /sAEEFEBF1A0EF;  176: 8032
2019.11.13 18:23:10.217 4: CUL_Parse: nanoCUL433 sAEEFEBF1A0EF;  176: 8032
2019.11.13 18:23:10.217 5: nanoCUL433: dispatch sAEEFEBF1A0EF;  176: 8032
2019.11.13 18:23:10.217 4: nanoCUL433: CUL_TCM97001 AURIOL_174 174 (AEEFEBF1A0EF) length: 12 RSSI: -82.5
2019.11.13 18:23:10.218 4: nanoCUL433: CUL_TCM97001 using longid: 1 model: AURIOL
2019.11.13 18:23:10.218 4: nanoCUL433: CUL_TCM97001 AURIOL_174 ID: 174 T: -2.1 Bat: low
2019.11.13 18:23:10.431 4: sduino/msg READ: ^BMS;P0=214;P4=-8064;P6=-1002;P7=-2000;D=04060706070606060706060607060606060606060706070606060606060707070606070607;CP=0;SP$
2019.11.13 18:23:10.432 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:10.432 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:10.432 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.13 18:23:10.432 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110140E5 length 36  RSSI = -73.5
2019.11.13 18:23:10.432 5: sduino Dispatch: u6#5110140E5, test ungleich: disabled
2019.11.13 18:23:10.436 5: sduino Dispatch: u6#5110140E5, -73.5 dB, dispatch
2019.11.13 18:23:10.436 5: sduino: dispatch u6#5110140E5
2019.11.13 18:23:10.437 4: SIGNALduino_unknown incomming msg: u6#5110140E5
2019.11.13 18:23:10.437 4: SIGNALduino_unknown rawData: 5110140E5
2019.11.13 18:23:10.438 4: SIGNALduino_unknown Protocol: 6
2019.11.13 18:23:10.438 4: SIGNALduino_unknown converted to bits: 010100010001000000010100000011100101
2019.11.13 18:23:10.438 4: SIGNALduino_unknown decoded protocolid: 6  EuroChron, sensor id=51, channel=, temp=22.9

2019.11.13 18:23:10.438 4: SIGNALduino_unknown sduino Protocol:6 | To help decode or debug, please add u6! (attr sduino development u6)
2019.11.13 18:23:10.438 4: Unknown, please report
2019.11.13 18:23:10.442 3: sduino: Unknown code u6#5110140E5, help me!
2019.11.13 18:23:10.484 5: CUL/RAW: /sAEEFEBF1A0EC;
2019.11.13 18:23:10.500 5: CUL/RAW: sAEEFEBF1A0EC;/  224: 8032

2019.11.13 18:23:10.500 4: CUL_Parse: nanoCUL433 sAEEFEBF1A0EC;  224: 8032
2019.11.13 18:23:10.500 5: nanoCUL433: dispatch sAEEFEBF1A0EC;  224: 8032
2019.11.13 18:23:10.501 4: nanoCUL433: CUL_TCM97001 AURIOL_174 174 (AEEFEBF1A0EC) length: 12 RSSI: -84
2019.11.13 18:23:10.501 4: nanoCUL433: CUL_TCM97001 using longid: 1 model: AURIOL
2019.11.13 18:23:10.501 4: nanoCUL433: CUL_TCM97001 AURIOL_174 ID: 174 T: -2.1 Bat: low
2019.11.13 18:23:10.649 4: sduino/msg READ: ^BMS;P0=-1008;P1=214;P3=-2011;P4=-8045;D=14101310131010101310101013101010101010101310131010101010101313131010131013;CP=1;SP$
2019.11.13 18:23:10.650 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:10.650 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:10.650 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.13 18:23:10.650 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110140E5 length 36  RSSI = -72
2019.11.13 18:23:10.650 5: sduino Dispatch: u6#5110140E5, test gleich
2019.11.13 18:23:10.650 4: sduino Dispatch: u6#5110140E5, Dropped due to short time or equal msg
2019.11.13 18:23:10.831 4: sduino/msg READ: ^BMS;P0=-2019;P1=228;P2=-1065;P3=-8041;P4=166;D=13121012101212121012121210121212121212121012401212121212121010101212101210;$
2019.11.13 18:23:10.835 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:10.835 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:10.836 5: sduino: Found wrong signalpattern 40, catched 21 bits, aborting demodulation
2019.11.13 18:23:10.985 4: sduino/msg READ: ^BMS;P0=-1004;P2=-2050;P3=217;P5=-8049;D=35303230323030303230303032303030303030303230323030303030303232323030323032;CP=3;SP$
2019.11.13 18:23:10.988 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:10.989 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:10.989 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.13 18:23:10.990 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110140E5 length 36  RSSI = -64.5
2019.11.13 18:23:10.990 5: sduino Dispatch: u6#5110140E5, test gleich
2019.11.13 18:23:10.991 4: sduino Dispatch: u6#5110140E5, Dropped due to short time or equal msg
2019.11.13 18:23:11.229 4: sduino/msg READ: ^BMS;P0=-994;P2=231;P3=-2005;P4=-8049;D=24202320232020202320202023202020202020202320232020202020202323232020232023;CP=2;SP=$
2019.11.13 18:23:11.230 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:11.230 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:11.230 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.13 18:23:11.230 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110140E5 length 36  RSSI = -75.5
2019.11.13 18:23:11.230 5: sduino Dispatch: u6#5110140E5, test gleich
2019.11.13 18:23:11.230 4: sduino Dispatch: u6#5110140E5, Dropped due to short time or equal msg
2019.11.13 18:23:11.507 5: CUL/RAW: /sAEEFEBF1A0EB;  224: 8016

2019.11.13 18:23:11.507 4: CUL_Parse: nanoCUL433 sAEEFEBF1A0EB;  224: 8016
2019.11.13 18:23:11.508 5: nanoCUL433: dispatch sAEEFEBF1A0EB;  224: 8016
2019.11.13 18:23:11.508 4: nanoCUL433: CUL_TCM97001 AURIOL_174 174 (AEEFEBF1A0EB) length: 12 RSSI: -84.5
2019.11.13 18:23:11.509 4: nanoCUL433: CUL_TCM97001 using longid: 1 model: AURIOL
2019.11.13 18:23:11.510 4: nanoCUL433: CUL_TCM97001 AURIOL_174 ID: 174 T: -2.1 Bat: low
2019.11.13 18:23:11.942 4: sduino/msg READ: ^BMS;P0=-2024;P1=212;P2=-995;P4=-8045;D=14121012101212121012121210121212121212121012101212121212121010101212101210;CP=1;SP=$
2019.11.13 18:23:11.943 4: sduino: Matched MS Protocol id 6 -> weather
2019.11.13 18:23:11.943 5: sduino: Starting demodulation at Position 2
2019.11.13 18:23:11.943 5: sduino: dispatching bits: 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 0 1
2019.11.13 18:23:11.943 4: sduino: Decoded matched MS Protocol id 6 dmsg u6#5110140E5 length 36  RSSI = -80.5
2019.11.13 18:23:11.943 5: sduino Dispatch: u6#5110140E5, test gleich
2019.11.13 18:23:11.944 4: sduino Dispatch: u6#5110140E5, Dropped due to short time or equal msg


Also wie gesagt, dies ist der Code, den ich immer manuell eingefügt hatte:

Code Auswählen Erweitern

if ($readedModel eq "TCM218943") {
      #    87FFDE0AD0EB
  ^
    # 1000 0111 1111 1111 1101 1110 0000 1010 1101 0000 1110 1011
        #    A    B    C    D    E    F    G    H    I
#     135   
        # Binärwerte sind invertiert!
        # A+B = Zufällige Code wechelt beim Batteriewechsel
        # C Bit 0 Battery, 3 Manual,
        # E+F Hum - bit 0-7
        # G+H+I Hum - Temperatur, wenn es negativ wird muss man negieren und dann 1 addieren
      #$def = $modules{CUL_TCM97001}{defptr}{$idType3};
     
      $temp    = (hex($a[6].$a[7].$a[8])) & 0x3FF; 
      $temp = (~$temp & 0x03FF);
 
  my $negative    = (~hex($a[6])) & 0xC;
      if ($negative == 0xC) {
        $temp = (~$temp & 0x03FF) + 1;
        $temp = -$temp;
      }
      $temp = $temp / 10;
 
      $humidity = hex($a[4].$a[5]);
      $humidity = (~$humidity & 0xFF);

      if (checkValues($temp, $humidity)) {
        $batbit = (hex($a[2]) & 0x8) >> 3;
$batbit = (~$batbit & 0x8);
        $mode    = (hex($a[2]) & 0x1);
        $mode    = (~$mode & 0x1);

            $model="TCM218943";


     
        if ($deviceCode ne $idType1)  # new naming convention
      {
      if ( $enableLongIDs == TRUE || (($longids != "0") && ($longids eq "1" || $longids eq "ALL" || (",$longids," =~ m/,$model,/))))
          {
   
             Log3 $hash,4, "CUL_TCM97001 using longid: $longids model: $model";
            } else {
             $deviceCode="CUL_TCM97001_" . $model . "_" . $channel;

            }
 

      }     
     
      $def = $modules{CUL_TCM97001}{defptr}{$deviceCode};
        if($def) {
          $name = $def->{NAME};
        }         
        if(!$def) {
            Log3 $name, 2, "CUL_TCM97001 Unknown device $deviceCode, please define it";
            return "UNDEFINED $model" . substr($deviceCode, rindex($deviceCode,"_")) . " CUL_TCM97001 $deviceCode";
        }
        if ($humidity >= 20) {
          $hashumidity = TRUE;
        }
        $hasbatcheck = TRUE; 
        $haschannel = FALSE;   
        $hasmode = TRUE; 
        $packageOK = TRUE;
       
        $readedModel=$model;
      } else {
          $name = "Unknown1";
      }
    }

Damit wurde der Sensor immer empfangen. Allerdings nur,  wenn ich ihn manuell angelegt hatte und das Modell eingetragen hatte. Hoffe du kannst da die notwendigen Informationen rauslesen und was draus machen.
Achso, Signalduino:
Version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
versionmodul v3.4.0
Der nanoCUL läuft mit einer aCUL Firmware

Gruss
killah78

PS: Habe die alte Version nochmal angehangen, womit ich das jetzt (nach manuellem Anlegen des Devices) korrekt (allerding nur durch den nanoCUL) empfange.

[Ralf9]

Hallo killah78,

nanoCUL433: dispatch sAEEFEBF1A0EF;
sduino: dispatch u6#5110140E5

Wenn ich die 5110140E5 invertiere und 000 anfüge kommt das selbe raus wie beim cul, die letzten 3 Ziffern sind nicht relevant.
Dies einzubauen müsste machbar sein, evtl ist beim signalduino eine neue Protokoll ID notwendig.
Wenn ich das richtig sehe, wird am Anfang ein Sensor (wenn die 7. Ziffer F ist kann es auch der SD_WS07 sein) angelegt der nicht passt, bei diesem wird dann das model nach TCM218943 geändert.

Ich habe auch vor den 2.Sensor (NC-3982) in das 14_CUL_TCM97001 Modul einzubauen, dann müsste es auch für den cul funktiionieren.
Alle signalduino Nachrichten die ich bis jetzt gesehen habe, werden als ID 0 und 51 erkannt.
Ich weiß noch nicht wie ich welche Modelbezeichnung ich nehmen soll, wenn niemand eine bessere Idee hat, werde ich die Bezeichung von der ID 51 (Auriol_IAN) nehmen.

Gruß Ralf

[Ralf9]

ich habe den TCM218943 bei mir eingebaut.

C Bit 0 Battery, 3 Manual

Es fehlt noch die Bedeutung von Bit 1 und 2.
Hat der TCM218943 ein Kanalschalter?
Ändern sich Bit 1 und 2 ab und zu oder sind sie immer auf 1

Ich kann zum Testen noch einige Nachrichten vom cul und signalduino brauchen,
mit den folgenden Angaben:
temp, hum, bat,mode
nanoCUL433: dispatch sAEEFEBF1A0EF
sduino/msg READ: MS;P0=214;P4=-806

Gruß Ralf

[killah78]

Hallo Ralf,
der Sender hat nur einen Schalter C/F, der wird aber wohl nur für die Anzeige sein.
Und einen Sendebutton. Kein Kanalschalter.

Ich bekomme nicht zu jeder nanoCUL Message auch eine entsprechende signalduino message.
Hier ist aber auch leider relativ viel los auf 433Mhz.

Hier mal ein paar Mitschnitte:

Code Auswählen Erweitern

20,9, 25
CUL/RAW: /sAEFFE6F2E0F9;  208: 8032
sduino/msg READ: ^BMS;P0=-1072;P2=-8040;P3=211;P4=-2026;D=32303430343030303430303030303030303030303434303034303030303434303430303034;CP=3;SP$
sduino Dispatch: u6#5100190D1, test ungleich: disabled


21,0, 25, forced
CUL/RAW: /sAEEFE6F2D0FC;  208: 8032


21,3, 22, bat low, forced
CUL_Parse: nanoCUL433 s6A6FE9F2A0F3;  208: 8064
sduino/msg READ: ^BMS;P0=-580;P2=-962;P5=-7993;P6=271;D=65606262606260626060626260626262626262626062606062626262626060626062606260;CP=6;SP=5$
sduino/msg READ: ^BMS;P0=-972;P1=244;P2=-1986;P3=-8004;D=13121010121012101212101012101010101010101210121210101010101212101210121012;CP=1;SP=$



27,3, 78, bat low
CUL/RAW: /s6A7FB1EEE007;  224: 8016
sduino/msg READ: ^BMS;P0=216;P1=-1015;P3=-2014;P4=-8066;D=04030101030103010303010101010101010103010103030303010103010303010101030101;CP=0;SP$
2019.11.14 19:01:14.602 5: sduino Dispatch: u6#95804F2C4, test ungleich: disabled


21,7, 82, forced
CUL/RAW: /s2DEFADF260FB;  208: 8032
sduino/msg READ: ^BMS;P0=-931;P1=262;P2=-1978;P4=-8000;D=14121210121010121010101012101010101012101210101210101010101212101212101012;CP=1;SP=$
sduino Dispatch: u6#D210520D9, test ungleich: disabled


21,1, 83, normal
CUL/RAW: /s2DFFADF29018;  208: 8032

20,8, 84, normal
CUL/RAW: /s2DFFABF2F011;  208: 8032


Die Empfangswerte vom Sender sind mit RSSI 75 auch relativ schlecht. Der andere Sender ist mit 55 deutlich besser. Ein anderer Tchibo Sender, der draussen hängt hat sogar nur 45. Die 75 bei einer Entfernung von ca 5 Metern zum Empfänger wohlgemerkt.

Gruss

[Ralf9]

Ich habe die beiden Sensoren als Model "TCM218943" und "Auriol_IAN" eingebaut, ich habe es noch nicht komplett durchgetestet. Es kann sein, daß beim Auriol_IAN der Trend noch nicht passt.

https://github.com/Ralf9/14_CUL_TCM97001/commit/5365b5ad0feb3b64cb31abb4c4a94f89fe2068d1
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm

Der TCM218943 funktioniert noch nicht mit dem Signalduino, da ist noch eine neue Protocol ID oder eine Anpassung an der ID 6 notwendig.
https://github.com/RFD-FHEM/RFFHEM/issues/692

Wenn Du Beschreibungen von den Sensoren hast, könnte ich noch von den beiden Sensoren bei Temp und Hum die min und max Werte gebrauchen.

Gruß Ralf

[killah78]

Hallo Ralf,
vielen Dank für das Hinzufügen.
Ich habe mal die Sensoren gelöscht und geschaut, was neu angelegt wird.
Der Tchibo wird als Auriol angelegt und ich muss das Modell dann ändern, dann passt es. Wie du schon geschrieben hattest, wird der derzeit nur durch den CUL empfangen.

Der Pearl Sender wird aber über SD_WS angelegt und wird ausschließlich vom Signalduiono empfangen. Also so wie vorher. Muss ich irgendwas tun, damit der über TCM97001 reinkommt?

Weitere technische Daten der Sender habe ich leider nicht.
Zum TCM habe ich in einem anderen Forum gefunden: ID: 0-255, temp: -39.9 - 59.9, hum: 0-99, bat: 0-1
Ob das alles so stimmt, kann ich aber nicht sagen.

Der Verkaufstext vom NC-3982 besagt:
Temperatur-Messbereich: -20 bis +60 °C
Hygrometer: misst zwischen 20 - 95 % Luftfeuchtigkeit



Gruss
killah78

[Ralf9]

Der Pearl Sender wird aber über SD_WS angelegt und wird ausschließlich vom Signalduiono empfangen. Also so wie vorher. Muss ich irgendwas tun, damit der über TCM97001 reinkommt?

Dazu wäre ein log mit verbose 4 hilfreich, es müsste ungefähr so aussehen:

Code Auswählen Erweitern

2019.11.16 09:35:16.471 4 : sduino/msg READ: MS;P0=-16046;P1=977;P2=-1041;P3=553;P4=-7915;P5=-1862;P6=-4143;D=34353535363636363536363536353635363536363535363536353535353536353635353536353535363012121212;CP=3;SP=4;R=36;O;
2019.11.16 09:35:16.471 4 : sduino: Matched MS Protocol id 0 -> weather (v1), bitLen=45
2019.11.16 09:35:16.471 4 : sduino: Decoded MS Protocol id 0 dmsg s1ED565051100 length 40 RSSI = -56
2019.11.16 09:35:16.471 4 : sduino Dispatch: s1ED565051100, -56 dB, dispatch
2019.11.16 09:35:16.471 4 : sduino: CUL_TCM97001 Unknown 30 (1ED565051100) length: 12
2019.11.16 09:35:16.471 4 : sduino: CUL_TCM97001 Parse Name: Unknown , devicecode: CUL_TCM97001_30 , Model defined: Unknown
2019.11.16 09:35:16.471 4 : sduino: CUL_TCM97001 AURIOL - ERROR temperature 138.1
2019.11.16 09:35:16.471 4 : CUL_TCM97001 using longid: 0 model: Auriol_IAN
2019.11.16 09:35:16.471 2 : CUL_TCM97001 Unknown device CUL_TCM97001_30 model:Auriol_IAN msg:s1ED565051100, please define it
2019-11-16 09:35:16.473 Global global UNDEFINED Auriol_IAN_30 CUL_TCM97001 CUL_TCM97001_30


Gruß Ralf

[killah78]

So sieht das jetzt aus:

Code Auswählen Erweitern

2019.11.16 10:37:19.361 4: sduino/msg READ: ^BMS;P0=-16036;P2=-1028;P3=988;P4=550;P5=-7919;P6=-1869;P7=-4077;D=45464647464646474747464747464646464647474646464647474747$
2019.11.16 10:37:19.364 4: sduino: Matched MS Protocol id 0 -> weather (v1)
2019.11.16 10:37:19.366 4: sduino: Decoded matched MS Protocol id 0 dmsg s23B061E41100 length 40  RSSI = -54
2019.11.16 10:37:19.368 4: sduino: CUL_TCM97001 Unknown 35 (23B061E41100) length: 12
2019.11.16 10:37:19.369 4: sduino: CUL_TCM97001 using longid: 1 model: AURIOL
2019.11.16 10:37:19.390 4: sduino: Matched MS Protocol id 7 -> Weather
2019.11.16 10:37:19.391 4: sduino: Matched MS Protocol id 33 -> weather
2019.11.16 10:37:19.392 4: sduino: Matched MS Protocol id 51 -> weather
2019.11.16 10:37:19.393 4: sduino: Decoded matched MS Protocol id 51 dmsg W51#23B061E411 length 40  RSSI = -54
2019.11.16 10:37:19.394 4: sduino: SD_WS_Parse protocol 51, rawData 23B061E411
2019.11.16 10:37:19.395 4: sduino: SD_WS_Parse decoded protocol-id 51 (Auriol IAN 275901, IAN 114324, IAN 60107), sensor-id 23
2019.11.16 10:37:19.395 4: sduino: using longid for 1 device SD_WS_51_TH_23_1


Gruss
killah78

[Ralf9]

Hast Du ein fhem neustart gemacht?
Bei mir sieht es so aus:

Code Auswählen Erweitern

2019.11.16 10:47:23.434 5 : sduinoD: dispatch s23B061E41100
2019.11.16 10:47:23.434 4 : sduinoD: CUL_TCM97001 Unknown 35 (23B061E41100) length: 12
2019.11.16 10:47:23.435 4 : sduinoD: CUL_TCM97001 Parse Name: Unknown , devicecode: CUL_TCM97001_35 , Model defined: Unknown
2019.11.16 10:47:23.435 4 : sduinoD: CUL_TCM97001 using longid: 1 model: AURIOL
2019.11.16 10:47:23.435 2 : sduinoD: CUL_TCM97001 Unknown device CUL_TCM97001_35 model:AURIOL msg:s23B061E41100, please define it
2019-11-16 10:47:23.440 Global global UNDEFINED AURIOL_35 CUL_TCM97001 CUL_TCM97001_35

Gibt es evtl schon einen anderen CUL_TCM97001 Sensor mit der DEF CUL_TCM97001_35 oder 35?

[killah78]

ja Neustart hatte ich gemacht.
Derzeit auch kein anderes Device mit 35.
Sollten denn zwei Devices dadurch entstehen? Eins durch TCM97001 und eins durch SD_WS?
Das SD_WS funktioniert nach wie vor. Hatte ich zwischendurch auch mal gelöscht, wurde dann neu angelegt.
Kann ich nochwas testen?

Gruss
killah78

[Ralf9]

Ja, es sollten eins durch TCM97001 und eins durch SD_WS entstehen.
Hast Du nach dem letzten Löschen eines TCM97001 Devices ein Neustart gemacht?

Du kannst auch mal versuchen den CUL_TCM97001_35 manuell anzulegen

Code Auswählen Erweitern

define AURIOL_35 CUL_TCM97001 CUL_TCM97001_35

Gruß Ralf

[killah78]

Ja hatte auch neu gestartet. Wird aber nicht angelegt.
Ich habe es jetzt manuell angelegt, dann wird es auch mit Werten beliefert. Aber leider sind die Werte falsch.

hier mal je ein Device Listing:

Code Auswählen Erweitern

Internals:
   CHANGED   
   CODE       SD_WS_51_TH_23_1
   DEF        SD_WS_51_TH_23_1
   FUUID      5dcfaac8-f33f-86d0-f9b7-cd005d4036178028
   LASTInputDev sduino
   MSGCNT     195
   NAME       SD_WS_51_TH_23_1
   NR         817
   STATE      T: 19.9 H: 41
   TYPE       SD_WS
   bitMSG     0010001111100000011000101010010000010001
   lastMSG    23E062A411
   lastReceive 1573917946.14378
   sduino_DMSG W51#23E062A411
   sduino_MSGCNT 337
   sduino_Protocol_ID 51
   sduino_RAWMSG MS;P0=-4077;P1=562;P2=-1859;P3=-16048;P4=955;P5=-1050;P6=-7950;D=16121210121212101010101012121212121210101212121012101210121210121212121210121212101345454545;CP=1;SP=6;R=43;O;
   sduino_RSSI -52.5
   sduino_TIME 2019-11-16 16:25:46
   READINGS:
     2019-11-16 16:25:46   batteryState    ok
     2019-11-16 16:25:46   channel         1
     2019-11-16 16:25:46   humidity        41
     2019-11-16 16:25:46   sendmode        auto
     2019-11-16 16:25:46   state           T: 19.9 H: 41
     2019-11-16 16:25:46   temperature     19.9
     2019-11-16 16:25:46   trend           consistent
     2019-11-16 16:25:46   type            Auriol IAN 275901, IAN 114324, IAN 60107
Attributes:
   alias      Nc-3982
   event-min-interval .*:300
   event-on-change-reading .*
   room       Outdoor

Code Auswählen Erweitern

Internals:
   CFGFN     
   CODE       CUL_TCM97001_35
   DEF        CUL_TCM97001_35
   FUUID      5dd014a1-f33f-86d0-e6cd-1470a2a5b4667cf6
   LASTInputDev sduino
   MSGCNT     2
   NAME       AURIOL_35
   NR         8074
   STATE      T: 9.8
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1573917946.12473
   sduino_DMSG s23E062A41100
   sduino_MSGCNT 4
   sduino_Protocol_ID 0
   sduino_RAWMSG MS;P0=-4077;P1=562;P2=-1859;P3=-16048;P4=955;P5=-1050;P6=-7950;D=16121210121212101010101012121212121210101212121012101210121210121212121210121212101345454545;CP=1;SP=6;R=43;O;
   sduino_RSSI -52.5
   sduino_TIME 2019-11-16 16:25:46
   READINGS:
     2019-11-16 16:24:37   battery         low
     2019-11-16 16:24:37   batteryState    low
     2019-11-16 16:24:37   mode            forced
     2019-11-16 16:25:46   state           T: 9.8
     2019-11-16 16:25:46   temperature     9.8
     2019-11-16 16:24:37   trend           consistent
Attributes:
   model      AURIOL
   room       Outdoor

Soll ich noch Logs liefern?
Gruss
killah78

Edit: ok, nach Modell=AURIOL IAN stimmen die Werte. Wurde zuerst mit AURIOL angelegt.

[Ralf9]

model      AURIOL

Du musst noch das Attribut model auf "Auriol_IAN" ändern

[killah78]

Ja passt.
Jetzt muss ich mal gucken, warum der nicht automatisch angelegt wurde.
Ist das denn richtig, dass nur über Signalduino reinkommt, oder sollten die Werte jetzt auch über den nanoCUL reinkommen?

Danke und Gruss
killah78

[Ralf9]

Edit: ok, nach Modell=AURIOL IAN stimmen die Werte. Wurde zuerst mit AURIOL angelegt.

stimmt auch der Trend?

Der Cul sollte eigentlich auch Daten liefern

[killah78]

Ja passt auch.
über den nanoCUL kommt aber nichts, weder über SD_WS noch über TCM97001.
Vielleicht habe ich eine zu alte Firmware?
V 1.26.05 a-culfw

Gruss
killah78

[Ralf9]

über den nanoCUL kommt aber nichts, weder über SD_WS noch über TCM97001.

Mit der a-culfw kenne ich mich nicht aus, das müsste sich mal jemand anschauen der sich mit der a-culfw auskennt.
Evtl reicht eine kleine Anpassung in der a-culfw

Gruß Ralf

[Ralf9]

Ist es dieser Sensor?
https://www.pearl.de/a-NC3982-3041.shtml
den gibt's gerade recht günstig. Hast Du mal verglichen wie genau die Werte sind?

Gruß Ralf

[killah78]

Ja genau das ist er. Der ist aber dauerhaft so günstig.
Temperatur entspricht meinen anderen Sensoren. Luftfeuchtigkeit zeigen bei mir 3 Sensoren in einem Raum alle was anderes an. Welcher davon jetzt passt kann ich nicht sagen. Andere zeigen 16 und 25% an, der NC3982 zeigt 40 an.

Gruss
killah78

[Ralf9]

Ich habe die Device specific help angepasst und ergänzt.
Bitte mal drüberschauen ob es so passt. Die englische habe ich nur mit google übersetzt.

https://github.com/Ralf9/14_CUL_TCM97001/commit/d4b99688822b1d1b514ce4efb629b08ec3412780

Gruß Ralf

[Ralf9]

Wenn nichts dagegen spricht, habe ich vor bei der Erkennung neuer Sensoren bei der Reihenfolge der Abfragen AURIOL und KW9010 zu tauschen:

alt

Code Auswählen Erweitern

if (($readedModel eq "AURIOL" || $readedModel eq "Unknown")) {

if (checkCRCKW9010($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "KW9010")) {

if ($readedModel eq "Auriol_IAN" || (hex($a[9]) >= 1 && hex($a[9] <= 3 && $readedModel eq "Unknown"))) {

if (($readedModel eq "TCM218943" || $readedModel eq "Unknown")) {


neu

Code Auswählen Erweitern


if (checkCRCKW9010($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "KW9010")) {

if (($readedModel eq "AURIOL" || $readedModel eq "Unknown")) {

if ($readedModel eq "Auriol_IAN" || (hex($a[9]) >= 1 && hex($a[9] <= 3 && $readedModel eq "Unknown"))) {

if (($readedModel eq "TCM218943" || $readedModel eq "Unknown")) {

Gruß Ralf

[muede]

Hallo,

auch ich habe mir in einem guten Angebot die Lidl Wetterstation geholt.
Leider habe ich noch einige Ungereimtheiten bei der Auswertung der Daten.
Zunächst zur Einrichtung:

• Der Windsensor wird als CUL_TCM97001_181 erkannt. Dabei wird er als model W132 initialisiert. Die angezeigten Werte passen auch soweit. Stelle ich das Modell auf Auriol um, was es ja eigentlich auch ist, wird die Temperatur verändert und negativ angezeigt. Es handelt sich dabei aber nicht um eine einfache Umekhr des Vorzeichens. Es wird auch ein komplett abweichender Zahlenwert gesetzt (Bsp: gemssen als W132 9,6° C, umgesetzt als Auriol -15,6° C)
• Der Regensensor wird als CUL_TCM97001_176. Er wird als model W174 initialisiert. Mit Umsetellung auf Auriol findet hier kein Datenaustausch statt. Unter 174 werden nur drei Werte angezeigt: rain, R und israining.
  
  ^{battery        ok 2019-11-12 16:45:59
  batteryState ok 2019-11-12 16:45:59
  israining      no 2019-11-17 21:27:20
  rain          11.5 2019-11-17 21:26:42
  state    R: 11.5 2019-11-17 21:26:42}
  
  Israining wird nur kurz als YES erkannt, um dann kurz später wieder auf NO umzuspringen, obwohl es am Regnen ist.
  Rain ist nur ein Summenzug. Die Readings des Mouls (oldRain, newRain) werden nicht angezeigt, die Differenz als 0 gewertet.
  
  ^{2019.11.17 21:21:47 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W1742019.11.17 21:21:47 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35500, new rain 11.25, diff rain 0.0
  2019.11.17 21:21:47 4: sduino: CUL_TCM97001 W174_176 max difference rain 592.7 l
  2019.11.17 21:22:24 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W174
  2019.11.17 21:22:24 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35537, new rain 11.25, diff rain 0.0
  2019.11.17 21:22:24 4: sduino: CUL_TCM97001 W174_176 max difference rain 593.3 l
  2019.11.17 21:23:01 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W174
  2019.11.17 21:23:01 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35574, new rain 11.25, diff rain 0.0
  2019.11.17 21:23:01 4: sduino: CUL_TCM97001 W174_176 max difference rain 593.9 l}
  
  

Auch ein Löschen der Device und erneute Einrichtng hat keine Änderung am Verhalten ergeben. Insbesondere der Regensensor ist so nicht sinnvoll zu verwenden. Meine Idee, mit israining die Markise zu steuern, ist so nicht möglich.

Hat jemand eine Idee, woran das liegen könnte?

LG,
Detlef

[Ralf9]

Der Windsensor wird als CUL_TCM97001_181 erkannt. Dabei wird er als model W132 initialisiert. Die angezeigten Werte passen auch soweit. Stelle ich das Modell auf Auriol um, was es ja eigentlich auch ist, wird die Temperatur verändert und negativ angezeigt.

W132 und W174 sollte eigentlich passen, das Modell Auriol ist für ältere Sensoren mit nur Temperatur.

Israining wird nur kurz als YES erkannt, um dann kurz später wieder auf NO umzuspringen, obwohl es am Regnen ist.

Damit Israining länger als YES angezeigt wird, muss es so stark regnen, daß sich bei jeder gesendeten Nachricht das rain erhöht.

Gruß Ralf

[Ralf9]

ich habe das model Auriol Z31743B ergänzt:
https://github.com/Ralf9/14_CUL_TCM97001/commit/0bddd595072cc60511085b4029560ef76c35f120

zum Testen dies ins FHEM Verzeichnis kopieren und dann einen fhem neustart
https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/FHEM/14_CUL_TCM97001.pm

version CUL_TCM97001
14_CUL_TCM97001.pm 18358 2019-11-30 17:00:00Z Ralf9

Ich habe folgendes geändert und ergänzt:
- Neues Attribut max-diff-rain, mit 0 (default) wird die Abfrage der rain Differenz zwischen 2 Messwerten deaktiviert.
- Korrektur der Berechnung von windSpeed, windGuest und windDirection.
- Neues Attribut windDirectionInverse, falls der Windmesser falsch herum montiert wurde.
- Neues Model "Auriol_IAN" (NC-3982, ADE WS 1503, Tchibo 65 722) zugefügt,
- Neues Model "TCM218943" zugefügt
- Neues Attribut "negation-batt", damit kann das Battery reading invertiert werden
- Einige Checksum Routinen optimiert und Log Ausgaben vereinheitlicht und optimiert.
- Es gibt nun für das Prologue Protokoll einen alternativen devicecode (DEF) bei dem als longID die 2. und 3. Hexiffer verwendet wird.
- Model Auriol Z31743B zugefügt
- update Device specific help ergänzt

Gruß Ralf

[Pfriemler]

Ausgehend von einer Anfrage zum optimalen Vorgehen bei Batteriewechsel:
https://forum.fhem.de/index.php/topic,105934.0.html
äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird... Sollte man hier auch einpflanzen. Alerdings gibt es m.W. noch gar keine sets in dieser TYPE...

[yersinia]

zum Testen dies ins FHEM Verzeichnis kopieren und dann einen fhem neustart
https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/FHEM/14_CUL_TCM97001.pm

version CUL_TCM97001
14_CUL_TCM97001.pm 18358 2019-11-30 17:00:00Z Ralf9

Getestet und funktioniert bei mir. Die Prologue bekommen die alternative DEF, bestehende Prologue Devices sind nicht (negativ) eingeschränkt. Läuft. Danke.

[Ralf9]

äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird...

Ich möchte erst mal nach einer Testphase den aktuellen Stand durch Bjoern in das SVN bringen.
Danach können wir das gerne angehen, da brauche ich aber Hilfe.

Gruß Ralf

[Ralf9]

Ich möchte erst mal nach einer Testphase den aktuellen Stand durch Bjoern in das SVN bringen.

Da sich bis jetzt keiner wegen Probleme oder Fehler gemeldet hat, gehe ich davon aus, daß dies so passt.

Der aktuelle Stand ist im SVN und müsste ab morgen im fhem update sein

Gruß Ralf

[killah78]

Hallo Ralf,
danke für deine Änderungen.
noch ein kurzes Feedback: ich hatte mich seit einigen Tagen (sind wohl schon Wochen) gewundert, dass ein Pearl NC-7159 Temperatursensor ein low-bat gesendet hat. Im Display war nichts derartiges sichtbar.
Jetzt habe ich aber gesehen, dass du ein Negation-batt implementiert hast. Dies musste ich für den Sensor setzen und alles ist gut.
Also keine Probleme.
Danke für deine Mühen.
Gruss
killah78

[Ralf9]

Ausgehend von einer Anfrage zum optimalen Vorgehen bei Batteriewechsel:
https://forum.fhem.de/index.php/topic,105934.0.html
äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird... Sollte man hier auch einpflanzen. Alerdings gibt es m.W. noch gar keine sets in dieser TYPE...

Ich habe es mir mal angeschaut wie es beim LaCrosse Modul funktioniert, dort gibt es ein newBatteryBit.

Für das 14_CUL_TCM97001 Modul müsste dies für Sensoren machbar sein die eine Taste zum manuellen Senden haben.
Die Nachrichten von diesen Sensoren müssen außerdem eindeutig z.B. über eine Prüfsumme dem Sensormodel zugeordnet werden können.

Es müsste dann nach einem Batteriewechsel innerhalb der replaceBatteryForSec Zeit die manuell Sendetaste mehrmals gedrückt werden.

Gruß Ralf

[Pfriemler]

Dann ist das wohl ein bisschen anders als gedacht. Meines Wissens ändern die LaCrosse bei jedem Batteriewechsel ihre ID; es mag ja sein, dass sie ein newBatteryBit mitsenden. Anscheinend wird die ID eines auf "replaceBatteryForSec" gesetzten Sensors nur dann auf die neue korrigiert, wenn dieses Bit mitkommt. Willst Du das ersatzweise mit einer abweichenden Häufigkeit von Sendevorgängen erreichen?

Wenn jeder Sensor eine Prüfsumme mitschickt, die eine eindeutige Zuordnung zum Sensor ermöglicht, bräuchte es doch einen Batteriewechselmechanismus gar nicht ... ?

Ich selbst nutze nur einen einzigen TCM97001, aber ich habe offenbar ein paar Nachbarn - einige der Sender liefern plausible Werte für einen Einsatz im Freien oder unter einer Überdachung. Gerade ist es recht ruhig, die meisten sind nur "defined", zwei ominöse Sensoren sehen aus wie Schnappschüsse meines Sensors. Ich halte diese Neukreationen schlicht für Datenübermittlungsfehler.
Bei einem Batteriewechsel muss ich diesen Sensor neu einrichten; eine Taste hat er nicht.

[Ralf9]

Willst Du das ersatzweise mit einer abweichenden Häufigkeit von Sendevorgängen erreichen?

Nein, diese Sensoren haben ein reading "mode", wenn am Sensor die Sendetaste gedrückt wird, wechselt es von normal auf forced.

Wenn jeder Sensor eine Prüfsumme mitschickt, die eine eindeutige Zuordnung zum Sensor ermöglicht, bräuchte es doch einen Batteriewechselmechanismus gar nicht ... ?

Es wird über die gesendete Nachricht eine Prüfsumme gebildet und diese Prüfsumme mitgeschickt. Über die Art der Prüfsummenbildung lässt sich in der Regel das Sensormodel erkennen.

Bei Sensoren ohne NewBattery Bit oder Sendetaste habe ich keine Idee wie man das replaceBatteryForSec einbauen könnte.

[HomeAuto_User]

Hallo Ralf,

beim W174 müsste man vermutlich eine Anpassung vornehmen.

Das Attribut

Code Auswählen Erweitern


max-diff-rain 20


ist gesetzt aber dennoch passiert folgendes:

Code Auswählen Erweitern


2020-02-08_10:57:14 W174_17 rain: 560.25
2020-02-08_11:27:27 W174_17 rain: 560.25
2020-02-08_11:57:40 W174_17 rain: 560.25
2020-02-08_11:58:55 W174_17 rain: 368.25
2020-02-08_11:59:31 W174_17 rain: 560.25
2020-02-08_12:29:44 W174_17 rain: 560.25
2020-02-08_12:59:57 W174_17 rain: 560.25


Das bringt jede Kurve zum knicken
Das Verhalten tritt sporadisch auf.

Wie wäre es mit einem ,,OldValue" Check oder die maxDiff vom Attribut darf nur positiv sein.

Liebe Grüße Marco


Gesendet von iPhone mit Tapatalk Pro

[Ralf9]

2020-02-08_11:57:40 W174_17 rain: 560.25
2020-02-08_11:58:55 W174_17 rain: 368.25
2020-02-08_11:59:31 W174_17 rain: 560.25

Dies habe ich bei meiner WH3080 auch alle 1-2 Monate, da ist wahrscheinlich die CRC ok obwohl die Nachricht fehlerhaft ist.
Dies herauszufiltern wird recht aufwändig, mir sind auf Anhieb 4 Fälle eingefallen die es zu berücksichtigen gibt:

Der Einfachheit kürze reading mit RD ab.
Es gibt die folgenden Readings
.rainOffset
rain_total
rain
dabei ist:
rain_total = .rainOffset + rain


- Fall 1
ein einzelner rain Wert ist max-diff-rain größer (crc ok trotz Fehler)
z.B.
471.6
490.8
471.6

empfangene rain = 490.8
$diffRain = 490.8 - 471.6
-> $diffRain ist größer als max-diff-rain
RD rainInvalid = 490.8 ($rain)

nächste empfangene rain = 471.6
$diffRain = 471.6 - 471.6      ($rain - $lastRain)
-> $diffRain ist nicht negativ und kleiner als max-diff-rain  => rain ist ok
delete RD rainInvalid
RD rain = rain


- Fall 2
ein rain Wert und folgende ist größer als max-diff-rain (z.B. bei Gießkannentest oder wenn sduino einige Zeit nichts empfangen hat.
z.B.
471.6
490.8
490.8
491.0

empfangene rain = 490.8
$diffRain = 490.8 - 471.6
-> $diffRain ist größer als max-diff-rain
RD rainInvalid = 490.8 ($rain)

nächste empfangene rain = 490.8
$diffRain = 490.8 - 471.6
-> $diffRain ist größer als max-diff-rain
da aber es aber ein RD rainInvalid gibt und der rain nicht kleiner als RD rainInvalid ist => rain ist ok
delete RD rainInvalid
RD rain = rain


- Fall 3
ein einzelner rain Wert ist max-diff-rain kleiner (crc ok trotz Fehler)
z.B.
603.3
315.3
603.3

empfangene rain = 315.3
$diffRain = 315.3 - 603.3
-> $diffRain ist negativ und ist größer als max-diff-rain
RD rainInvalid =  315.3 ($rain)

nächste empfangene rain = 603.3
$diffRain = 603.3 - 603.3
-> $diffRain ist nicht negativ und kleiner als max-diff-rain  => rain ist ok
delete RD rainInvalid
RD rain = rain


- Fall 4
ein rain Wert und folgende ist kleiner als max-diff-rain (Zählerüberlauf oder Batteriewechsel)
z.B.
603.3
50.0
50.3
50.3

empfangene rain = 50.0
$diffRain = 50.0 - 603.3
-> $diffRain ist negativ und ist größer als max-diff-rain
RD rainInvalid = 50.0

nächste empfangene rain = 50.0
$diffRain = 50.0 - 603.3
-> $diffRain ist negativ und ist größer als max-diff-rain
da aber es aber ein RD rainInvalid gibt und der rain nicht kleiner als RD rainInvalid ist => rain ist ok
delete RD rainInvalid
RD .rainOffset = RD .rainOffset + $lastrain
RD rain = rain


Gruß Ralf

[yersinia]

Hallo Ralf9,

kannst du dir bitte mal dies ansehen: [PATCH] Unknown Device Meldung bei CUL_TCM97001

Die Meldungen müllen mir auch den Log voll, ich weiss auch nicht, warum das LogLevel 1 und nicht 3 oder 4 ist. Hier mal ein Auszug aus Mai:

Code Auswählen Erweitern

2020.05.04 08:38:01 2: nanoCUL_433_1: CUL_TCM97001 Unknown device CUL_TCM97001_169 model:Rubicson msg:sA9806C7EF8D8, please define it

Ich würde diese Log-Meldungen gerne unterdrücken - und zwar ohne ein Device anlegen zu müssen, das ich dann aktiv ignoriere.
Der CUL hat verbose auf 2, das global Device auf 3.

Wie werde ich das Zumüllen des Logs los?

EDIT:
Die Log-Auszüge beziehen sich auch auf Hideki und SD_WS07, nicht nur auf CUL_TCM97001. Hab das angepasst und werde nen neuen Thread aufmachen.

Kann man hier das Loglevel hochsetzen?

[Wzut]

Ich habe seit ein paar Tagen den W174 und hatte gestern das Problem das rain nicht mehr aktualisiert werden konnte da angeblich die Differenz alt <-> neu zu groß sei.
Nach etwas suchen bin ich darauf gekommen :

Code Auswählen Erweitern

my $timeSinceLastUpdate = ReadingsAge($iodev, "state", 0);
( gibt es 2x , bei Temp und Rain )
Das Problem ist das das hier nicht "state" vom W174 abgefragt wird sondern vom IODev, d.h. selbst wenn der Timestamp vom rain Reading uralt ist, das IOdev kann durchaus wesentlich aktueller sein da es i.d.R. ja mehr als einen Sensor empfängt. 
Vorschlag : das  $name = $def->{NAME} ein paar Zeilen höher schieben und $iodev durch $name ersetzen.

[Ralf9]

Danke für den Hinweis.
Ich werde es dann bei mir auf dem github ändern und dann bjoernh bescheid geben damit er es ins SVN bringt
https://github.com/Ralf9/14_CUL_TCM97001/blob/master/fhem/FHEM/14_CUL_TCM97001.pm

hier ist das selbe, dies dürfte dann so auch nicht passen

Code Auswählen Erweitern

# Sanity check temperature
if($def) {
my $timeSinceLastUpdate = ReadingsAge($iodev, "state", 0);

Gruß Ralf

[HomeAuto_User]

Hallo Ralf,

siehst du eine Variante oder eine Idee, wie man solch einen Speicherfresser (10min) im Logfile minimieren kann?

- Leider ist das globale verstellen von Verbose nicht im Sinne der anderen Module
- Leider gibt es auch 2 Sensoren des Modules welche auch weiterhin empfangen sollen
- alle Sensoren anlegen lassen und auf Ignore, das ist mit dem SIGNALduino + Empfang in der Region nicht tragbar, da die IGNORE-List dann 100te mit der Zeit werden (Test wurde shcon vollzogen)

Code Auswählen Erweitern

2020.06.06 10:30:12 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20814D00, please define it
2020.06.06 10:30:16 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808A42000, please define it
2020.06.06 10:30:30 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sA1309A4000, please define it
2020.06.06 10:30:35 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:30:44 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20814D00, please define it
2020.06.06 10:30:48 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:30:51 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808A42000, please define it
2020.06.06 10:31:04 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s3DB09D6000, please define it
2020.06.06 10:31:06 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sC1309C4000, please define it
2020.06.06 10:31:18 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20839400, please define it
2020.06.06 10:31:18 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_66 model:Mebus msg:sC4209B3100, please define it
2020.06.06 10:31:33 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:31:42 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s9130994000, please define it
2020.06.06 10:31:45 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:31:51 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20839400, please define it
2020.06.06 10:31:51 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209C9F00, please define it
2020.06.06 10:32:14 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s1DB09B6000, please define it
2020.06.06 10:32:16 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s8130984000, please define it
2020.06.06 10:32:24 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:ABS700 msg:s8C208300, please define it
2020.06.06 10:32:24 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20839400, please define it
2020.06.06 10:32:24 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209C9F00, please define it
2020.06.06 10:32:29 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:32:42 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:32:47 2: sduino_433: CUL_TCM97001_08: Unknown device CUL_TCM97001_72 model:W044 msg:s480BB0990000, please define it
2020.06.06 10:32:57 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209C9F00, please define it
2020.06.06 10:33:11 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808B40000, please define it
2020.06.06 10:33:22 1: sduino_433: SD_UT_Parse UNDEFINED sensor MD_2018R detected, protocol 91, data 11C2C1146, code 11C2C1
2020.06.06 10:33:22 1: sduino_433: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 3EEB9, code 3EE
2020.06.06 10:33:24 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s0DB09A6000, please define it
2020.06.06 10:33:27 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:33:46 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808B40000, please define it
2020.06.06 10:34:00 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s1DB09B6000, please define it
2020.06.06 10:34:03 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20839400, please define it
2020.06.06 10:34:04 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sC1309C4000, please define it
2020.06.06 10:34:17 1: sduino_433: SD_UT_Parse UNDEFINED sensor MD_2018R detected, protocol 91, data FF0A1034C, code FF0A10
2020.06.06 10:34:23 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:34:35 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s4DB09E6000, please define it
2020.06.06 10:34:36 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209D6B00, please define it
2020.06.06 10:34:40 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sF1309F4000, please define it
2020.06.06 10:34:56 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808C40000, please define it
2020.06.06 10:35:11 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s5DB09F6000, please define it
2020.06.06 10:35:15 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s4130A34000, please define it
2020.06.06 10:35:18 2: sduino_433: CUL_TCM97001_08: Unknown device CUL_TCM97001_72 model:W044 msg:s480BB0990000, please define it
2020.06.06 10:35:20 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:35:31 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808B40000, please define it
2020.06.06 10:35:41 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20839400, please define it
2020.06.06 10:35:42 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209E4600, please define it
2020.06.06 10:35:46 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s7DB0A06000, please define it
2020.06.06 10:35:50 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s4130A34000, please define it
2020.06.06 10:36:15 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20843A00, please define it
2020.06.06 10:36:22 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s9DB0A26000, please define it
2020.06.06 10:36:58 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:sADB0A36000, please define it
2020.06.06 10:37:00 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s5130A44000, please define it
2020.06.06 10:37:15 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:37:17 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808C40000, please define it
2020.06.06 10:37:21 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20843A00, please define it
2020.06.06 10:37:21 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209D6B00, please define it
2020.06.06 10:37:27 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:37:33 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:sADB0A36000, please define it
2020.06.06 10:37:36 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s6130A54000, please define it
2020.06.06 10:37:48 2: sduino_433: CUL_TCM97001_08: Unknown device CUL_TCM97001_72 model:W044 msg:s480BB0990000, please define it
2020.06.06 10:37:52 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808C40000, please define it
2020.06.06 10:37:54 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20843A00, please define it
2020.06.06 10:37:54 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209E4600, please define it
2020.06.06 10:38:08 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:sEDB0A76000, please define it
2020.06.06 10:38:10 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s9130A84000, please define it
2020.06.06 10:38:12 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:38:22 2: CUL_TCM97001 Unknown device CUL_TCM97001_125 model:Auriol_IAN msg:s7D315CE97100, please define it
2020.06.06 10:38:22 1: sduino_433: SD_WS_Parse UNDEFINED sensor SD_WS_51_TH detected, code SD_WS_51_TH_1
2020.06.06 10:38:24 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:38:27 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209E4600, please define it
2020.06.06 10:38:43 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:sEDB0A76000, please define it
2020.06.06 10:38:47 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sB130AA4000, please define it
2020.06.06 10:38:59 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20843A00, please define it
2020.06.06 10:39:00 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209E4600, please define it
2020.06.06 10:39:08 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:39:18 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:sFDB0A86000, please define it
2020.06.06 10:39:21 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:39:22 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sA130A94000, please define it
2020.06.06 10:39:54 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s3DB0AC6000, please define it
2020.06.06 10:39:57 1: sduino_433: SD_UT_Parse UNDEFINED sensor MD_2018R detected, protocol 91, data 11C2C1443, code 11C2C1
2020.06.06 10:39:58 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:sB130AA4000, please define it
2020.06.06 10:40:05 1: sduino_433: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1B1
2020.06.06 10:40:06 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_196 model:AURIOL msg:sC4209FB200, please define it
2020.06.06 10:40:11 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808D40000, please define it
2020.06.06 10:40:18 1: sduino_433: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_1
2020.06.06 10:40:19 2: sduino_433: CUL_TCM97001_08: Unknown device CUL_TCM97001_72 model:W044 msg:s480BB0990000, please define it
2020.06.06 10:40:30 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_219 model:Mebus msg:s2DB0AB6000, please define it
2020.06.06 10:40:34 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_19 model:Mebus msg:s5130A44000, please define it
2020.06.06 10:40:39 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20843A00, please define it
2020.06.06 10:40:47 2: sduino_433: CUL_TCM97001 Unknown device CUL_TCM97001_80 model:NC_WS msg:s50C808D40000, please define it

MfG Marco

PS: Ich bin kurz davor einen Aufruf zu machen, von RAWmsg des Modules um dort vielleicht eine Umgestaltung vorzunehmen.

[Ralf9]

Hallo Marco,

hast Du schon versucht beim Device Unknown das verbose 1 zu setzen?

Code Auswählen Erweitern

attr Unknown verbose 1

Gruß Ralf

[Wzut]

@Ralf9 , ebeno beim W174 :
 

Code Auswählen Erweitern

    if ((hex($aReverse[2]) >> 1) == 3 && $aReverse[3] == 0x03) {
hier würde ich sicher stellen das $aReverse[2] und $aReverse[3] auch wirklich nummerisch sind, hatte heute wohl ein verstümmeltes Telegramm und da schlug die Zeile auf mit isn't numeric in numeric eq (==)

[HomeAuto_User]

Hallo Ralf,

Hallo Marco,

hast Du schon versucht beim Device Unknown das verbose 1 zu setzen?

Code Auswählen Erweitern

attr Unknown verbose 1

Gruß Ralf

habe ich getestet und dabei fiel mir auf, sollte ein Benutzer das Device

Code Auswählen Erweitern

Unknown umbenannt haben in Bsp.

Code Auswählen Erweitern

CULTCM_Unknown dann funktioniert das nicht mehr. -> Somit kommen dann wieder die Meldungen

Code Auswählen Erweitern

CUL_TCM97001 Unknown device CUL_TCM97001_140 model:AURIOL msg:s8C20814D00, please define it

Wäre es da nicht sinnvoller im Code an der Stelle nach einem Device zu schauen mit den Kriterien
- TYPE : CUL_TCM97001
- Attributes, model: Unknown
- Attributes, verbose: 1

MfG

[Ralf9]

habe ich getestet und dabei fiel mir auf, sollte ein Benutzer das Device Unknown umbenannt haben

muss ich mir anschauen, evtl am Anfang der "CUL_TCM97001_Parse($$)" den Namen von Unknown ermitteln
evtl so

Code Auswählen Erweitern

    my $defUnknown = $modules{CUL_TCM97001}{defptr}{"CUL_TCM97001_Unknown"};   
    if (!$defUnknown) {
      $nameUnknown = $defUnknown->{NAME};
    }
    else {
      $nameUnknown = "Unknown";
   }

[Ralf9]

@Wzut, @HomeAuto_User

ich habe es bei mir eingebaut, bitte mal testen ob es so passt:
https://github.com/Ralf9/14_CUL_TCM97001/commits/dev

Gruß Ralf

[Wzut]

THX, wird aber noch drei Wochen dauern bis ich wieder zuhause bin.

[Damian]

Ich habe neuerdings mein nanocul von a-culfw auf singalduino umgeflasht.

Meine ganzen TCM97001-Sensoren wurden auch gefunden und entsprechend angelegt.

Bei einer kleinen Temperaturstation von lidl (Modelnummer HG04641A-RX) mit einem einfachen Außen-Temperatursender (ohne Feuchte) wird auch Unknown-Eintrag angelegt:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CODE       CUL_TCM97001_Unknown
   DEF        CUL_TCM97001_Unknown
   FUUID      5ef86efe-f33f-c0d4-ba71-b25d1e91dcd1d98d
   LASTInputDev sigduino
   MSGCNT     6
   NAME       Unknown
   NR         86
   STATE      Code: 6AB200
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1593340642
   sigduino_DMSG s6AB20000
   sigduino_MSGCNT 6
   sigduino_Protocol_ID 0.5
   sigduino_RAWMSG MS;P0=-4135;P1=424;P2=-2042;P3=-8691;D=13121010121012101210121010121210121212121212121212;CP=1;SP=3;R=238;O;
   sigduino_RSSI -83
   sigduino_TIME 2020-06-28 12:37:22
   READINGS:
     2020-06-28 12:37:22   state           Code: 6AB200
Attributes:
   model      Unknown
   room       CUL_TCM97001

Die Außentemperatur betrug 19.2 Grad

Wie kann ich den Sensor einbinden?

[HomeAuto_User]

@Wzut, @HomeAuto_User

ich habe es bei mir eingebaut, bitte mal testen ob es so passt:
https://github.com/Ralf9/14_CUL_TCM97001/commits/dev

Gruß Ralf

Hallo,
bisher ist mir noch nichts aufgefallen. Ich lasse es weiter im Test laufen.
MfG

[Ralf9]

Es gibt von der 14_CUL_TCM97001.pm eine neue dev Version
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm
oder

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt

- KW9010 und KW9015 werden nun automatisch über den Kanal erkannt (bei Kanal 0 ist KW9015)

- Für W174 und KW9015 gibt's nun eine gemeinsame sub checkRain
  es fehlt noch raintotal und die Behandlung bei rainüberlauf

-log Ausgabe der Werte ergänzt. z.B.

Code Auswählen Erweitern

sduinoD: CUL_TCM97001 KW9010_196 ID: 196 T: -5.8 H: 50 trend: rising Bat: ok mode: forced CH: 1

Es kann sein, daß bei einigen Sensoren der Trend noch nicht passt.

Gruß Ralf

[monkye]

....oder

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt

- KW9010 und KW9015 werden nun automatisch über den Kanal erkannt (bei Kanal 0 ist KW9015)

Also das funktionierte nicht, die TXT-Datei gibt es nicht...

[Ralf9]

Ich habe es gerade bei mir getestet:

Code Auswählen Erweitern

2020.08.31 09:12:27.802 1 : Downloading https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt
2020.08.31 09:12:28.001 1 : RMDIR: ./restoreDir/update/2020-06-06
2020.08.31 09:12:28.155 1 : UPD FHEM/14_CUL_TCM97001.pm
2020.08.31 09:12:28.347 1 : saving fhem.cfg
2020.08.31 09:12:28.347 1 : saving ./log/fhem.save
2020.08.31 09:12:28.348 1 :
2020.08.31 09:12:28.348 1 : New entries in the CHANGED file:
2020.08.31 09:12:28.348 1 : 404: Not Found
2020.08.31 09:12:28.348 1 : Calling /usr/bin/perl ./contrib/commandref_modular.pl, this may take a while
2020.08.31 09:12:28.392 1 :
2020.08.31 09:12:28.393 1 : update finished, "shutdown restart" is needed to activate the changes.
2020.08.31 09:12:28.393 1 :
2020.08.31 09:12:28.393 1 : Please consider using the global attribute sendStatistics

nach einem fhem restart ergibt
"version CUL_TCM97001"

Code Auswählen Erweitern

14_CUL_TCM97001.pm 18358 2020-08-28 17:00:00Z Ralf9

Gruß Ralf

[heigu]

Gute Tag zusammen,

Danke Ralf9 für den Einbau. Das Update funktioniert bei mir auch, d.h. ich habe die identische Ausgaben beim update und version Befehl wie in Deinem Post gezeigt.

Der 404er Not Found ist etwas verwirrend, da das aber nur das CHANGED File betrifft ist das wohl zu ignorieren, denke ich.

Mein KW9015 wird als Device=AURIOL_240 und Model=KW9015 automatisch angelegt.

[monkye]

Ich habe es gerade bei mir getestet:

Code Auswählen Erweitern

2020.08.31 09:12:27.802 1 : Downloading https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt
.....
nach einem fhem restart ergibt
"version CUL_TCM97001"
[code]14_CUL_TCM97001.pm 18358 2020-08-28 17:00:00Z Ralf9

Gruß Ralf

Mea culpa....

Hatte in  der Tat den Neustart "gedacht" - aber nicht getan. Der Sensor ist da und es funktioniert. (Es regnet seit gestern...)

DANKE @Ralf

[heigu]

Hallo Ralf9,

Seit zwei tagen ist der KW9015 bei mir nun im Dauerbetrieb und tut was er soll. Danke schön dafür schon mal!

Dazu noch ein paar Fragen bzw. Anmerkungen:

• In welcher Einheit wird die Regenmenge angegeben? Ich vermute mm
• Zählt die Regenmenge immer monoton nach oben? Gibt es da mal einen Überlauf? Wird die periodisch zurückgesetzt (1x pro Stunde, 1x am Tag, 1x im Monat, etc.)?
• Bei battery und batteryState wird der Zeitstempel nicht aktualisiert
• Einen kurzen Event-Log habe ich angehängt

Gruß,
heigu

[Ralf9]

Zählt die Regenmenge immer monoton nach oben? Gibt es da mal einen Überlauf?

ja, es sind mm und zählt bis zum Überlauf hoch. Da es 8 Bit sind, müsste der Überlauf bei 255 * 0.45mm =  114,75 mm sein.

Wird die periodisch zurückgesetzt (1x pro Stunde, 1x am Tag, 1x im Monat, etc.)?

nein, aber dies ist evtl mit dem statistics Modul machbar
https://wiki.fhem.de/wiki/Statistics

Bei battery und batteryState wird der Zeitstempel nicht aktualisiert

Ja, dies ist so gewollt. Der Zeitstempel ändert sich nur, wenn sich der batteryState ändert.

Gruß Ralf

[heigu]

Hallo Ralf9,

danke für die schnelle und umfassende Antwort. Ich habe mir damit nur ein Delta der Regenmenge berechnet. Der Überlauf des Zählers ist berücksichtigt, ein Batteriewechsel nicht (Die Annahme ist, das der Überlauf öfter als der Batteriewechsel stattfinden). Mit dem Delta sind dann Summen auf Stunden, Tagen, etc. leicht zu berechnen.

Code Auswählen Erweitern


rainDelta:rain:.* {
  my $rainNew = ReadingsVal("AURIOL_240","rain", 0);
  my $rainOld = ReadingsVal("AURIOL_240","rainOld", $rainNew);

  my $rainDelta = $rainNew - $rainOld;
  if( $rainDelta<0 ) {
    $rainDelta = $rainNew + (114.75 - $rainOld);
  }

  return $rainDelta;
},
rainOld:rainDelta:.* {
  return ReadingsVal("AURIOL_240","rain", 0);
}


[tndx]

Guten Abend,

siehst du eine Variante oder eine Idee, wie man solch einen Speicherfresser (10min) im Logfile minimieren kann?

- Leider ist das globale verstellen von Verbose nicht im Sinne der anderen Module
- Leider gibt es auch 2 Sensoren des Modules welche auch weiterhin empfangen sollen
- alle Sensoren anlegen lassen und auf Ignore, das ist mit dem SIGNALduino + Empfang in der Region nicht tragbar, da die IGNORE-List dann 100te mit der Zeit werden (Test wurde shcon vollzogen)

ich habe mich gerade wieder über das zugemüllte Logfile geärgert und bin auf diesen Thread gestoßen. Ich habe das gleiche Problem und behelfe mir seit Jahren damit, dass ich die Logfiles nachträglich von dem Müll säubere. Gibt es hier irgendeinen Fortschritt? In FHEM ist er offenbar noch nicht eigeflossen, d.h. ich kann nur versuchen, das Modul manuell  durch eine Testversion zu ersetzen?

[Ralf9]

Bei dem Attribut "NC_WS" (PEARL NC7159, LogiLink WS0002) passt momentan die Battery nicht

noch ein kurzes Feedback: ich hatte mich seit einigen Tagen (sind wohl schon Wochen) gewundert, dass ein Pearl NC-7159 Temperatursensor ein low-bat gesendet hat. Im Display war nichts derartiges sichtbar.
Jetzt habe ich aber gesehen, dass du ein Negation-batt implementiert hast. Dies musste ich für den Sensor setzen und alles ist gut.

Ich bin gerade von FHEMduino auf SIGNALduino umgestiegen (ich weiß, damit bin ich spät dran

Seitdem haben alle meine fünf LogiLink WS0002 Temperatursensoren battery/batteryState low.
Die Batterien sind aber frisch und haben eine Spannung von 3,1V

Richtig wäre Bit12 = 1 -> ok

Als es eingebaut wurde hat es noch gepasst:

dancer0705 committed on 4 Apr 2015
https://github.com/mhop/fhem-mirror/commit/ee830c0b39e19682f2b424e1256acc7400e92c48

Code Auswählen Erweitern

      $batbit = (hex($a[3]) & 0x8) >> 3;
      $batbit = ~$batbit & 0x1; # Bat bit umdrehen
     
      if ($batbit) {
        readingsBulkUpdate($def, "battery", "low");
      } else {
        readingsBulkUpdate($def, "battery", "ok");
      }

Mittlerweile passt es nicht mehr: Bit12 = 1 ist jetzt low!

Code Auswählen Erweitern

my $bat = $batbit eq "1" ? "ok" : "low";

Es kann auch sein, daß bei anderen Sensoren das Bat nicht mehr passt.

Wenn nichts dagegenspricht werde ich beim NC_WS die Invertierung auskommentieren und hier commiten:
https://github.com/Ralf9/14_CUL_TCM97001/tree/dev

Gruß Ralf

[Ralf9]

Ich habe das Battery vom Model NC_WS bei meiner dev Version gefixt

https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm
oder

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt

@killah78
Ich könnte von Deinem NC-7159 ein List gebrauchen

@Wzut
Hast Du getestet ob es inzwischen passt?

Ich habe seit ein paar Tagen den W174 und hatte gestern das Problem das rain nicht mehr aktualisiert werden konnte da angeblich die Differenz alt <-> neu zu groß sei.
Nach etwas suchen bin ich darauf gekommen :

Code Auswählen Erweitern

my $timeSinceLastUpdate = ReadingsAge($iodev, "state", 0);
( gibt es 2x , bei Temp und Rain )
Das Problem ist das das hier nicht "state" vom W174 abgefragt wird sondern vom IODev, d.h. selbst wenn der Timestamp vom rain Reading uralt ist, das IOdev kann durchaus wesentlich aktueller sein da es i.d.R. ja mehr als einen Sensor empfängt. 
Vorschlag : das  $name = $def->{NAME} ein paar Zeilen höher schieben und $iodev durch $name ersetzen.

Gruß Ralf

[killah78]

Hi Ralf9,
sorry, irgendwie bekomme ich keine Benachrichtigungen.
Habe das Modul gerade upgedated.
Hier ein Listing:

Code Auswählen Erweitern

Internals:
   AlternativeDEFcode CUL_TCM97001_5_40
   CODE       CUL_TCM97001_82
   DEF        CUL_TCM97001_82
   FUUID      5dc1b815-f33f-86d0-3386-54861fa52393800a
   LASTInputDev sduino
   MSGCNT     35541
   NAME       NC_WS_84
   NR         737
   RSSI       -81.5
   STATE      T: 19.6 H: 17
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1613293890.15708
   nanoCUL433_MSGCNT 875
   nanoCUL433_RAWMSG s52880C4110F1;  496: 9168
   nanoCUL433_TIME 2021-02-13 12:07:20
   sduino_DMSG s52880C411000
   sduino_MSGCNT 34715
   sduino_Protocol_ID 0
   sduino_RAWMSG MS;P3=-1929;P4=509;P5=-3888;P6=-9158;D=46434543454343454345434343454343434343434345454343434543434343434543434345;CP=4;SP=6;R=36;O;m2;
   sduino_RSSI -56
   sduino_TIME 2021-02-14 10:11:30
   READINGS:
     2021-02-13 09:47:56   Activity        alive
     2021-02-14 10:11:30   battery         ok
     2021-02-14 10:11:30   batteryState    ok
     2021-02-09 06:36:16   channel         1
     2021-02-14 10:11:30   humidity        17
     2021-02-09 11:09:17   mode            normal
     2021-02-14 10:11:30   state           T: 19.6 H: 17
     2021-02-14 10:11:30   temperature     19.6
Attributes:
   alias      NC-7159 im Bad
   device_timeout 1800
   icon       temp_outside
   model      NC_WS
   room       Fussbodenheizung,Outdoor
   userattr   device_timeout

Sieht für mich gut aus. Ich habe das negation_bat herausgenommen und jetzt zeigt es "ok" an.

[Ralf9]

ich hab die dev Version in die master übernommen, siehe hier die erste Nachricht.

Wenn es so passt, geb ich Anfang März Bjoern bescheid, dass er es in das SVN übernimmt.

Gruß Ralf

[heigu]

Hallo Ralf,

danke für Deine Arbeit! Ich wollte fragen, ob die Änderungen schon im SVN angekommen sind?

Gruß,
heigu

[HomeAuto_User]

Hallo Ralf,

danke für Deine Arbeit! Ich wollte fragen, ob die Änderungen schon im SVN angekommen sind?

Gruß,
heigu

Hallo Heigu,
laut SVN Info ist die Änderung noch nicht eingeflossen. Die letze Aktualisierung liegt im Dezember 2019 zurück.
Der Maintainer muss dort dies hochladen oder ein Wechsel vom Maintainer vollzogen werden.

MfG Marco

[Ralf9]

danke für Deine Arbeit! Ich wollte fragen, ob die Änderungen schon im SVN angekommen sind?

Bitte noch etwas Geduld, kann noch etwas dauern, ich hab Björn eine PM geschickt, aber er ist in letzter Zeit nicht mehr so oft im Forum online.

Gruß Ralf

[heigu]

Hallo Ralf & Marco,

danke für das Update, gut zu wissen das da wer dran ist.

Gruß,
heigu

[fhem_flash780]

Hi zusammen,

ich hoffe das Ihr mir weiterhelfen könnt. Ich habe mir bei Amazon folgenden Sensor gekauft: FWS-310
In den Rezensionen schrieb jemand er funktioniert mit fhem und wird als Typ SD_WS_33 erkannt.

Über meinen MapleCUN erscheint das device dank autocreate als: CUL_TCM97001_Unknown erkannt.
Ein list sieht folgendermaßen aus:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CODE       CUL_TCM97001_Unknown
   DEF        CUL_TCM97001_Unknown
   FUUID      60c9907f-f33f-bc89-1e0b-2378019860b2e014
   LASTInputDev MAPLECUL2_433
   MAPLECUL2_433_MSGCNT 9
   MAPLECUL2_433_RAWMSG s1C40D180C40014;  496: 8112
   MAPLECUL2_433_TIME 2021-06-16 07:48:33
   MSGCNT     9
   NAME       Unknown
   NR         315
   RSSI       -64
   STATE      Code: 1C40D180C400
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1623822513
   READINGS:
     2021-06-16 07:48:33   state           Code: 1C40D180C400
Attributes:
   model      Unknown
   room       CUL_TCM97001


Egal was ich als model einstelle, es wird immer überschrieben. Im fileLog steht folgendes:

Code Auswählen Erweitern

2021-06-10_20:24:07 Unknown Code: 1A1395BC8A40
2021-06-10_20:24:56 Unknown Code: 1A1355BC88C0
2021-06-10_20:24:57 Unknown Code: 1A1355BC88C0
2021-06-10_20:24:57 Unknown Code: 1A1355BC88C0

Habt Ihr eine Idee ? Oder ist der Sensor nicht kompatibel ?

Grüße

Joschi

[Ralf9]

Der Sensor wird z.Zt. nur vom Signalduino erkannt.

2021-06-10_20:24:07 Unknown Code: 1A1395BC8A40
2021-06-10_20:24:56 Unknown Code: 1A1355BC88C0

Wenn ich diese Codes über den DummySduino zum SD_WS Modul schicke, dann wird er erkannt.

Code Auswählen Erweitern

2021.06.17 19:16:45.183 5 : sduinoD: dispatch W33#1A1395BC8A4
2021.06.17 19:16:45.183 4 : sduinoD: SD_WS_Parse protocol 33, rawData 1A1395BC8A4
2021.06.17 19:16:45.183 4 : sduinoD: SD_WS_Parse decoded protocol-id 33 (E0001PA, s014, S522, TCM, TFA 30.3200, TX-EZ6), sensor-id 104
2021-06-17 19:16:45.185 SD_WS SD_WS_33_TH_1 T: 22.8 H: 47

2021.06.17 19:17:56.285 5 : sduinoD: dispatch W33#1A1355BC88C
2021.06.17 19:17:56.285 4 : sduinoD: SD_WS_Parse protocol 33, rawData 1A1355BC88C
2021.06.17 19:17:56.286 4 : sduinoD: SD_WS_Parse decoded protocol-id 33 (E0001PA, s014, S522, TCM, TFA 30.3200, TX-EZ6), sensor-id 104
2021-06-17 19:17:56.288 SD_WS SD_WS_33_TH_1 T: 22.7 H: 47

Damit es auch mit dem Cul funktioniert, müsste dieses Protokoll jemand in das 14_CUL_TCM97001 Modul einbauen.

Gruß Ralf

[fhem_flash780]

Der Sensor wird z.Zt. nur vom Signalduino erkannt.Wenn ich diese Codes über den DummySduino zum SD_WS Modul schicke, dann wird er erkannt.

Danke für den Test und die Erläuterung, dann halte dann mal Ausschau nach einem Sensor der bereits jetzt out of the box funktioniert.

Grüße

Joschi

[Ralf9]

Ich habe den NX7674, Kuehl- & Gefrierschrank-Thermometer (Rosenstein & Söhne), zugefügt.
Das Protokoll entspricht bis auf ein paar Kleinigkeiten der Protokoll ID 33 vom Signalduino (SD_WS_33).

Bei bedarf kann ich auch weitere Sensoren zufügen, wie z.B. der FWS-310

https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt
Gruß Ralf

[Ralf9]

Hallo,

ich möchte gerne in der "CUL_TCM97001_Define" das löschen des $hash->{OLDDEF} einbauen.

Ich habe mal bei anderen Modulen geschaut.

In der 11_FHT.pm steht:

Code Auswählen Erweitern

  delete($modules{FHT}{defptr}{lc($hash->{OLDDEF})}) # Modify
    if($hash->{OLDDEF});
In der 14_CUL_TX.pm steht:

Code Auswählen Erweitern

  my $dp = $modules{CUL_TX}{defptr};
  my $old = ($dp && $dp->{$a[2]} ? $dp->{$a[2]}{NAME} : "");
  my $op = ($hash->{OLDDEF} ? "modify":"define");
  my $oc = ($hash->{OLDDEF} ? $hash->{CODE} : "");
  return "Cannot $op $hash->{NAME} as the code $a[2] is already used by $old"
        if($old && $oc ne $a[2]);
  delete($modules{CUL_TX}{defptr}{$oc}) if($oc);
Wenn ich den Code richtig verstehe wird da ..{defptr}{$hash->{CODE}} gelöscht, warum nicht ..{defptr}{$hash->{OLDDEF}} ?

Edit:
Wenn ichs richtig überblicke ist es egal was ich nehme, da $hash->{OLDDEF} und $hash->{CODE} dasselbe enthalten.

Gruß Ralf

[Ralf9]

hab es in mein github commited:

https://github.com/Ralf9/14_CUL_TCM97001/commit/f3b64f0555f179bcc7fd0577d18c1a51534face8
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm

ich warte noch auf Rückmeldung wegen dem NX7674 (Kuehl- & Gefrierschrank-Thermometer (Rosenstein & Söhne)) dann kommts ins svn

Gruß Ralf

[Ralf9]

Es gibt eine neue Version
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt
Falls jemand mit einem Auriol_IAN mitliest, da war ein Bug beim Kanal. Bitte mal testen ob der Kanal jetzt passt.

[hasselh]

Hi @Ralf9,

kannst du bitte den Block am Ende von 14_CUL_TCM97001.pm (bei ca Zeile 2100) abändern in:

Code Auswählen Erweitern

UNDEFINED_MODEL:
if (!$defUnknown) {
  Log3 $name, 2, "$iodev: CUL_TCM97001 Unknown device $deviceCode model:$model msg:s$msg, please define it";
}

Das wurde weiter oben im Code ja auch so gelöst. Ansonsten schreibt mir das 14_CUL_TCM97001.pm mein FHEM Log File voll und ich habe keine Möglichkeit das zu unterbinden ohne alle ~20 Devices meiner Nachbarn zu definieren...

[Ralf9]

hast Du die vielen Log Einträge auch noch, wenn Du im Device Unknown das verbose auf 1 setzt?

Gruß Ralf

[hasselh]

nein, so habe ich tatsächlich auch keine Log Einträge mehr. Super !! Ich danke dir !!

Gruss,  Hayo

[Ralf9]

07.01.2024
 - bugfix NX7674 und Auriol_IAN
 - bei den Attributen Hilfe ergänzt
05.01.2024
 - update NX7674
03.01.2024
 - bei einem modify der DEF wird nun die alte DEF gelöscht
15.11.2023
 - NX7674, Kuehl- & Gefrierschrank-Thermometer (Rosenstein & Söhne), zugefügt

Ist nun auch im SVN und morgen im fhem update