Hallo,
anlässlich der Girld-Day Vorbereitung haben wir das Webinterface noch mal ordentlich getestet und festgestellt, das der FiPy beim Speichern der neuen Settings manchmal abstürzt.
Deswegen noch mal die Frage in die Runde: Habt ihr Ideen, woran das liegen könnte?
Es handelt sich um die neu geflashten FiPys mit der Pycom-Version von Andreas und dem aktuellen Code von hiverize.
Viele Grüße,
Diren
1 Like
Auch ich hatte im Dezember so meine Probleme mit dem Webinterface und daher nur noch im user_settings.json editiert.
Die neuen Onewire-Treiber konnte ich noch nicht einbauen wg. fehlender Programmierkenntnisse.
@MKO hatte in den Code geschaut und etwas gefunden, bei mir war es schon immer so mit der Instabilität!
Hi Diren,
versuche doch einmal [1] auf Basis des neuen Pycom Firmware Release 1.20.2. Wenn Du damit Core Dumps abgreifen kannst, könnten wir der Angelegenheit u.U. besser auf den Zahn fühlen.
Viele Grüße,
Andreas.
Leider habe ich weder Zeit und Gelegenheit mir das ganze nochmal anzuschauen.
Soweit ich mich erinnere, war da ein Syntax Fehler in der Abfrage, ob der AP oder STA Mode aktiv ist. Und die Abfrage gab egal welcher Mode aktiv war immer das selbe Ergebnis raus.
Und der AP Mode wurde, gerade im Button Mode, ständig neu in gestartet.
Ob das ganze Aktuell noch drin ist, kann ich allerdings nicht sagen. Habe den Code auf Git jetzt nur überflogen.
Main.py Zeile 184 fehlen da hinter _wlan.mode nicht die Klammern wie in Zeile 222 ?
Gruß Micha
1 Like
Stimmt danke, die Klammer fehlt.
Die Abfrage ist meiner Einsicht nach richtig.
Mir ist aufgefallen, dass die Konfiguration am Anfang – nach dem Start des AP – recht flüssig läuft und dann immer zäher wird, auch die Responszeiten, z.B. die Anzeige der aktivierten / gespeicherten pins oder bereits eingegebener Werte wird gefühlt immer länger, gemessen habe ich bis zu 20 Sekunden. Das würde dazu passen, dass irgend was voll läuft oder re-started wird.
Bei der Konfiguration der letzen Systeme habe ich für eine komplette Einrichtung (WLAN, Waage, Brutraum-Temperatur) ca. 10 restarts des Systems gebraucht. Siehe auch
https://community.hiveeyes.org/t/test-szenarien-bob-software-2019-12/2844/5
Soweit ich mich Erinnere gab es auch Probleme mit dem erkennen, ob der Webserver gestartet ist. Ich hatte mich damals hauptsächlich mit dem nicht funktionierendem Button mode beschäftigt kann daher nicht sagen, ob es im “normalen” Mode genauso ist.
auch wird Loop_run im Button Mode gestoppt und die Main.py wird dadurch beendet.
190: if not webserver.mws.IsStarted():
Gab bei mir immer ein true raus.
und der Webserver wurde versucht mehrfach zu starten.
Hatte da auch noch einige für mich nicht ganz nachvollziehbare Abfragen und
merkwürdiges verhalten in der Firmware/Webserver/Vue gefunden.
Habe dann aber irgendwann den Faden/Zeit/Ruhe dabei verloren.
Bin aber auch eher versierter Anwender als Programmierer und Python habe ich schon seit 10-15 Jahren nicht mehr wirklich benutzt.
Hatte aber auch gedacht die Entwicklung geht eh eher in Richtung hiveeyes-micropython-firmware, da ich persönlich finde das es einiges professioneller und stabiler aufgebaut ist. Aber da wird ein captive portal anscheinend immer noch von niemandem angegangen.
Er stürzt übrigens schon einiges vorher ab, bzw. reagiert nicht mehr schnell genug, daher auch keine aktuellen Daten von den Sensoren. Dieses fällt allerdings solange nicht auf, bis man Speichert. Als kleinen Trick kann man die Daten im Webinterface ändern und kurz vor dem speichern den FIPy neu starten.
Komme leider erst am Wochenende wieder nach Hause. Werde mal schauen ob ich den Faden wiederfinde.
Gruß Micha
1 Like
Hey,
danke für die ganzen Ideen!
Ich glaube ich konnte tatsächlich ein paar Bugs fixen:
- die messwerte werden nicht mehr geladen, wenn die seite schon gewechselt wurde
- mehr garbage collection im webinterface findet statt
- wenn eine neue anfrage an messwerte geschickt wird, wird die alte gecancelt
- das mess-interval insgesamt ist länger, damit genug zeit zum auslesen ist
Außerdem neu drin:
- die ds treiber von didi (Vielen Dank! Ich hoffe ich hab alles richtig eingebaut)
- die led leuchtet erfolgreichem startup grün (so kriegt man mit, wenn er abstürzt, dann ist sie wieder gelb)
known issues:
- ssids werden im webinterface erst nach 2. restart angezeigt (hab schon eine idee woran es liegt, schaffe es aber vor dem wochenende nicht mer)
- vielleicht immer noch memory leaks
Vielleicht habt ihr ja Lust zu testen.
Ich hoffe, ich hab alles nötige ins Repo gepusht.
lg
Diren
1 Like
Vielen Dank @Diren! Habe jetzt mit verschiedenen firmware-Versionen getestet,
- der “alten” von Andreas FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
- der “neuen” FiPy-1.20.2.rc3-0.8.0-vanilla-squirrel.tar.gz
- und auch der offiziellen 1.20.2.rc3
bekomme aber jedesmal eine Fehlermeldung, die den Treiber der DS18B20 betrifft:
init ds
Traceback (most recent call last):
File "main.py", line 14, in <module>
File "webserver.py", line 9, in <module>
File "sensors/__init__.py", line 23, in <module>
File "sensors/ds18x20.py", line 22, in convert_temp
File "lib/onewire.py", line 22, in reset
OneWireError:
Pycom MicroPython 1.20.2.rc3-0.8.0-vanilla-squirrel [v1.20.2.rc3-4-g4962aea3b-dirty] on 2020-02-11; FiPy with ESP32
Type "help()" for more information.
>>>
bzw.
ImportError: no module named '_onewire'
Pycom MicroPython 1.20.2.rc3 [v1.11-2037465] on 2020-02-05; FiPy with ESP32
Fehlt da noch was / ist noch etwas nicht upgedatet worden im GIT-Repo (Stand 2020-02-14, ca. 21h)?
Hi Clemens,
ich benutze auch ‘1.20.1.r1-0.7.0-vanilla-dragonfly-onewire’. Hab gerade noch mal neu gepullt, alles erased und neu geflasht, kriege aber den Fehler nicht. Wenn du magst überlegen wir Montag gemeinsam, was das sein könnte, am Wochenende übernehme ich keine Garantie ;)
Viele Grüße,
Diren
“Erase all” habe ich nicht gemacht, da auf dem FiPy vorher die 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire drauf war. Habe den flash-Bereich des FiPys dann nur über das Windows-Tool gelöscht, was ja schon manchmal nicht gut ging. Vielleicht liegt es daran! Ok, versuche es nochmal mit “erase all” vorher! Alles weitere dann Montag! ;-)
Ich glaube nicht, dass es an der Firmware / Micropython von PyCom liegt. Ich hatte auch Probleme mit Exceptions, die in onewire.py bei einem CRC-Error entstanden. Als ich die nicht richtig abgefangen hatte, war mein System instabil und rebootete andauernd.
Siehe
Hier könnte es ähnlich sein
Hmm, @didilamken ich dachte @Diren hätte deine Änderungen schon im aktuellen code drinnen. Bei mir läuft es auch nicht instabil, sondern gar nicht … Leider keine Besserung mit “erase all” vorher, gleiche Fehlermeldung:
File "lib/onewire.py", line 22, in reset
OneWireError:
Ok, in lib/onewire.py
def reset(self, required=False):
reset = _ow.reset(self.pin)
if required and not reset:
raise OneWireError
return reset
Der versucht also ein reset, das kann passen, da ich gerade gar keine Sensoren angeschlossen habe! In der letzten Version lief der sketch auch durch ohne angeschlossene Sensoren, das wird es sein! Dann mal mit versuchen …
Wunderbar @Diren, mit angeschlossenen Sensoren läuft es! Ein Traum das Webinterface nun im Gegensatz zu vorher!! Kein einziger Totalabsturz, komplette Konfiguration läuft nun ohne erzwungenen restart! Man kann sogar zwischendurch sich mit dem “richtigen” WLAN verbinden, dort den beep sensor key erzeugen und wieder zum FiPy-AP reconnecten! Fantastisch!
In Osnabrück an der Uni war der Girl’s Day immer vor allem mit Arbeit verbunden, “In die Zukunft investieren”. Hier ist es aber ein echter Innovationsschub für BOB! ;-)) Endlich läuft das webinterface stabil! Ick freu’ mir!
Die Verbesserung in den Treibern ist wohl das Abfangen von Fehlern mit raise exception.
Vor Monaten wurden im Onewire-Treiber CRC-Fehler einfach ignoriert und es gab falsche Bits,die zu den merkwürdigen Messwert-Ausreissern führten, über die so lange diskutiert wurde.
Jetzt wird mit einer Exception auf CRC-Fehler reagiert. Wird die nicht sauber abgefangen, beendet das Programm und der Watchdog bootet neu. In den Messdaten auf dem Server bekommt man davon nichts mit, erst auf der seriellen Leitung sieht man etwas.
2 Likes
Hab auch mal versucht zu testen.
komme irgendwie nicht weiter.
Bei mir wird der AP nicht gestartet.
Den FiPy habe ich vorher über Command line mit dem Update tool gelöscht
Firmware:1.20.1.r1-0.7.0-vanilla-dragonfly-onewire
und
und die Firmware ist frisch von Git geladen. Die user_settings.json und default_Settings sind auch aus dem Git.
Überspielt habe ich mit Visual Studio und Pymakr Plugin.
Die RGB leuchtet erst einige sekunden gelb dann grün.
Über Serial kommt unter anderem folgendes
AP SSID: Moltebeere
Cause of restart: PWRON
switching to ap mode is now possible
Starting measurement setup...
WLan is enabled, trying to connect.
No WLan connection configured!
No WLan connection configured!
No WLan connection configured!
No network connection.
DS18B20: Messung gestartet...
DS18B20: 19.6 19.6 17.0 18.8 16.3 18.6
{'weight_kg': -68312.0, 'p': 990.4699, 't': 22.26076, 'h': 49.43261}
stack: 896 out of 11264
danach laufen die Messungen.
getestt habe ich ebenfalls mit einem weiterem FiPy und
1.20.2.rc3-0.8.0-vanilla-squirrel
Auch habe ich es über den button mode Versucht aber dort kommt eine Fehlermeldung mit Programmabruch
Ne Idee was ich vergessen/Übersehen haben könnte?
1 Like
Habe mit der Platine von Didi getestet und da gibt es einen dezidierten button um in den AP-Modus zu wechseln.
Dann habe ich den Button Mode doch richtig herum verstanden true = Didi und false = Clemens ;-)
also false bricht ab.
OK Dann geht es mit deinem Layout noch nicht.
An welchen Pin hängt der Taster Bei Didi? an P2 kanns ja wegen der RGB nicht sein.
hatte vorhin pin3 mit Vorwiederstand aber ohne pullup/pulldown Wiederstände Versucht.
bin jetzt am überlegen, ob ich mir nen Taster und Wiederstände zusammenbastel oder ob ich den Button=false Mode nicht irgendwie zum laufen bekomme.
Also erstmal stand Git
dann nach den gefundenen ssid das hier.
Es ist der Button “Flash” ( braucht man bei Arduino-IDE zum Flaschen, braucht man nicht für MicroPython). bei Hiverize/FiPy für AP-Modus