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. 
Ü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.
Was ich gestern schon getestet habe: Bei einem Wegfall der Konnektivität / keine WLAN zeigt der FiPy das schön per LED an (springt dann wieder auf gelb) und reconnected sich auch sobald der WLAN-Router wieder “da” ist. Hatte gestern mal die FritzBox ausgestöpselt und nach ein paar Minuten wieder eingeschaltet, das machte dem BOB-System keine Probleme.
Ich hatte nach einem CRC-Fehler mit Exception in onewire.py noch eine Exception bei der Ansteuerung des OLED-Displays, die ich ( noch ) nicht erklären kann. Ich kann sie aber abfangen. Evtl. gibt es noch weitere Fälle.
Ich bin leider noch nicht dazu gekommen, die neueste Variante zu testen. Die älteren Varianten laufen seit Wochen auf 2 FiPy im Dauertest.
Habe ich auch gerade getestet. Dann wird sofort der Watchdog aktiv. Im Button mode=false. Fällt er jetzt in den AP Mode. Das hatte ich nicht bedacht. Da der dann für die WDT Zeit = 30 Min praktisch schläft.
Bei guter Verbindung sicher kein Problem, da es nicht so oft vorkommen sollte. Bei schlechtem Empfang wohl sehr kontraproduktiv.
Da der AP after PWR on aber gut funktioniert. Sollten wir ihn daher bei keiner Verbindung rauswerfen.
Einen Abriss der Internet Verbindung bei weiterhin stabilen Wlan wird zwar nicht bemerkt, aber es wird nach Wiederaufbau einfach wieder weiter übertragen. Einen Wechsel der IP Adresse kann ich dabei aber leider nicht simulieren.
Spannungsschwankungen haben bisher keine größeren auswirkungen.
@Diren bei deinem letzten Commit
ist glaube ich noch nicht alles mitgekommen.
Da fehlt bestimmt noch ein bischen code in der config.py
Läuft bei mir leider nicht:
Starting boot process...
Boot finished.
CSV Logger failed. Is a SD card inserted?
init sensors
init ds
No DS1820 found. Is it connected properly?
Gain & initial value set
BME280 initialization failed. Is it connected properly?
Traceback (most recent call last):
File "main.py", line 14, in <module>
File "webserver.py", line 12, in <module>
AttributeError: type object 'Config' has no attribute 'getInstance'
Pycom MicroPython 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire [13d82ea5-dirty] on 2019-11-17; FiPy with ESP32
Oben die Fehlermeldung ohne angeschlossene Sensoren, mit kommt die aber auch.
ohha, ihr habt Recht, tut mir Leid, ich hatte vergessen die config zu pushen. Ich hoffe jetzt geht’s.
2 Likes
Merci, läuft jetzt!