Sowohl @didilamken als auch @MKO berichteten bereits über mögliche Probleme beim Auslesen der DS18B20 mit dem FiPy inkl. entsprechender Standardbibliotheken zur Softwareansteuerung, die zu Meßwertaußreißern / Misreadings / Glitches führen können.
Hier wollen wir diese Dinge genauer unter die Lupe nehmen und hoffentlich entsprechend verbessern. Vielen Dank für Eure Mithilfe!
So mal ein Aktueller Bericht der Langzeittests bei mir.
Immer noch mit Datalogger 0.5.1 auf 1.20.0.rc11
FiPy 0
FiPy 1
WiPy 1
Bei den DS Fehlern stellt sich langsam aber sicher raus, das sich die Fehler auf ein paar beschränken und auch bei einem Fehler die gewisse Chance besteht, das ein anderer auf diesem Node parallel ebenfalls einen Fehler macht.
Tippe daher auf recht seltene Timing Probleme.
FiPy 2 habe ich selbst vom test ausgeschlossen, da ich derzeit mit im für das Webinterface arbeiten will. Er hat aber nach 5 Tagen 0 Störungen gehabt.
Abstürze hatte ich bei ihn aktuell aufgrund des abgeschalteten Deep Sleep aber schon ein paar mal.
Herzlichen Dank für die Testberichte! Das hört sich ja vielversprechend an.
Sind das komplette Glitches, also kommen irgendwelche utopischen Werte an, die vermutlich aufgrund unzulänglicher Sensoransteuerung zustande kommen? Hier könnten wir ja in der Tat ein kleines Clamping-Feature einbauen, sofern wir das Problem nicht “ab Hardwaresensor+Treiber” gelöst bekommen.
leider nicht, ist von 0,5°C bis zu 25°C Abweichung nahezu alles vertreten.
Die kleinen Aussetzer fallen eigentlich nur im Vergleich mit den anderen Sensoren auf.
Wenn man jetzt längere Messintervalle hat wird es schwierig werden sie in der Beute von den natürlichen Schwankungen rauszufiltern. Überwiegend sind die Aussetzer allerdings schon höher als 3°C.
Vielen Dank für diese Details zu Deinen Beobachtungen. Wir haben die notwendigen Schritte zur Analyse und Lösung bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas aufgenommen.
Auch @didilamken berichete ja bereits über Fehlmessungen bei diesen Sensoren.
Da wir ungern verfrüht eine
einführen würden, will ich hiermit in die Runde fragen, ob dem ein oder anderen Hardware-Guru noch etwas dazu einfällt, ansonsten schlage ich vor, dass wir uns bei der nächsten Gelegenheit die Treiberschicht bzw. deren Ansteuerung noch einmal genauer ansehen.
a) Darf ich fragen, ob wir einen externen 4.7kOhm pull-up Widerstand am 1-wire Bus zu den DS18B20 an Bord haben?
b) Bzgl. etwaigen Timing-Problemen gibt es hier exzellente Nachforschungen und Wissen aus zweiter Hand mal wieder von robert-hh aus dem Pycom-Forum. Fetzt.
https://forum.pycom.io/topic/2570/solved-onewire-ds18x20-reading-not-stable-with-lopy4-no-problem-with-lopy
Summary from https://forum.pycom.io/topic/2570/solved-onewire-ds18x20-reading-not-stable-with-lopy4-no-problem-with-lopy/19:
onewire.py library [1], no misreadings anymore.Looking at the data sheet, that seems OK. Faster is better. For reading, it says:
“Output data from the DS18B20 is valid for 15μs after the falling edge that initiated the read time slot. Therefore, the master must release the bus and then sample the bus state within 15μs from the start of the slot.”
However, also note that
it’s better to keep the second
sleep_us(1)'s in both theread_bit()andwrite_bit().
That means 4x sleep_us(1) removed from the actual onewire.py library. 2 from read_bit() and 2 from write_bit(). ↩︎
Zur Verbesserung des Verhaltens schlage ich folgende Dinge vor.
start_conversion() länger warten. 1 Sekunde statt 0.75.sleep_us(1) bei read_bit() und ggf. write_bit() in onewire.py testen.start_conversion() zuerst an alle versenden. Oder ist das Quatsch?Der DS18B20 kann eine checksumme mitliefern und sagt, ob der Wert gültig ist. Habe das hier nur für den RasPi ausbuchstabiert gefunden:
Die Datei besteht aus zwei Zeilen, die jeweils den hexadezimalen Registerdump des Sensor-ICs enthalten. Am Ende der ersten Zeile steht die Prüfsumme (CRC) und die Information, ob es sich um einen gültigen Messwert handelt (YES). Die zweite Zeile endet mit dem Temperaturmesswert in tausendstel Grad Celsius. Im Beispiel beträgt die Temperatur also 7,375 °C. Die Genauigkeit auf drei Stellen hinter dem Komma ist natürlich nur scheinbar; dem Datenblatt des DS18S20 entnimmt man zum Beispiel, dass die Messgenauigkeit ±0,5 °C beträgt. Die tatsächliche Temperatur liegt also irgendwo zwischen 6,8 und 7,9 °C.
Vielleicht gibt es in MicroPython auch eine lib, die das macht?
Habe gestern Nacht noch ein Mal genauer hingeschaut, indem ich die Sensoren Mal in Grafana angeschaut habe. Bei Beep gibt es ja keine Möglichkeit sich einzelne Messungen anzuschauen oder näher rein zu Zoomen.
Dabei ist mir auch aufgefallen, das ab und an auch gar keine Werte von den Sensoren kommen.
Könnte das auch Live im Log beobachten. Dort werden dann keine oder nur 2 der Sensoren gefunden.
Die fehlerhaften Werte weichen dort aber noch extremer ab, teilweise mehrere 100°C. Bei Beep werden anscheinend die Werte bereits durch Mittelwerte geglättet.
Danke für die Nachforschungen, @MKO! Habe meine Daten daraufhin auch inspiziert und ähnliches gefunden:
Da Grafana je nach Zoomlevel (für mich) nicht eindeutig nachvolliehbare Mittelwertsbildung / magic macht habe ich versucht die Rohdaten zu exportieren. Afaik bekommt man mit den unten gewählten Parametern nur die Rohdaten wie sie von den nodes gekommen sind ohne irgendwelche “Nachbereitung” / Extremwertbereinigung / Missingsubstitution usw. @Andreas ist das so korrekt oder werden die Daten dort schon irgendwie aufbereitet / gefiltert / manipuliert? Für mich, für die Analyse der Daten ob für später oder hier zur Verbesserung und zum debuggen ist es essentiell, dass user die Möglichkeit haben auf die ungefilterten Rohdaten zuzugreifen!
Diese habe ich dann in Excel importiert und nur die DS18B20- und BME-Temperaturdaten im Datensatz gelassen.
Damit habe ich 1531 Datensätze in knapp 7 Tagen (2019-07-08, 15:27h bis 2019-07-15, 08:01h).
Bei den DS18B20 gab es diesw Ausfälle in Form von keinen Daten, d.h. missings im Datensatz:
Es gab 2x Abweichungen von ein mal ca. 18 °C und ein mal 16 °C nach oben im
Vergleich zum BME was mit ziemlicher Sicherheit nicht der Realität entspricht, alle anderen Abweichungen waren um die 2 °C. Nach unten waren es maximal -4 °C zum BME, was tatsächlich real sein kann, da die Sensoren unter einem Blumentopf draußen waren und der Tontopf auch direkte Sonne abbekommen hat. Der BME hatte keine Ausfälle.
ausfaelle-DS18B20-vs-bme280_2019-07.xlsx (167.7 KB)
A post was merged into an existing topic: Stabilität und längere Testzeiträume der neuen Micropython-Firmware
Was mich etwas wundert, dass die Ausreißer nach oben immer dann auftreten, wenn die anderen Sensoren auch ein Maximum haben.
Gab es direkte Sonne auf einzelne Sensoren? Könnten es doch reale Werte sein?
Nein Sonne ist an dieser Stelle nur ganz früh am Morgen und das 100W Solarpanel liegt als zusätzlicher Sonnenschutz direkt darüber und erzeugt nur aus dem indirektem licht den benötigten Strom.
Sonne gab es hier im Norden auch nicht wirklich.
hier mal das Grafana Panel von den Sensoren des anderen FiPy.
https://swarm.hiveeyes.org/grafana/d/rgD4TVIZz/mko-teststand?orgId=2&from=1562339643166&to=1563108111823&var-STATION=AACHEN-ORSBACH&panelId=16&fullscreen
Ok, da wurde es richtig heiß! :-) also tatsächlich falsche, nicht reale Werte und nicht nur “ein bisserl drüber”. Danke!
das macht Sinn, denn bei der 12bit Auflösung braucht der Chipp alleine 750ms zum Rechnen. Kann gut gehen mit 0.75s muss aber nicht.
Runter auf 11bit denke ich würde auch dem gelieferten Aergebnis bei 0,5 Grad Abweichung noch genüge tun.
Ich vermute ein Zeit-Problem im Treiber ds18x20.py, da (zufällig) ein oder mehrere Bit abgeschnitten werden und dadurch absurde Messwerte entstehen. Ich habe mein Programm ohne Korrektur eine halbe Stunde laufen lassen: es gab 2 Fehler
a: 6. korr> 4. Temp.: 278.1 C -> old: 22.1 C
2019-07-16 18:50:18 BME: 23.6 C 1017.6 mbar 51.2 % HX : 9.4 kg DS: 22.1 C 23.6 C 22.1 C 278.1 C 23.5 C 0.0 C
b:118. korr> 1. Temp.: 2070.1 C -> old: 22.1 C
2019-07-16 19:08:58 BME: 23.5 C 1017.6 mbar 50.5 % HX : 9.7 kg DS: 2070.1 C 23.8 C 22.1 C 22.1 C 23.6 C 0.0 C
Da alle 10 sec gemessen, aber nur alle 20 sec auf der Webseite angezeigt und alle 2 min der Graph neu gezeichnet wird, wird kräftig gemittelt, so dass man im Graph nicht den eigentlichen Fehler erkennen kann.
Der Fehler b war um 19:08:58 Kanal 1 Wert 2070.1 °C ; im Graph um 21:08 Wert 192.8°C
Da mir solche Fehler auf dem RaspberryPi mit Python 2.7 nicht aufgefallen sind, vermute ich den Fehler im MicroPython-Treiber.
Wir haben jetzt kürzlich folgendes gemacht:
Weitere Details wie oben bei fiddling with the timing in onewire.py werden folgen, vielleicht kannst Du hier schon einmal vorfühlen?
Leider sind die Treiber
so unterschiedlich, dass ich (noch) nicht daran etwas ändern könnte.
Hi Didi,
es gibt überall tiefere Treiberschichten. Die Datei FiPy/ds18x20.py at master · Hiverize/FiPy · GitHub enspricht der pycom-libraries/onewire.py at master · pycom/pycom-libraries · GitHub, dort aber ohne die class OneWire, an der die Änderungen vorzunehmen sind.
Im Gegensatz dazu hat hiveeyes-micropython-firmware/sensor_ds18x20.py at master · hiveeyes/hiveeyes-micropython-firmware · GitHub mit dem Sensor-Auslesen selbst überhaupt nichts zu tun, das ist nur ein kleiner Wrapper.
Viele Grüße,
Andreas.