Zu diesem Thema lief uns gerade noch die esponewire.c für ESP32 aus dem ESP32-Port des aktuellen Genuine MicroPython über den Weg, die dort timing-kritische Dinge maschinennah implementiert – gerade das Lesen und Schreiben von Bits auf den Bus und die Einhaltung des Protokolls und der Contenance.
Dass diese Angelegenheit beim Pycom MicroPython in pure-Python per onewire.py implementiert ist, mag man zwar fast nicht glauben , zeigt aber umso deutlicher, dass diese Geräte vom Hersteller nicht unbedingt dafür ausgelegt wurden, Meßdatenlogger zu sein, sondern eher, um ihren Dienst als universelle Telemetriemodembausteine zu tun.
Auch hier wäre es nett, wenn wir bei Gelegenheit auch auf die maschinennahe Programmierung der Pycom-Geräte zugehen würden. Vielleicht ist es machbar, fehlende Funktionalitäten ggf. selbst nachzurüsten.
Genau. Irgendwann werden wir das machen und können uns dann vielleicht bessere Sachen zusammenklauben.
Ja, gerade dieses Beispiel spricht schon Bände darüber, dass das bestimmt nur eine notdürftige Lösung war, weil der echte ESP32-Port in dieser Zeit vermutlich noch gar nicht ordentlich fertig war.
Hier noch ein paar Fundstücke, die teils die bereits hier erforschten Dinge widerspiegeln, aber auch in einem weiteren patch von @robert-hh auch noch CRC-checks mitbringen – die gibt’s in der aktuellen Variante noch nicht.
git pull
make setup
make install
# oder
make recycle(-ng)
der Bibliothek ein Stück näher.
Bei mir konnte ich feststellen, dass manchmal von einem der beiden Sensoren kein Ergebnis zurückkam. Zusammen mit den nun eingeführten CRC-Checks würde ich das als »considered to be a good thing™« betrachten – weil es u.U. genau jenen Fall widerspiegelt, wo bisher Glitches bei der Messung übernommen/durchgereicht/nicht weggefiltert wurden, obwohl sie inkorrekt gelesen wurden.
Wir freuen uns über Eure Erfahrungsberichte – vorzugsweise mit längeren Testzeiträumen.
Gut werde meinen Teststand nochmal neu starten. Hab Ihn gerade mit der Firmware von gestern Nacht am laufen. Im Gegensatz zur Org. 0.5.1 ein deutlicher Rückschritt habe ca alle 10- 20 Messungen einen Glitch.
Auf nahezu allen DS 1820 Sensoren geht wie bei 0.5.1 von ein paar Grad Abweichung bis zu 534°C alles vertreten. Ausbleiben einiger Werte von DS1820 Sensoren konnte ich auch schon sehen.
Ok, schade! Um sicherzugehen: Löschst Du vielleicht gerne kurz Deinen dist-packages Ordner komplett und holst Dir die Inhalte erneut per make setup? Better safe than sorry…
An jenem Gerät bei Labor / FiPy Workbench 01 sind zwar Sensoren angeschlossen, allerdings wird dort bisher nur selten bis kaum konkret auf die Werte geschaut.
Bei den Aufzeichnungen gibt es viele Lücken, weil es recht häufig recycled wird. Daher sind die Aussetzer (bei allen Sensoren) der Betriebsweise geschuldet.
Frage an die Grafana-Spezis: Würde man solche Ausreißer durch Glitches gegen 451°F oder darüber hinaus nicht auch hier bei min/max in der Legendentabelle von Grafana zu Gesicht bekommen, um eindeutig mit dem Finger drauf zeigen zu können?
Das einzige “Misreading” sehe ich oben bei system-temperature. Das war aus der Zeit, in der wir mit dem Voltage Divider und der Ansteuerung des ADC beschäftigt waren.
Neue Version mit CRC-Checks allerdings noch ohne die letzten beiden commit bezüglich der Rückstellung der Timings der Ds1820.
2 Fehler allerdings einer auf 0 hatte ich bisher noch nie das einer nach unten ausgeschlagen hat
Ich habe jetzt nochmal ein Git Pull gemacht und vorher den den Fipy und und den dist-packages Ordner gelöscht.
3:18 Uhr mal schauen was Jetzt raus kommt
Edit: Schaut jetzt wieder viel ruhiger aus. Aktuell noch kein Fehler seit dem.
Allerdings gab es in den 432 Messungen 128 mal keine Daten von einzelnen oder mehrerern Sensoren. Was aber vergleichbar mit dem Org. 0.5.1 ist.
Was schließen Ich daraus? das Timing um die Wartezeiten sind extrem wichtig. Und wir sollten dort nur langsam dran drehen. gibt also auch ein zu lange warten.
Hi Didi,
ist mit Grafana erstellt. Die hiveeyes-micropython-firmware kann zusätzlich auch zu swarm.hiveeyes.org per MQTT übertragen. Das kann die hiverize/FiPy leider (noch?) nicht.
Lasse dort nur Datenpunkte und keine Linien anzeigen.
Mitteln tut Grafana auch allerdings auch, aber nur wenn man größere Zeiträume über ein Tag betrachtet.
Bei unter 20h zeigt er bei mir die Echtdaten kann auch sein das er nur eine maximale Datensatz-zahl darstellen kann und dann mittelt.
Auf alle fälle ist Grafana viel besser zur darstellung und analyse der Daten geeignet, da man beliebige Zeitabschnitte betrachten und einstellen kann.
Hoffe das ist mit Andreas Änderung nun wieder besser, hatte mit der alten Version bei ca. 1300 Datensätzen und 5 DS18B20 nur um die 20 Ausfälle – dann fast immer der ganze bus!
, zeigt aber umso deutlicher, dass diese Geräte vom Hersteller nicht unbedingt dafür ausgelegt wurden, Meßdatenlogger zu sein, sondern eher, um ihren Dienst als universelle Telemetriemodembausteine zu tun.
