Hallo zusammen,
erfreulicherweise wird der Außensender der Tchibo TCM 269250 Wetterstation direkt von SIGNALduino erfasst.
Es wurden hier einige unterschiedliche Devices automatisch angelegt.
SD_WS_33_TH_?
SD_WS_51_TH_?
Die automatischen Devices die per SD_WS_51_TH angelegt werden, sind nicht richtig.
Dafür passt der SD_WS_33_TH sehr sehr gut.
Temperatur und Feuchtigkeit wird korrekt angezeigt.
Das einzige was nicht passt, ist die Batterieanzeige - diese wird mir mit Critical angezeigt, obwohl es frische Batterien sind.
Würden wir das vielleicht auch noch hinbekommen ??
Wäre total klasse.
Unterstütze gerne mit verschiedenen Daten.
Viele Grüße,
Ingo
Ich bräuchte mal die Readings und die Internals _RAWMSG und _DMSG von den Devices.
Hier ganz frisch:
2017.03.06 22:41:58 4: sduino/msg READ: ^BMS;P2=457;P3=-7712;P4=-2004;P5=-3909;D=23242425242425242525252424242425252425252425252425242524252524242425242424242424252525;CP=2;SP=3;R=14;O;^C
2017.03.06 22:41:58 4: sduino: Matched MS Protocol id 0 -> weather1
2017.03.06 22:41:58 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.06 22:41:58 4: sduino: Decoded MS Protocol id 33 dmsg W33#25C36D5881C length 44 RSSI = -67
2017.03.06 22:41:58 4: SD_WS_Parse: Protocol: 33, rawData: 25C36D5881C
2017.03.06 22:41:58 4: sduino decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) sensor id=151, channel=1, temp=13.8333333333333, hum=38, bat=critical
2017.03.06 22:41:58 4: sduino: Matched MS Protocol id 51 -> weather51
2017.03.06 22:41:58 4: sduino: Decoded MS Protocol id 51 dmsg W51#25C36D5881C length 44 RSSI = -107.5
2017.03.06 22:41:58 4: SD_WS_Parse: Protocol: 51, rawData: 25C36D5881C
2017.03.06 22:41:58 4: sduino decoded protocolid: 51 (Lidl Wetterstation 2759001/IAN114324) sensor id=1208, channel=1, temp=29.4, hum=88, bat=ok
2017.03.06 22:41:59 4: sduino/msg READ: ^BMS;P2=454;P3=-7725;P4=-2005;P5=-3907;D=23242425242425242525252424242425252425252425252425242524252524242425242424242424252525;CP=2;SP=3;R=10;O;^C
2017.03.06 22:41:59 4: sduino: Matched MS Protocol id 0 -> weather1
2017.03.06 22:41:59 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.06 22:41:59 4: sduino: Decoded MS Protocol id 33 dmsg W33#25C36D5881C length 44 RSSI = -69
2017.03.06 22:41:59 4: SD_WS_Parse: Protocol: 33, rawData: 25C36D5881C
2017.03.06 22:41:59 4: sduino decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) sensor id=151, channel=1, temp=13.8333333333333, hum=38, bat=critical
2017.03.06 22:42:01 4: sduino/keepalive ok, retry = 0
Temp,Hum von Protocol 33 passt.
Bat leider nicht.
Bei Protocol 51 passen die Werte leider nicht aber Bat wäre okay.
Aktuell hab ich gerade das Verhalten, dass der Decode nicht funktioniert
2017.03.07 21:55:19 4: sduino/msg READ: ^BMS;P1=450;P2=-7717;P3=-2008;P4=-3913;D=12131314131314131414141313131314131413141314141314131413141414131314131313131313131414;
CP=1;SP=2;R=18;O;^C
2017.03.07 21:55:19 4: sduino: Matched MS Protocol id 0 -> weather1
2017.03.07 21:55:19 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.07 21:55:19 4: sduino: Decoded MS Protocol id 33 dmsg W33#25C2AD5C80C length 44 RSSI = -65
2017.03.07 21:55:19 4: SD_WS_Parse: Protocol: 33, rawData: 25C2AD5C80C
2017.03.07 21:55:20 4: sduino/msg READ: ^BMS;P1=433;P2=-7730;P3=-2024;P4=-3918;D=12131314131314131414141313131314131413141314141314131413141414131314131313131313131414;
CP=1;SP=2;R=15;O;^C
2017.03.07 21:55:20 4: sduino: Matched MS Protocol id 0 -> weather1
2017.03.07 21:55:20 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.07 21:55:20 4: sduino: Decoded MS Protocol id 33 dmsg W33#25C2AD5C80C length 44 RSSI = -66.5
2017.03.07 21:55:20 4: sduino: Dropped (W33#25C2AD5C80C) due to short time or equal msg
Es kommen praktisch immer zwei Signale direkt hintereinander mit den gleichen Werten. Daher wird der zweite verworfen.
Aber der erste wieder aktuell gerade nicht dekodiert.
Was könnte das Problem sein?
Könnte man vielleicht ein zusätzliches Protokoll definieren?
Als Zwischenversion von 33 und 51.
Temp,Hum von Protocol 33 passt; Bat leider nicht.
Bei Protocol 51 passen die Werte nicht, aber Bat wäre okay.
Kanal ist auch jeweils okay.
Sollte also doch dann funktionieren, oder?
Gruß,
Ingo
Ich hab leider immer wieder das Problem, dass über einen längeren Zeitraum der Decode nicht kommt:
2017.03.24 08:06:56 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.24 08:06:56 4: sduino: Decoded MS Protocol id 33 dmsg W33#2D411590808 length 44 RSSI = -67.5
2017.03.24 08:06:56 4: SD_WS_Parse: Protocol: 33, rawData: 2D411590808
2017.03.24 08:06:56 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.24 08:06:56 4: sduino: Decoded MS Protocol id 33 dmsg W33#2D411590808 length 44 RSSI = -67.5
2017.03.24 08:06:56 4: SD_WS_Parse: Protocol: 33, rawData: 2D411590808
Der Sender sendet teilweise 10 bis 20 Nachrichten hintereinander ...
Die meisten stehen im Log dann natürlich auf dropped ... Aber beim jeweils ersten kommt es nicht zum Drop, aber es kommt auch keine Dekodierte Nachricht:
Hier dann wieder wo es funktioniert:
2017.03.24 08:25:16 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.24 08:25:16 4: sduino: Decoded MS Protocol id 33 dmsg W33#2D41158C828 length 44 RSSI = -67.5
2017.03.24 08:25:16 4: SD_WS_Parse: Protocol: 33, rawData: 2D41158C828
2017.03.24 08:25:16 4: sduino decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) sensor id=181, channel=1, temp=22.2222222222222, hum=35, bat=critical
2017.03.24 08:25:16 4: sduino: Matched MS Protocol id 33 -> weather33
2017.03.24 08:25:16 4: sduino: Decoded MS Protocol id 33 dmsg W33#2D41158C828 length 44 RSSI = -67.5
2017.03.24 08:25:16 4: SD_WS_Parse: Protocol: 33, rawData: 2D41158C828
2017.03.24 08:25:16 4: sduino decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) sensor id=181, channel=1, temp=22.2222222222222, hum=35, bat=critical
An welcher Stelle müsste ich mit Debuggen anfangen?
Hallo Sidey,
es sieht so aus, als wäre noch ein Fehler in der crc Berechnung und der Ausgabe des crc Fehlers
2017.03.26 08:39:42.106 4: sduinoD/msg get dispatch: W33#2D411590808
2017.03.26 08:39:42.107 5: sduinoD: dispatch W33#2D411590808
2017.03.26 08:39:42.107 4: SD_WS_Parse: Protocol: 33, rawData: 2D411590808
2017.03.26 08:39:42.107 4: sduinoD decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) crc error
2017.03.26 08:39:42.107 4: sduinoD decoded protocolid: 33 (s014/TFA 30.3200/TCM/Conrad) sensor id=181, channel=1, temp=22.2222222222222, hum=36, bat=critical
if (!$decodingSubs{$protocol}{crcok}->( $rawData )) {
Log3 $iohash, 4, "$name decoded protocolid: $protocol ($SensorTyp) crc error";
#return "";
}
Gruß Ralf
Zitat von: Ralf9 am 26 März 2017, 08:59:20
Hallo Sidey,
es sieht so aus, als wäre noch ein Fehler in der crc Berechnung und der Ausgabe des crc Fehlers
Stimmt. Mir ist schleierhaft, wieso meine und Verknüpfung nicht funktioniert, aber so geht es wohl nicht.
Die CRC Berechnung existiert bei diesem Sensor noch nicht. Ich werte einige Bits aus, aber wenn die 0 sind, dann ist der crc fehlerhaft.
Ich habe das in dev-r33 geändert. Damit ist der crc jetzt immer ok.
Ja, der Sender passt nicht ganz zu ProtocolID 33.
Wie schon geschrieben, sind die Werte Channel, Temp, Hum perfekt.
Bat würde von ProtocolID 51 stimmen.
Könnte man hier nicht ein zusätziches Protokoll einführen?
Prinzipiell könnte man auch ein neues Protokoll definieren, aber das ist vielleicht nicht notwendig.
Zum Protokoll #33 habe ich mit die Historie noch mal angesehen. Da hatte ich die Batterie zumindest identisch zur pimatic Implementierung ausgewertet:
https://github.com/RFD-FHEM/RFFHEM/issues/53
Ob die falsch war, weiss ich nicht. Von dem Signalaufbau sieht es aber ziemlich identisch aus.
Hast Du denn mal eine leere und eine volle Batterie ausprobiert?
Grüße Sidey
Ah .. Oki .... Die Daten, die ich habe, stammen von vollen Batterien ...
Hab leider aktuell keine leeren .. Bzw .. nur welche die wirklich leer sind. Batteriemessgerät hab ich leider nicht :-(
Gruß,
Ingo