Vielen Dank für den Support, so sehe ich das an dieser Stelle derzeit auch und das ist nun auch der aktuelle Softwarestand.
Für mich bedeutet das absolut das höchste der Gefühle innerhalb des aktuellen Schlamassels, da die Firmware nun nach diesem aktuellen Stand absolut keine Glitches mehr in den Messungen zu produzieren und daher ausschließlich korrekte Werte zu liefern scheint – zumindest bezogen auf die Probleme beim Auslesen innerhalb der digitalen Sensordomäne, die uns lange Zeit plagten.
Jegliche Workarounds würde ich weiterhin sehr ungerne an dieser Stelle einbauen.
discodoc und Terkin 0.6.0 rufen laut nach Buschfeuerlöschung, daher muss ich kurzfristig weiterreiten und würde gerne erst bei der nächsten Gelegenheit wieder auf Optimierungen in diesem Bereich zurückkommen.
Sehe es genauso wie @wtf – bloß nicht beschönigen!
Das kann man später sonst nicht mehr nachvollziehen, wenn es einmal darauf ankommen sollte.
Grafana oder Beep kommen sehr gut damit zurecht.
Wenn man größere Messabstände in Betracht zieht, um Strom zu sparen, muß man auf alle Fälle – wie @clemens vorgeschlagen hat – die Messung des Sensors wiederholen. Eine Fehlermeldung dass ein Wert nicht gelesen wurde, gibt die Firmware bereits aus. Da sollte es kein Problem sein, sie dort nochmal zu versuchen auszulesen.
Das ist auf jeden Fall wichtig und darf nicht unter den Teppich gekehrt werden. Ich bin da ganz bei Euch, dass wir als Kompensation und als maximal erträglichen Workaround ein Retry-Verfahren einführen können, das die konkret jeweils fehlerhaft gelesenen Sensoren (also dort wo vermutlich der CRC-Check negativ zuschlägt) weitere Male versucht, auszulesen.
Das scheinen noch Probleme im MicroPython-Treiber zu sein, denn die gleichen Sensoren haben bei mir auf dem Fipy mit der Arduino-IDE nicht zu solchen Messwert-Aussetzern geführt.
Die Frage ist jetzt, wie man damit umgeht, solange der Fehler im Treiber nicht behoben ist.
Ich hatte angeregt, die Aussetzer zu erkennen und dann den letzten gültigen Wert zu übertragen.
Andere möchten nur erkennen und dann nichts übertragen.
das eine Gerät, das seit dem 27. August durchgehend Daten übermittelt, die bei [1] und [2] einzusehen sind, ist mit zwei DS18B20 Sensoren ausgestattet. Ich hatte bisher jedoch leider noch keine Gelegenheit, die entsprechenden Daten [3] durchzusehen [4].
Bei diesen Pycom-Gerätschaften kann ja wirklich alles mögliche im Busch sein und wir mussten leider unerwartet hart darum kämpfen, um den aktuellen, nun scheinbar einigermaßen robusten Stand zu erreichen.
Um weiteren Ursachen für fehlerhafte Sensorlesungen auf den Grund zu gehen, brauchen wir Eure engagierte Mithilfe. Kannst Du uns für den konkreten Fall weitere Details über Dein genaues Setup zukommen lassen, @IngoP? Merci vielmals schon im Voraus!
Wenn ich richtig mitgekommen bin, laufen deine FiPy’s mit der aktuellen Hiverize/FiPy master Firmware. Soweit ich weiß sind dort die Timingprobleme noch nicht behoben.
Und daher tauchen ab und zu die falschen Messwerte auf.
In der Hiveeyes Micropython Firmware ist dieser Fehler behoben, allerdings werden dort bei Fehlerwerten, diese nicht übertragen.
Habe mit der hiveeyes-Software und dem release 0.6.0 ein paar einzelne glitches in Form von deutlichen Ausreißern (die wir eigentlich schon als gefixed durch den CRC-check gesehen haben). Es sind einzelne Ausreißer wie hier mit exakt 85,00 °C:
There is a footnote on page 4 which says “The power-on reset value of the temperature register is +85°C.”
so if you read 85 degrees it means it hasn’t done a conversion since the last power on.
You hadn’t wired it up properly so the sensor was being powered off and on periodically, which resets the register to 85 and that is why you got a valid CRC from it.
zwar unlogisch, warum der CRC dann nicht false ist, aber ok. Den sollten wir also noch filtern und nicht als valides sensor reading weiterreichen.
Ich glaube nicht, dass der Lesezyklus eine Rolle spielt. In der hiverize/FiPy-Software dauert das Lesen von BME280, HX711 und 5 mal DS18B20 gut 5 sec. Dann wird bis Sekunde 10 gewartet und dann von vorne. Ob man noch weitere sec wartet ist für den DS18B20 egal. Ich wüsste auch nicht, wo man die Auflösung einstellen kann.
Meine Sensoren haben gut mit dem Python von Raspbian funktioniert, mit dem MicroPython von PyCom gibt es Aussetzer. Allerdings ist der onewire-Treiber im Raspbian enthalten. Der legt eine Datei an, die man mit dem Python-Programm ausliesst. Das ist bei MicroPython ganz anders
Die Werte der Ausreisser sind irrelevant. Da werden 1 oder mehrere Bit “verschluckt” und es entstehen komische Messwerte. Bei mir kam alles vor von 0°C, 29,4 oder 85 oder 258 oder 519 oder 2513 °C. Das falsche Bit ist zufällig, da kann man nichts aus ableiten, ausser es liegt ein falscher Messwert vor.
Ich habe das Gefühl, dass wir aneinander vorbeireden, da dieses Problem eben nur innerhalb der GitHub - Hiverize/FiPy noch nicht behoben wurde.
Es ist wirklich blöd, dass wir hier immer noch mit ganz unterschiedlichen Softwarevarianten zum gleichen Thema hantieren. Habt Ihr Ideen, wie wir diese Angelegenheit verbessern können?
… außer, wenn als erster Wert nach dem Bestromen der DS18B20 aus dem 2 byte -Tempraturregister 0550h (“85°C”) kommt, denn das ist klar ein Indiz, daß diese Register ausgelesen wurden, ohne, daß vorher eine temperature conversion dort gestartet wurde.
Ja genau @weef wir müssen aufpassen das, die Info welche @clemens gefunden hat, nicht gleich wieder im Caos um die Firmware-Versionen untergeht.
Hatte auch schon einen 85°C Wert, seit dem die Gliches in der hiveeyes-micropython-firmware behoben sein sollten.
