SIGNALduino - Tchibo TCM 269250 Außensender

Begonnen von dela2017, 06 März 2017, 21:26:16

Vorheriges Thema - Nächstes Thema

dela2017

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


Sidey

Ich bräuchte mal die Readings und die Internals  _RAWMSG und _DMSG von den Devices.

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

dela2017

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.

dela2017

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?

dela2017

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

dela2017

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?

Ralf9

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
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

Sidey

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.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

dela2017

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?

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

dela2017

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