FODY E42 für Tempus Pro E41 Thermo-/Hygrosensor Funk 868 MHz

Begonnen von Noop, 16 November 2021, 00:43:32

Vorheriges Thema - Nächstes Thema

KölnSolar

Einen halben Tag später mit 2 "harten" Wechseln der Umgebungsbedingungen(Sensor auf die Terrasse) lassen sich die Charakteristiken so zusammenfassen

- nettes Design, relativ schwer, kein Display
- Funkübertragung alle 12s --> event-on-change-reading empfohlen
- gute Reichweite, stabile Funktelegramme
- durch 1byte random-id(Reset/Batteriewechsel) problemlos viele devices einsetzbar --> attr  longids am Transceiver setzen
- weiße LED blinkt 5-mal bei Reset und Batteriewechsel, nicht im Normalbetrieb(evtl. bei LowBat ?)
- "Zittern" von Messwerten: Schwankungen von +/- 0.1/0.2 T --> threshold für event-on-change-reading empfohlen
- Sprünge von +/- 0,5 T --> für Steuerungsaufgaben z.B. Lüftungserkennung unbrauchbar
- RLF sehr ungenau(mind. 10% zu niedrig) --> für Steuerungsaufgaben z.B. Lüftungssteuerung unbrauchbar
- sehr träge bei starken Schwankungen durch große Masse u. Bauweise(90' Verzug bei deltaT 15°  :o)

Könnten die Sprünge an falsch interpretiertem Datenprotokoll liegen ?  :-\

ZitatBeim Wechsel der aktiven Bank wird nichts in das EEPROM geschrieben
Prima, dann ließen sich ja doch devices unterschiedlichster Funkprotokolle problemlos mit einem 868-nanoCUL-Sduino betreiben.  8)

Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

elektron-bbs

Zitat von: KölnSolar am 05 Dezember 2021, 07:40:53
Könnten die Sprünge an falsch interpretiertem Datenprotokoll liegen ?  :-\

Kann ich mir nicht vorstellen. Ich habe mal die Daten über 24 h in eine Excel-Tabelle gepackt. Da gibt es kein Bit, was sich zusätzlich oder anders auswerten ließe.
In dem Zeitraum gab es folgende Wertänderungen der Temperatur:


Diff.   Anzahl
--------------
0,0       553
0,1       280
0,2        75
0,5        37
-------------
Summe:    945
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

KölnSolar

#47
sehr schöne Excel-Arbeit.

Auf den ersten Blick fällt mir auch nichts anderes ein.

Die Bedeutung von Byte 13 versteh ich nicht. Was soll mir bit count sagen ?
Irgendwie ändern die nibbles sich ja mit den T-Nibbles. Gefühlt stecken da die Sprünge drin. Mal anders dargestellt ohne redundante Werteu u T T T H H t
Temperatur Feuchte
1 3 8 6 1 3 9 0 0,0 39
1 4 8 7 1 3 9 0 18,7 39
1 2 8 8 1 3 9 0 18,8 39
1 3 9 2 1 3 9 0 19,2 39
1 3 9 4 1 3 9 0 19,4 39
1 4 9 9 1 3 9 0 19,9 39
1 0 0 0 2 3 9 0 20,0 39
1 2 0 5 2 3 9 0 20,5 39
1 1 0 6 2 3 8 0 20,6 38
1 2 0 6 2 3 9 0 20,6 39
1 0 0 7 2 4 0 0 20,7 40
1 2 0 7 2 3 8 0 20,7 38
1 3 0 7 2 3 9 0 20,7 39
0 F 1 2 2 4 0 0 21,2 40
1 0 1 2 2 4 1 0 21,2 41
1 1 1 2 2 3 8 0 21,2 38
1 2 1 2 2 3 9 0 21,2 39
1 0 1 3 2 4 0 0 21,3 40
1 1 1 3 2 4 1 0 21,3 41
1 2 1 3 2 3 8 0 21,3 38
1 3 1 3 2 3 9 0 21,3 39
1 1 1 8 2 3 8 0 21,8 38
1 2 1 8 2 3 6 0 21,8 36
1 3 1 8 2 3 7 0 21,8 37
1 2 1 9 2 3 8 0 21,9 38
1 3 1 9 2 3 6 0 21,9 36
1 4 1 9 2 3 7 0 21,9 37
1 0 2 0 2 3 8 0 22,0 38
1 1 2 0 2 3 6 0 22,0 36
1 2 2 0 2 3 7 0 22,0 37
1 2 2 5 2 3 8 0 22,5 38
1 3 2 5 2 3 9 0 22,5 39
1 4 2 5 2 3 7 0 22,5 37
1 2 2 6 2 3 8 0 22,6 38
1 3 2 6 2 3 9 0 22,6 39
Aber eine Formel erkenne ich auch nicht.  :'(

