Verbesserung der Stabilität der BOB-Firmware

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.

image

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

Ahh, ok doch der P2 (RGB) aber auf GND gezogen. Ich hatte ihn auf 3V3 versucht.

Bug in main.py für Button Mode=false auch gefunden. Irgendwie hackt git bei meinem commit.

Pull requests ist jetzt händisch auf git raus

1 Like

https://github.com/Hiverize/FiPy/blob/master/default_settings.json

"general": {
    "general": {
        "button_ap_enabled": true,
        "button_ap_pin": "P2",

Die default_settings.json ist identisch mit der Didi-Version, in der “Clemens” ist "button_ap_enabled": false,

pullup / pulldown brauchst du nicht, wir haben die intern per Software aktiviert, etwas Draht könnte reichen.

Wie gesagt läuft jetzt bei mir auch mit

"general": {
"general": {
    "button_ap_enabled": false,
    "button_ap_pin": "P2",

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?

1 Like

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. :roll_eyes:
Ü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ß.

oder schlagt ihr was besseres vor?

1 Like

So jetzt scheint es auch mit Clemens Platine nach power On zu klappen. Commit ist ebenfalls raus. Geht evtl. noch etwas schöner.

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.

Gruß Micha

1 Like

Danke fürs Testen und Mitcoden!!!

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?

Ja nach den von mir eingereichten Pull requests läuft es bei mir mit Clemens Platine. Vorher leider nicht, da bei der Platine kein Button vorgesehen ist.

Man sollte im Git in den default Settings den ap_Button meiner Meinung auch auf false setzen, so bekommen wir keine Probleme, falls ein etwas unerfahrener User mit Clemens Platine versucht selbständig zu Updaten. Und dann nicht mehr in den AP kommt.

Grüße

Ich bin bei dem Entwurf von BOB-HAT-Vx davon ausgegangen, dass mit Arduino-IDE UND MicroPython programmiert wird. Leider braucht die Arduino-IDE “P2” zum Flashen, daher liegt der Button “Flash” über dem Button “Reset” und ist an “P2” angeschlossen.
Das erklärt aber auch, dass ich RGB-LED nicht immer so programmieren konnte, wie ich wollte.

Auf dem Board gibt es aber noch die Buttons SW1 an “P16” ( kollidiert mit VBATT, für Tara vom HX711 vorgesehen ) und SW2 an “P14” ( für Scale vom HX711 ) und SW3 an “P13” ( Abgleich der DS18B20 ), Man könnte sie auch für den AP-Modus vorsehen.

Ja, ich fände es auch gut, einfach einen anderen Button zu nehmen.

@Diren Gibt es eigentlich immer noch weitere aktuelle Problemstellen? Das Programm lief das letzte Mal bei mir immer nur ein paar Tage am Stück problemlos und mußte dann neu gestartet werden.

Würde sonnst Mal wieder einen Langzeit-Test starten. Denke 7 Tage auf 2-3 Systemen müssen fürs erste reichen.

Und dann anschließend die Teilnehmer vom Hamburger Workshop einladen, um deren Systeme neu aufzuspielen.

Gruß Micha

1 Like

Hey @MKO,

unserer Erfahrung nach läuft das Programm jetzt sehr viel stabiler als zu der Zeit des Workshops in Hamburg. Trotzdem treten bei den Imkernden immer wieder Ausfälle auf, die wir hier nicht reproduzieren können. Wir testen auch nur mit Didis Platine.
Wenn du noch Langezeit-Tests machen kannst, wäre das genial!!!

Wir starten gerade eine Aktion, dass wir allen Imkernden einen geupdateten FiPy per Post zuschicken, damit wirklich alle die Updates haben.
Es wäre natürlich trotzdem cool, wenn ihr euch treffen könnt, und ggf. schon mal gemeinsam kalibriert, oder ggf. die user-settings gemeinsam rüberzieht.

1 Like

In der aktuellen Version im Git sollten nun folgende Fixes drin sein:

  • MKOs Pull request für die weiße Platine (Danke!)
  • FiPy misst auch ohne angeschlossene Temperatursensoren
  • SSID-Scan-Ergebnisse sind auch beim ersten Start im Webinterface verfügbar

Gerade hat sich mein FiPy noch mal selbst neu gestartet ohne zu verrraten warum, also es darf gerne weiter getestet werden :)

1 Like

Gut werde dann parallel mal schauen ob und wie ich Fehler provozieren kann.

Wie oben schon mal angedeutet z.B. WLAN Ausfall durch schlechtem Empfang/Router Reset/ Router reconect oder Ausfall/Wartung Beep-Server oder die Route dorthin.

Probleme durch Spannungsschwankungen Strombegrenzung en usw. kann ich auch mal testen.