Er meldet zwar im Terminal, dass er einen Fehler bei WLAN hat, jedoch verbindet er sich vollständig.
Ich kann ja den FiPy pingen und auch in den paar Sekunden in denen er verbunden ist das Web-Interface öffnen…
An den Sensoren liegt es nicht.
Habe auch schon den FiPy ausschließlich mit Expansionboard versucht zu starten. -> Selbes Verhalten.
Ich checke das und danke für die Links zu der Doku!
vielleicht sollte der Doku Link mal in eine Readme.md auf dem GitHub project gekippt werden
Sind euch “Probleme” bekannt, wenn ein WLAN die selber SSID für 5GHz und 2,4GHz verwendet?
Meine SSID ist in den available WLAN zwei mal vorhanden, wegen unterschiedlicher Frequenzen.
Ich konnte die user_settings.json editieren.
Mal ne blöde Frage: Ich hab das jetzt über die Python Console gemacht. ist also etwas umständlich.
Ist das der “einfache” weg?
Es gab mal einige Probleme mit einigen Fritzboxen und den Connection Timeout (muß dann etwas höher gestellt werden) einige Router antworten irgendwie nicht schnell genug. findet man glaube ich unter General Settings.
Das 5 gHz Netzwerk bekommt der FiPy gar nicht mit.
Wenn er das Webinterface öffnet kann man immer noch Daten Ändern und speichern. Mann muß nur den Zeitpunkt Abpassen wenn gerade der FiPy eine neue Verbindung aufgebaut hat.
Der Einfache Weg, ist meiner Meinung nach über Atom oder Visual Studio Code mit PyMakr Plugin.
Da bekommst Du automatisch ein REPL und Zugriff aufs Dateisystem.
Du scheinst schon Recht gute Kenntnisse zu haben, wenn Du später Mal Lust auf mehr hast, solltest Du darüber nachdenken, zur alternativen Terkin Firmware zu wechseln.
Ja ich bin Entwickler und auch recht viel mit Python unterwegs. Aber bis jetzt nicht mit der pycom architektur oder mit MicroPython gearbeitet.
Und auf Grund der - sagen wir verstreuten doku - ist das finden der infos schwer, wenn man nicht genau weiß wonach man sucht ;-)
Das ist leider wahr ;]. Wir müssen hier endlich mal mehr Struktur reinbringen. Ich hoffe Du findest Dich trotzdem zurecht, die richtigen Juwelen auszugraben.
Auch dort wirst Du direkt fündig:
Terkin ist ein MicroPython-Datenlogger, der gemeinsam mit @einsiedlerkrebs, @poesel, @Thias, @clemens, @MKO, @tonke, @weef, @wtf und @roh entwickelt wurde. Diese Gerätschaft erschließt die Hardware des FiPy etwas mehr, unterstützt z.B. auch LoRa und Cat-M1 über das Sequans Modem und läuft sogar auch auf CPython. Terkin wurde primär zur Datenübertragung an Kotori ausgelegt, kann aber auch zur BEEP Software funken.
Tatsächlich konnte ich bisher keine Problemlösung finden.
Ich habe zwei Unifi AccessPoints für mein WLAN hier, welche die selbe SSID für 2,4 und 5 GHZ verwenden. Beide haben natürlich die selbe SSID.
Ich vermutete, dass die beiden Netze oder die beiden AccessPoints ggf. das “Problem” sein könnten. Könnte immer noch am WLAN liegen, aber ich glaube es nicht.
Auch bei nur einem aktiven AP schlägt vermutlich der WatchDog zu.
Basierend auf dem Souce Code würde ich sagen, dass der FiPy das erste mal sich nicht verbinden kann und deswegen einmal WLan connection failed, retry... in die Console schreibt, aber es bei zweiten Versuch schafft, sonst würde das bis zu 3 mal schreiben.
Nun wäre die Frage, oder meine nächsten Schritte beim Reversen, wann und warum der WatchDog einen Reset auslößt.
Da ja derzeit der Server von Bee-Observer nicht funktioniert konnte ich auch noch kein gültiges Konto einrichten auf dem FiPy.
Jetzt wollte ich mal schauen, ob bei nicht richtiger Anmeldung der Watchdog ggf. auch auslöst. Das wäre dann ein recht “dummer” Fehler von mir ;-)
Schön wäre es auch, wenn der WatchDog erstmal was in die Console feuert, bevor der Reset gemacht wird.
Ich habe das Problem mit der Bootschleife gefunden.
Der SW1 ist entweder falsch vertratet oder falsch programmiert.
Sobald in der user_settings.json die Einträge zu den WLANs und Co enthalten sind, startet der FiPy ja normalerweise in seinen “Messmodus”.
Mit den aktuellen boards ist es aber so, dass diese dann nach dem Boot in the AP modus wechseln, jedoch nach initialer Aktivierung des WatchDogs. Dieser Zustand führt dann, da im AP Modus der Watchdog nicht länger gefüttert wird, dazu, dass der FiPy nach ca. 10 Sekunden reseted wird.
kann man an dieser Meldung sehen: Called. Pin Pin('P16', mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).
Ich würde sagen, dass hier das “PULL_UP” falsch ist. dadurch funktioniert der FiPy entweder, wenn der PIN auf "button_ap_pin": "P2" geändert wird in den settings, oder man ihn gedrückt hält.
Mit der Änderung auf P2 muss man dann natürlich wieder den Flash Knopf Brücken um in den AP-Modus zu kommen, wie im letzten Datentreffen erwähnt.
Ich schau mal ob ich die Stellen im Code finde und fixen kann.
Ich würde dann einen PullRequest nach GitHub machen.
Ist einer der Maintainer der FiPy Firmware hier im Forum anwesend?
Auf der Platine ist SW1 bestück und der R4 daneben, oder?
Nur der Pin der mit dem Flash-Button verbunden ist hat einen aktivierbaren pull up, der P16 hat gar keinen internen pull up, den man aktivieren könnte, daher müssen wir den mit dem R4 extern bestücken.
Ja ich hab mich geirrt. Das PULL_UP war nicht das Problem.
Das Problem war, dass die CallBack zu früh im Process registriert wurde und dadurch während der “Startphase” schon ausgelöst wurde.
Ich habe das registrieren der CallBack an den Start der start_measurement() Funktion verschoben.
Dann funktioniert es wie es soll.
Ich hab einen PullRequest auf GitHub erstellt.
Ich hätte auch Interesse den Code mal ein wenig… aufzuräumen.
Ist etwas inconsistent und die Python Pep8 werden auch nicht wirklich befolgt.
Falls etwas “Refactoring” gewünscht ist, hätte ich da lust drauf.
Mir fällt gerade noch ein, dass wir zu Projektstart im Hamburger Workshop Platinen komplett ohne AP-Button hatten und @MKO den code so angepasst hat, dass nach einem Reset? / Neustart (?? ich weiß nicht mehr, ob power cycle oder reset gereicht hat) den AP-Mode gestartet hat und der dann nach einer Zeit auch automatisch verlassen wurde. Vielleicht magst du @MKO nochmal schauen, ob der fix von @snooz bzw. der bug was damit zu tun hat.
Ich denke grundsätzlich wäre es eine gute Idee, dass der FiPy, falls er sich nicht in ein WLAN einloggen kann, den Access Point öffnet.
Und, wenn der FiPy mit dem WLAN verbunden ist und der Button gedrückt wird, der Webserver startet. So, dass man aus dem eigenen Netz auf die Konfig kommt.
Zum Access Point könnte man dan lange drücken.
Auch finde ich, dass die LED zu wenig infos zeigt.
Keine “Blinkcodes” und der eigentliche Status ist auch nicht so wirklich zu sehen.
Ich habe zwar seit 2 Monaten nichts mehr gemacht, aber hier sind meine bisherigen Programme.
Überarbeitet habe ich die Sensoren wie DS18B20, BME280, HX711, die RTC DS3231 und den Stromsensor INA219.
Noch nicht angefasst habe ich den WLAN-Manager mit der Umschaltung von Client zu AP und die ganze Konfiguration WiPy1-Strom-V2b.zip (55,9 KB) WiPy2-Mess-V2.zip (137,3 KB)
Super vielen Dank für deinen Bug-Fix! Ich konnte es gerade testen auf einem FiPy der mit dem gleichen Problem zu mir zurück gesendet wurde. Ich werde den Pull-Request heute noch bestätigen.
Wir würden uns sehr freuen, wenn Du am Code weiterarbeiten möchtest!
Ich denke es ist gut, neuen Code immer ausführlich zu testen (siehe das Boot-Loop Problem, da haben wir eindeutig nicht genug getestet, als wir die Positions des Buttons geändert haben). Vielleicht finden sich hier aber auch noch ein paar weitere Leute, die testen würden. Wenn du nur ein bisschen Refactorings machst, ist das sicherlich keine Problem, aber bei größeren Änderungen wäre das besser.
Moin @snooz soweit ich mich entsinne gibt es da ein Problem mit der Pinbelegung und Der RGB. P2 wird bei zumindest bei Der Weißen Platine noch für den AB Modus genutzt und sobald der interupt eingerichtet wird ist die LED außer Funktion und kann nicht mehr genutzt werden. Ich hatte mal versucht die LED und interupt nach dem Startvorgang wieder zurückzuseten, aber ohne Erfolg.
Etwas hatte ich da im Kamerun Branch schon gemacht allerdings entsinne ich mich nicht mehr genau was. Und mir fehlt aktuell die Zeit mich darum zu kümmern.
@MKO
Ja mit P2 geht die LED nicht, daher wurde jetzt ja auch P16 umgestellt.
Ich würde mich jetzt auch zum Thema LED eher auf P16 konzentrieren.
Das mit dem Testen ist natürlich so eine Sache.
Ich hab jetzt meine beiden FiPy in Betrieb genommen und will diese Daten nicht mit Tests versauen.
Ich habe jetzt mal zwei WiPy bestellt, aber die wollte ich auch an weiteren Völkern mit selbst gekauften Waagen montieren.
Wenn ich ein Kit zum Testen hier hätte, könnte ich das damit natürlich machen. @Diren
Wenn die beiden WiPy hier sind, wollte ich mich nochmal dran setzen.
Gruß
Beim Booten wird der Startgrund ermittelt. Wenn es ein kompletter Neustart (stromlos) ist, muß er ebenfalls im AP Modus starten, da diese Variante keine Buttons hat.
Ja genau. Wenn dieser Konflikt u.U. durch eine entsprechende Konfigurationseinstellung gelöst werden könnte, à la board_variant = "green|white", wäre das vermutlich praktisch? [1]
Viele Grüße,
Andreas.
Ich stecke hier nicht genau drin, weil ich eher für die andere Datenlogger-Software GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. zuständig bin, daher kann ich nicht einschätzen, ob hier eine generische Lösung möglich ist, ohne diesen zusätzlichen “Modus” einzuführen. Nimm daher bitte meinen Kommentar “with a grain of salt”. ↩︎
Soweit mir bekannt ist nicht. Kommt natürlich darauf an, wie weit du in die Firmware eintauchen möchtest.
Fals Du z.B. beim Webinterface ran willst/musst, es ist in Vue geschrieben Du findest es unter GitHub - Hiverize/Webinterface. Ein ändern direkt im Code ist nicht nur kompliziert sondern auch nicht besonders nachhaltig.
Und das Pycom-Micropyton hat immer noch ein paar echt fiese Fallstricke was Deepsleep und Lightsleep angeht, da würde ich an deiner stelle eher etwas vorsichtig sein. In der Kamerun Firmware habe ich z.B. versucht mit Lightsleep und aufwach Interupts zu arbeiten was aber zu ständigen Programmabstürzen geführt hat oder die Interupt Buttons wurden danach im Wachzustand nicht mehr ausgelöst.
