Absolut. Für mich ist hier mit dem aktuellen Stand das korrekteste erreicht, was hier zu erzielen ist. Workarounds halte ich für keine gute Idee.
Da könnte schon noch weiter geforscht werden, ja. Da wir aber bereits so viel Zeit reingesteckt haben und nun ja absolut korrekt unterwegs sind, sehe ich weitere Arbeiten daran nicht als Bestandteil der Version 0.6.0.
Sehe ich anders, wenn Messwerte fehlen ist das alles andere als absolut korrekt und auf jeden Fall einen workaround wert.
Solange die Probleme mit dem Onewire- und/oder DS18B20-Treiber nicht gelöst sind, sollte man auf jeden Fall versuchen, fehlerhafte Messwerte zu erkennen, sei es durch CRC-Check oder Messwert-Toleranzen. Als Workaround würde ich im Fehlerfall den alten Wert übernehmen, denn die Temperatur kann sich gar nicht sprungartig verändern.
Ich werde meine BOB-Sensoren noch einmal an einem Raspi testen. Da sind mir solche Messwert-Ausreisser nur beim HX711 aufgefallen.
Wäre nicht eine Lücke oder null-Value deutlich sinnvoller? Lücken kann auch das Flux im Grafana (oder welche-Software-auch-immer) mit dem jeweils letzten Wert füllen (wenn einem die etwas längere Linie zwischen zwei Punkten doll stören sollte); aber nen alten Wert mit nem neuen Timestamp (schon in der Datenbank) zu versehen klingt in meinen Augen wesentlich unsauberer als ehrlich keinen Wert zu haben. (Wir wissen ja an genau diesem Punkt schon, dass der Wert nicht richtig ist.)
This.
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.
@roh und andere haben Interesse signalisiert, gemeinsam auf etwaige Streifzüge in Richtung Pycom Firmware selber bauen zu gehen, um zu schauen ob wir uns die esponewire.c und die zugehörige modonewire.c aus dem Genuine MicroPython Projekt zu eigen machen können.
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.
Drüben bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas steht es nun auf der Agenda:
also was mich jetzt irritiert, nachdem alles scheinbar “stabil” läuft … dass die Sensoren extreme Temperatur ausreißer haben …
Sind das die besagten Timingprobleme beim 10sec Messintervall ?
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.
Hi Ingo und Didi,
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.
Eigentlich hatten wir gehofft, uns langsam ernsthaft dem Thema HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal widmen zu können und dass die Probleme hinsichtlich Laufzeitstabilität endlich der Vergangenheit angehören würden.
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!
Viele Grüße,
Andreas.
https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-38/fipy-workbench-01/data.txt?from=20190827T000000&to=now ↩︎
https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-38/fipy-workbench-01/data.txt?from=20190827T000000&to=now&include=temperature.28ff641d8fc3944f.onewire:0,temperature.28ff641d8fdf18c1.onewire:0 ↩︎
Vielleicht könnte jemand aus der Leserschaft hier mithelfen? ↩︎
Blockquote Kannst Du uns für den konkreten Fall weitere Details über Dein genaues Setup zukommen lassen, @IngoP
Was genau meinst Du mit SETUP ?
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.
Ja genau.
Das SETUP ist der Original Sketch des KÖLN Workshops, der hier verteilt wurde. Die Systeme laufen in der Firmware mit dem LittleFS.
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:
Die 85,00 °C, sind ein Fehlercode des Sensors,
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.
Setze doch die Lesezyklen mal auf 15 sec. und versuche doch mal die Auflösung des TempSensors auf 10 bit runterzudrehen … geht das via config ?
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
While I’m inclined to believe this is true, I would be happy to have it confirmed better. Is there something about this detail within the datasheet?
Thanks for telling us. Is there any chance to switch over to GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython.?
This is definitively a good thing!
Also 85Grad habe ich nicht als Ausreißer sondern 74 oder 63 … also auch in der Reihe und sehr skurril
Das kann nicht sein. Die Auflösung des DS ist auf 12 bit.
Das Datenblatt sagt da eine Latenz bis zum Ergebnis der Messung von rund 750msec.
Und in diesem Kontext kann ein Blick auf die Register LS und MS zur Datenbeschaffung helfen.
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.