Grüße Markus

Edit: u. wir liegen ja mal über u. mal unter der T. von meinem Oregon.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

elektron-bbs

Das ist eine Quersumme aller Bits:

checksum (number/count of set bits within bytes 14-25)
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

Noop

Zitat von: KölnSolar am 05 Dezember 2021, 07:40:53
- "Zittern" von Messwerten: Schwankungen von +/- 0.1/0.2 T
- sehr träge bei starken Schwankungen

Diese Punkte sind mir auch schon aufgefallen. Die Werte hüpfen oft in dem Bereich.
Zur Genauigkeit kann ich wenig sagen, weil mir ein zuverlässiger Vergleich fehlt
Bedeutet wohl, dass die Teile eigentlich keinen guten Dienst für ihre Aufgabe tun, oder? Also letztlich schlechte Qualität.
Woran erkennt man denn das Gegenteil, z. B. @KölnSolar von "deinem Oregon"? Bzw was wäre denn eine übliche Trägheit?
By the way: was ist RFL?

KölnSolar

#50
OK. passt.
Dann doch nur die 3 nibbles.  :'(
Das sind die "Lücken" durch die Sprünge
20,1-20,4
20,8-21,1
21,4-21,7
22,1-22,4
Auch nicht so richtig systematisch.

Ich mag nicht glauben, dass das ein Hardwarefehler ist.  >:(

Edit:
ZitatAlso letztlich schlechte Qualität
Das würd ich so nicht sagen. Im Augenblick sieht das nach einem systematischen Problem aus.
ZitatBy the way: was ist RFL?
RLF=Relative LuftFeuchte
ZitatBzw was wäre denn eine übliche Trägheit?
Z.B. könnte ein Sensor benutzt werden, um plötzlichen Temperaturabfall durch Fensteröffnung zu erkennen. Dafür ist der FODY zu träge. Die meisten Sensoren sind da flinker(weniger Masse, Luftschlitze f. Sensor).
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

ZitatDas sind die "Lücken" durch die Sprünge
Da sind vermutlich noch mehr Lücken.
Die Lücke zwischen 20.1 und 20.4 hab ich mal getestet.
Bei einer Raumtemperatur von ca 20 Grad wurden bei meinem FODY E42 keine Temperaturen zwischen 20.1 und 20.4 Grad angezeigt.

Sind diese Lücken evtl der Grund warum es diese Sensoren z.Zt. so günstig gibt?
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

KölnSolar

#52
ZitatSind diese Lücken evtl der Grund warum es diese Sensoren z.Zt. so günstig gibt?
Klar, den Gedanken hatte ich auch schon. Aber für uns 3 Entwickler ist doch nicht nachzuvollziehen, dass die Daten eines per I2C angebundenen Sensors nicht mit einem Bröckchen Software richtig in ein Datenprotokoll umzusetzen wären. Da ist das Funkprotokoll doch 1.000-mal komplizierter.
Ich guck mir mal den Sensor näher an...

Edit:
Noop: die Bilder im 1. Post hast Du gemacht ? Der HT-01D ist hier näher beschrieben und hier das technische Datenblatt. Temp/Hum werden mit jeweils 14bit übertragen. Die Formel für die Temp ist etwas komplexTemp output [C] = (Temp_High[7:0] × 64 + Temp_Low[7:2]/4])/214 × 165 - 40. Ob da ein Fehler gemacht wurde ? Hilft alles aber auch nicht weiter.  :'(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Noop

