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

Begonnen von Ralf9, 13 Juni 2019, 21:10:24

Vorheriges Thema - Nächstes Thema

Ralf9

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

Ralf9

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

Ralf9

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

Ralf9

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

Ralf9

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

Ralf9

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

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:
$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.  ;)

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:


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

killah78

#10
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]

Ralf9

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

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

killah78

#12
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.

Ralf9

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

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

Ralf9

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