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.
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)?
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 ;)
“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
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.
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
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.
mit dem Kabel oder dem Anlöten einer Leitung + Schalter würde ich hinbekommen aber andere die schon ein Workshop hatten sicher nicht. war mir nur unsicher mit der gleichzeitigen benutzung der RGB und des Einganges P2.
Das Problem, was ich jetzt noch vermute/habe habe ist ein fehlendes timeout des AP nach z.B. Stromausfall. aber dafür ist der wdt auf 30 min zuständig oder?
Ich glaube das hatten wir bisher nicht wirklich berücksichtigt was nach einem Stromausfall passiert vs. nach einem reset. Andreas hatte mal versucht / überlegt über die restart cause eine Abzweigung zu realisierten:
Wenn per hardware reset, dann AP-Modus starten. Ansonsten (z.B. nach Stromausfall) hochfahren ohne in den AP zu gehen, fände ich sehr charmant, weiß nicht an was es dann gescheiterte ist oder nicht weiterverfolgt wurde.
Ich hab mal meine Router Daten angeben. Hatte ich bisher noch nicht gemacht.
WDT nach 30 Min scheint zu klappen
Wenn ich mir den Code so anschaue, ist auch nicht mehr drin, das der AP mode nach PWRON startet Er sartet aktuell nur, wenn er keine gültige WLan verbindung findet.
Die einzige Abfrage die den Boot status abfragt wird nur als Log ausgegeben.
Daher geht er jetzt natürlich nicht mehr in den AP-Mode.
Über die IP komme ich aus dem Netz leider auch nicht drauf wär natürlich Genial wenn das gehen würde ist aber sicherlich nicht mal so eben so umzuprogramieren. Da der Webserver und die Messung dann gleichzeitig laufen müßten
Idee: Nach Neustart nach Stromausfall startet der AP modus wenn ap_Button= false und wird nach 10 Min automatisch der FiPy widr dann über den WDT neugestartet. Die Box ständig aufzuschrauben wenn man was Ändern will oder muß.
was ich jetzt noch vermisse ist eine Prüfung der Verbindung wärend der Übertragung falls das Wlan mal abreißt und auch die Verbindung zu Beep wird anscheinend noch nicht weiter überwacht oder neu gestartet.
Tatsächlich ist es P2 und es überlappt mit der LED. Das ist ein bisschen unglücklich, vielleicht nutzen wir für zukünftige Versionen einen anderen Knopf/ Pin.
Ich hab das jetzt so gelöst, dass die LED die Farbe ändert, sobald der Start-Up-Prozess vorbei ist (von gelb auf grün). Danach wird der AP konfiguriert (nur konfiguriert, nicht in den Ap-mode gewechselt.) Ab diesem Zeitpunkt kann die LED nicht mehr angesteuert werden.
Ich habe jetzt nur mit Didis Platine getestet, vielleicht schließe ich gleich noch mal die von Clemens an.
Gute Idee, dann kommt man in den AP, aber nach Absturz kann trotzdem weiter gemessen werden
Stimmt, ich habe nie ohne Sensoren getestet, das sollte ich nachholen.
Puh, das freut mich!
Der Hauptzweck der Aktion war ja, dass das Webinterface stabiler wird. @MKO Läuft das Webinterface bei dir?