Zitat von: KölnSolar am 05 Dezember 2021, 22:02:42
Noop: die Bilder im 1. Post hast Du gemacht ?

Ja, die habe ich gemacht. Habe auch vorhin mal versucht den auseinander genommenen Fody in Betrieb zu nehmen um zu sehen, ob er sich anders verhält, aber da habe ich wohl etwas kaputt gemacht.
Ich habe aktuell 9 dieser Sensoren in Betrieb (aktuell ohne event-on-change-reading + der Signalduino / fhem läuft bisher nicht durchgehend).
Bei allen sieht man das 0,1°C "flackern", teilweise aber nicht durchgängig, sondern zwischendurch auch mal stabil.
0,5°C Sprünge habe ich jetzt beim Anschauen dieses kurzen Zeitabschnitts nicht gesehen.
Ich kann mal logs hochladen. Wie soll ich das am Besten machen (also irgend ein format / command)?

KölnSolar

ZitatJa, die habe ich gemacht
Danke, dann können wir also sicher sein, dass der HT-01D drin steckt.

Von mir mal der Vergleich der Sensoren als Grafik. Leider nur eine schmale Bandbreite wg. FBH. Aber man sieht schön, wie die Werte mal drüber mal drunter liegen, mal 0,1°, mal 0,2° "Zittern" und den 0,5° "Sprung". Wenn man das weiter analysiert, könnte man vielleicht wenigstens eine Korrektur einbauen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Und damit das hier nicht einschläft: Mittlerweile kristallisiert sich heraus, dass die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden(was für einen Fehler in unserer Dateninterpretation oder einem firmwarefehler im Fody spricht). Außerdem, dass die T wenig(max. 0,2°) unter dem Vergleichssensor liegt, aber deutlich über(max. 0,5°) nach(vor) einem Sprung nach oben(unten). Das sieht man auch schon an meiner gestrigen Grafik. Ich hab nun einen 2. Vergleich in einem anderen Raum gestartet. Und dann werde ich die beiden Sensoren tauschen, da unterschiedlichste Temperaturverhältnisse vorhanden sind.

Eine Wertekorrektur könnte ich mir per userReadings vorstellen. 3 St. müssten genügen(TempSprung,TempDiffSprung,TempKorrigiert). Oder die Sprungtemperaturen definieren und immer auf dieser Basis korrigieren ? Was meint Ihr ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

elektron-bbs

#56
Zitat von: KölnSolar am 07 Dezember 2021, 10:25:43
Und damit das hier nicht einschläft: Mittlerweile kristallisiert sich heraus, dass die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden(was für einen Fehler in unserer Dateninterpretation oder einem firmwarefehler im Fody spricht). Außerdem, dass die T wenig(max. 0,2°)

Was meinst du mit "die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden"?
In meiner Excel-Tabelle sehe ich die Sprünge bei verschiedenen Temperaturen:


19,3   19,9   20,5   21,2   21,8   22,5   |   18,8   21,3   22,0
18,8   19,4   20,0   20,7   21,3   22,0   |   19,3   21,8   22,5


Was auffällt, ist die stark schwankende Anzahl der jeweiligen Nachkommastellen:


Anz.   Nachkomma
----------------
122      0,0
   0      0,1
101      0,2
178      0,3
  21      0,4
  44      0,5
  42      0,6
  33      0,7
116      0,8
290      0,9


Diese müssten ja eigentlich relativ gleich verteilt sein.

