Hier ist die aktuelle Version meiner modifizierten 14_CUL_TCM97001.pm
Ein update kann gemacht werden mit:
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
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 (https://forum.fhem.de/index.php/topic,95249.msg880699.html#msg880699)
Das Problem ist hier:
$msgtype = "other";
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/14_CUL_TCM97001.pm#L1690
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
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
@@ -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")) {
Zitat von: killah78 am 13 Juni 2019, 13:19:11
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
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
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
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:
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
Die Anpassungen sind mittlerweile im fhem update (SVN).
https://svn.fhem.de/trac/changeset/19762/trunk
Gruß Ralf
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:
$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:
$windgrad = (hex($a[3]) & 0x1)+ ((hex($aReverse[4])*2) + (hex($aReverse[5]))*32) ;
$windDirection = int($windGrad/45);
Wenn dann noch in Zeile 1686
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:
my @winddir_name=("N","N","NE","E","SE","S","SW","W","NW");
Zeile 428 neu:
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:
$windSpeed = (hex($aReverse[6]) + hex($aReverse[7])) * 0.2;
Zeile 1022 neu:
$windSpeed = (hex($aReverse[6]) + hex($aReverse[7]) * 16) * 0.2;
Zeile 1037 alt:
$windGuest = (hex($aReverse[6]) + hex($aReverse[7])) * 0.2;
Zeile 1037 neu:
$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
$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. ;)
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
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:
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
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
Hallo Ralf,
vielen Dank.
Hier für den 2. Sensor (NC-3982):
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.
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]
ZitatIch 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.
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
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
# 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
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:
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:
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.
Hallo killah78,
ZitatnanoCUL433: 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
ich habe den TCM218943 bei mir eingebaut.
ZitatC 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
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:
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
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
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
ZitatDer 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:
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
So sieht das jetzt aus:
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
Hast Du ein fhem neustart gemacht?
Bei mir sieht es so aus:
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?
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
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
define AURIOL_35 CUL_TCM97001 CUL_TCM97001_35
Gruß Ralf
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:
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
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.
Zitatmodel AURIOL
Du musst noch das Attribut model auf "Auriol_IAN" ändern
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
ZitatEdit: ok, nach Modell=AURIOL IAN stimmen die Werte. Wurde zuerst mit AURIOL angelegt.
stimmt auch der Trend?
Der Cul sollte eigentlich auch Daten liefern
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
Zitatü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
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
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
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
Wenn nichts dagegen spricht, habe ich vor bei der Erkennung neuer Sensoren bei der Reihenfolge der Abfragen AURIOL und KW9010 zu tauschen:
alt
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
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
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
ZitatDer 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.
ZitatIsraining 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
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
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...
Zitat von: Ralf9 am 01 Dezember 2019, 12:58:19
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.
Zitatä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
ZitatIch 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
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
Zitat von: Pfriemler am 03 Dezember 2019, 12:32:14
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
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.
ZitatWillst 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.
ZitatWenn 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.
Hallo Ralf,
beim W174 müsste man vermutlich eine Anpassung vornehmen.
Das Attribut
max-diff-rain 20
ist gesetzt aber dennoch passiert folgendes:
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
Zitat2020-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
raindabei ist:
rain_total = .rainOffset + rain
- Fall 1ein 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 2ein 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 3ein 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 4ein 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
Hallo Ralf9,
kannst du dir bitte mal dies ansehen: [PATCH] Unknown Device Meldung bei CUL_TCM97001 (https://forum.fhem.de/index.php/topic,88553.0.html)
Zitat von: yersinia am 04 Mai 2020, 12:09:24
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:
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?
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 :
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.
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
# Sanity check temperature
if($def) {
my $timeSinceLastUpdate = ReadingsAge($iodev, "state", 0);
Gruß Ralf
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)
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.
Hallo Marco,
hast Du schon versucht beim Device Unknown das verbose 1 zu setzen?
attr Unknown verbose 1
Gruß Ralf
@Ralf9 , ebeno beim W174 :
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 (==)
Hallo Ralf,
Zitat von: Ralf9 am 06 Juni 2020, 11:12:57
Hallo Marco,
hast Du schon versucht beim Device Unknown das verbose 1 zu setzen?
attr Unknown verbose 1
Gruß Ralf
habe ich getestet und dabei fiel mir auf, sollte ein Benutzer das Device
Unknown
umbenannt haben in Bsp.
CULTCM_Unknown
dann funktioniert das nicht mehr. -> Somit kommen dann wieder die Meldungen
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
Zitathabe 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
my $defUnknown = $modules{CUL_TCM97001}{defptr}{"CUL_TCM97001_Unknown"};
if (!$defUnknown) {
$nameUnknown = $defUnknown->{NAME};
}
else {
$nameUnknown = "Unknown";
}
@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
THX, wird aber noch drei Wochen dauern bis ich wieder zuhause bin.
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:
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?
Zitat von: Ralf9 am 14 Juni 2020, 17:42:40
@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
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
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.
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
Zitat von: Ralf9 am 28 August 2020, 23:05:04
....oder
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...
Ich habe es gerade bei mir getestet:
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"
14_CUL_TCM97001.pm 18358 2020-08-28 17:00:00Z Ralf9
Gruß Ralf
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.
Zitat von: Ralf9 am 31 August 2020, 09:18:05
Ich habe es gerade bei mir getestet:
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
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
ZitatZä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.
Zitat
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
ZitatBei 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
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.
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);
}
Guten Abend,
Zitat von: HomeAuto_User am 06 Juni 2020, 10:54:30
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?
Bei dem Attribut "NC_WS" (PEARL NC7159, LogiLink WS0002) passt momentan die Battery nicht
Zitat von: killah78 am 03 Januar 2020, 13:50:10
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.
Zitat von: kaihs am 06 Januar 2021, 19:13:11
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
$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!
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
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
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?
Zitat von: Wzut am 05 Juni 2020, 08:00:29
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 :
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
Hi Ralf9,
sorry, irgendwie bekomme ich keine Benachrichtigungen.
Habe das Modul gerade upgedated.
Hier ein Listing:
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.
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
Hallo Ralf,
danke für Deine Arbeit! Ich wollte fragen, ob die Änderungen schon im SVN angekommen sind?
Gruß,
heigu
Zitat von: heigu am 13 Mai 2021, 13:04:39
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 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/14_CUL_TCM97001.pm) 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
Zitatdanke 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
Hallo Ralf & Marco,
danke für das Update, gut zu wissen das da wer dran ist.
Gruß,
heigu
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:
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:
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
Der Sensor wird z.Zt. nur vom Signalduino erkannt.
Zitat2021-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.
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
Zitat von: Ralf9 am 17 Juni 2021, 19:24:06
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
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
update all https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/controls_dev_ralf9_CUL_TCM97001.txt
Gruß Ralf
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:
delete($modules{FHT}{defptr}{lc($hash->{OLDDEF})}) # Modify
if($hash->{OLDDEF});
In der 14_CUL_TX.pm steht:
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
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
Es gibt eine neue Version
https://github.com/Ralf9/14_CUL_TCM97001/blob/dev/fhem/FHEM/14_CUL_TCM97001.pm
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.
Hi @Ralf9,
kannst du bitte den Block am Ende von 14_CUL_TCM97001.pm (bei ca Zeile 2100) abändern in:
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...
hast Du die vielen Log Einträge auch noch, wenn Du im Device Unknown das verbose auf 1 setzt?
Gruß Ralf
nein, so habe ich tatsächlich auch keine Log Einträge mehr. Super !! Ich danke dir !!
Gruss, Hayo
Zitat07.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