Ich bin kein OO Programmierer, von daher ist das für mich schwierig… Bascom assembler und co kann ich unterstützen ;-)
Bei meinem PI klappt es hervorragend.
Vielleicht, nur so eine Idee, können wir mal bei espeasy in die libraries schauen…
Die funktionieren …
Ja, das trat auf, solange das Timing noch nicht in Ordnung war. Hier im Beitrag hatten wir uns das mühsam erarbeitet und das Problem bereits vor einiger Zeit bei GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. behoben [1] [2].
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.
Genau!
page 6
*The power-on reset value of the temperature register is +85°C.
Just found another piece worth to be referenced here.
Moin.
Hier nochmal ein Auszug von meinem System.
Die Ursache für die Glitches finde ich aktuell noch nicht valide. könnte doch auch Reflexionen an den Pfostensteckern sein? Interessanterweise tauchen die Glitches nur bei den internen Sensoren auf
Es kann nicht an der Hardware liegen. Ich kann die selben ( nicht gleichen ) Sensoren an einem RaspberryPi und einem Python-Programm ohne viele Messwert-Ausreisser betreiben. Wenn ich sie an den FiPy mit MicroPython stecke, tauchen sie auf. Aus meiner Sicht gibt es noch Timing-Probleme im Onewire-Treiber.
Früher wurde schon viel diskutiert, wie man die Messfehler erkennt und dann mit ihnen macht.
Mein Ansatz war, Temperatursprünge ( z.B. 10°C innerhalb von 10 sec ) zu erkennen und dann einfach den Wert durch den letzten zu ersetzen, da die Temperatur nie so schnell wechseln kann.
Definitiv! Bisher konnten wir hier nur den pure-Python Treiber von Pycom benutzen, dabei sind Timing-Fehler vorprogrammiert.
Zum Glück hatte uns die von @robert-hh verbesserte Variante der onewire.py mit integrierten CRC-checks zwischenzeitlich deutlich weitergeholfen, weil damit zumindest keine falschen Messungen mehr auftraten.
Nachdem andere genervt ähnliche Probleme schildern, haben wir hier noch einmal die Haube aufgemacht und es kommen u.U. durch neue Erkenntnisse die Dinge neu in Bewegung.
… also answering @kjm here:
In fact, modonewire.c would be the right file implementing this functionality. The esponewire.c referenced above was the file for ESP8266 which seems to have slipped into the ESP32 port tree accidentally.
However, we failed on porting this to Pycom MicroPython appropriately. While we have come quite far making it compile, it panics at runtime right away when trying to reset the onewire bus.
We have been able to wrap up some things and share it with the community.
However, going further into the details of this topic is beyond what we can currently do about it.
6 posts were merged into an existing topic: Diskussion über die Ansteuerung der Sensordomäne auf Pycom Geräten
Hallo nocheinmal,
P.S.: Bitte nicht vergessen, den Garbage Collector während der Messung abzuschalten.
Viele Grüße,
Andreas.
Korrekt, das müssen wir noch nachreichen.
@robert-hh was so kind to upload his improved 1-Wire/DS18X20 driver to a repository on GitHub.
This will enable us to contribute some minor improvements. Thank you so much!
Wir haben hierzu gerade noch entsprechende Eingaben gemacht.
Vielen Dank für Eure Rückmeldungen und Verbesserungsvorschläge dazu!
Finally, we have been able to make this work on Pycom MicroPython.
We have published respective firmware images called 0.7.0-vanilla-dragonfly-onewire. See also Inofficial firmware bakery for Pycom/ESP32 devices - #2 by Andreas.
Die Testhardware läuft ab sofort mit FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire, die Meßwerte können unter amo-fipy-workbench betrachtet werden.
Die Implementierung der Maskierung der 85°C auf Treiberebene geht u.U. doch einen Schritt zu weit:
@robert-hh said within #8:
In the new version I intentionally did not implement this test. 85°C is a valid result, which must not be suppressed by the driver. Checking must be done by the calling code, which knows the context.
I see your point here. Thanks!