Ich habe keine Vorstellung, wie man das nachträglich korrigieren will. Ich habe es schon versucht mit einer Mittelwertbildung über die letzten 10, 20 o.ä. Messwerte. Aber da werden halt auch nur aus den "Stufen" dann "Schrägen" über einen bestimmten Zeitraum.

Im Anhang mal noch ein Diagramm von zwei Sensoren im Vergleich.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

KölnSolar

#57
ZitatWas meinst du mit "die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden"?
In meinem obigen Bsp. findet ein Sprung immer von 18,8 auf 19,3 statt. Werte 18,9-19,2 gibt es nie.

Nun bin ich wieder ein Stückchen weiter. Denn was ich zuvor geschrieben habe stimmt nicht ganz. Nach dem 0,5-Sprung "zittert" das Teil zwischen 19,2 u. 19,4 bis zum nächsten 0,5-Sprung.

D.h. aber, dass eine Korrektur nicht möglich ist bzw. wir tatsächlich nur mit einer Genauigkeit von 0,5° messen.  :'(  Lediglich die Scheingenauigkeit des Zitterns(bisher ohne dass ich dort ein System erkenne)müsste man ausfiltern, damit man nicht dem Trugschluss unterliegt, es würden tatsächlich T-Veränderungen stattfinden.

Bis Morgen habe ich wieder mehr Daten und dann von 2 Sensoren. Dann stell ich wieder Grafiken ein, so dass mein Gesülze besser nachvollziehbar ist.
Und vielleicht erkennen wir ja doch noch etwas, um den Sensor wenigstens auf 1/4° Genauigkeit zu kriegen.  :-\

ZitatDiese müssten ja eigentlich relativ gleich verteilt sein.
Eben nicht, weil es sich nicht um einen Messfehler, sondern um einen Systemfehler handelt. Die Häufigkeit ist dann abhängig vom Temperaturbereich und dem Verhältnis der Dauer der unterschiedlichen 0,5°-Bereiche.

Edit: Deine Vergleichsgrafik ist auch interessant. Man erkennt durch den Versatz der Kurven recht gut die von mir beschriebene Trägheit. Und dadurch wird ein "Berg" zu einem "Plateau".
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Hölle, ist das Ding träge. Ich habs nur in den ca. 3° wärmeren Referenzraum gebracht(grüne Linie). Eine Stunde bis die neue Umgebungstemp. richtig angezeigt wird.  :o

Ansonsten sieht man ganz gut, was ich vorhin versuchte in Worte zu fassen.  ::)

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Und nun ein Chart mit 2 Fody's über ca. 12h im Vergleich. Man sieht, dass sie sich fast identisch verhalten. Ein Muster beim "Zittern", welches man für eine Korrektur nutzen könnte, sehe ich nicht.
Folglich nur die Bestätigung für meinen obigen Ansatz, den Sensor mit 0,5° Genauigkeit zu betreiben und das "Zittern" auszufiltern. So z.B. attr SD_WS_108_TH_4A userReadings corrtemperature:temperature.* {if(ReadingsVal($name,"temperature",0) > ReadingsVal($name,"corrtemperature",0) + 0.3 ||  ReadingsVal($name,"temperature",0) < ReadingsVal($name,"corrtemperature",0) - 0.3)  { ReadingsVal($name,"temperature",0) } else {ReadingsVal($name,"corrtemperature",0)}}

sah im Log dann simpel und unspektakulär so aus 2021-12-08_08:28:23 SD_WS_108_TH_4A corrtemperature: 18.6
2021-12-08_09:53:59 SD_WS_108_TH_4A corrtemperature: 19.3
2021-12-08_09:54:23 SD_WS_108_TH_4A corrtemperature: 18.8
2021-12-08_09:54:35 SD_WS_108_TH_4A corrtemperature: 19.3

Man könnte vielleicht noch überlegen, ob man nicht gezielt auf jeweils xy.0 u. xy.5 korrigiert.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt