Wie genau soll eigentlich das Verhalten bei fehlender Konnektivität sein?
Während der Messung geht die Verbindung kaputt → der FiPy misst weiter, (speichert alles auf SD) und versendet wieder sobald das WLan wieder da ist
Das heißt ja, dass sich der FiPy bei dir neu gestartet hat? Das sollte ja eigentlich nicht notwendig sein
beim Starten kann keine WLan-Verbindung aufgebaut werden → Der FiPy fängt trotzdem an zu messen, (speichert auf SD) und versucht alle x Minuten sich neu zu verbinden? Wie groß ist x?
in der Config ist angegeben, dass eine Antenne benutzt werden soll, aber eine Verbindung ist nicht möglich → Soll der FiPy die Verbindung ohne Antenne probieren?
Kennt ihr Referenzprojekte, in denen der Versand opportunistisch läuft, bzw. kann die hiveeyes-Variante das vielleicht schon? D.h. Daten werden gesendet, sobald WLan wieder da ist.
Gibt es eigentlich hier eine Person, die schon Erfahungen mit dem Praxiseinsatz der Antenne hat?
@Diren
Wenn das W-Lan wegfällt, dann wird der WDT aktiv und startet den Fipy neu. Ist meiner Meinung keine schöne Lösung, aber sie funktioniert wenigstens.
Zeit ist die eingestellte WDT Zeit.
Wie oben schon geschrieben gibt es da noch ein Problem mit dem Programm wenn ap_button=false aktiviert ist. Er Startet neu, findet wiederum keine Verbindung und startet dann den AP für 30 min. Also wiederum 30 min Funkstille. Diese Funktion sollte wieder raus.
Wenn W-Lan verbunden, aber Internet gestörtist , passiert nichts, die Messung läuft einfach weiter und sie werden nicht Übertragen. Wenn die Störung beseitigt ist sendet er nur die aktuellen Daten.
Auch nicht schön, aber wenigstens geht es problemlos weiter.
Die Daten Zwischenzusprechen und bei neuer Verbindung als Paket zu übertragen wird nicht so einfach sein. Die micropython-Firmware kann das aber meines Wissens auch noch nicht, es wurde diesbezüglich aber schon einiges diskutiert und evtl. sogar vorbereitet.
Stichwort: Stromsparen- Sendezyklus alle X Messungen @Andreas könnte sicher mehr dazu sagen. Mann müsste die Datensätze auf SD Speichern und mit gesendet bzw. Nicht gesendet markieren.
Mit der Antenne wollte ich heute Abend mal probieren wie es läuft. Allerdings wird die Empfangsstärke nicht mit zu Beep übertragen, so kann man nur durch experimentieren herrausfinden, ob die Antenne auch was bringt, bzw ob er sie überhaupt nutzt.
Die Konfiguration im AP-Modus läuft bei mir sehr flüssig. Sehr gut sogar.
Allerdings werden die Exceptions nach CRC-Error in ds18x20.py noch nicht gut abgefangen, so dass das Programm endet, ohne den Datensatz gesendet zu haben.
Der Watchdog bootet dann neu und misst und sendet weiter. Es fällt kaum auf, nur die Variable cycle auf dem OLED-Display fängt von vorne an und wird nie richtig gross.
Auf der Weboberfläche fallen die ausgefallen Datensätze überhaupt nicht auf.
Ich arbeite an dem Problem. Heute abend geht es weiter.
Nur als erster kurzer Hinweis: Ich hatte zwar das expansion board angeschlossen, aber keine SD-Karte drinnen, ggf. ändert das auch noch etwas.
Zwischenpufferung von Daten und Versenden nach einer erneuten WLAN-Verfügbarkeit haben wir afaik noch nicht, die hiveeyes-firmware hat es auch noch nicht implementiert.
Wie oben beschrieben sind WLAN-Abbrüche zumindest fürs Wiederanlaufen kein Problem bei mir.
Puffern und nach re-connect die alten aufgelaufenen Daten schicken und gleichzeiig messen und auch diese Daten verschicken stelle ich mir bei unserem akteullen Messinterval von einigen Sekunden schwierig vor, wenn da das WLAN mal einen Tag nicht läuft kann ich mir nicht vorstellen, dass der FiPy parallel das alles abarbeiten kann, und ein Ausfall von ein paar Messzyklen wäre vermutlich zu verschmerzen … Ich denke die (Zeit-)Kosten für die Implementierung in Relation zum Nutzen sind etwas hoch!
Stimmt MKO und Clemens, war mir gar nicht aufgefallen, dass er manchmal neu startet. ich hatte auch schon mehrere Fälle, wo er einfach weitergemessen hat.
Sind wir uns sicher, dass er in diesem Fall zuverlässig reconnecten kann, wenn das WLan wieder da ist? Bei Clemens scheint es einmal funktioniert zu haben, aber ich sehe das noch kritisch.
Kannst du dafür einen Pull-Request stellen/ Nochmal genau erklären, wie es sein soll? Ich bin gar nicht mehr im Denken für die weiße Platine drin.
Wäre es eine Option einfach ganz auf die grüne Platine zu wechseln?
zusammengefasst aus euren und Didis Beiträgen, wären also folgende Implementierungen cool, falls möglich?:
wenn es keinen Button gibt, sollte der FiPy nicht bei jedem WLan-Ausfall 30 Minuten im AP hängen
Exceptions nach CRC-Error abfangen (Didi ist da dran)
Kleiner Tipp: Statt ds18b20tmp = 999999 einfach continue machen. Es gibt aus meiner Sicht keinen Grund, an dieser Stelle künstliche Werte zu erzeugen. Bei der Auswertung der Exception gilt das gleiche.
Das gibt Probleme bei der späteren Verarbeitung des Wertes:
ds18b20tmp = None bei print() und speichern auf SD-Karte
ds18B20tmp = 999999
ds18b20tmp = 9999 ist im Datenfile gut zu erkennen , sieht aber in gnuplot nicht gut aus
ds18b20tmp = 15.0 habe ich im folgenden Bild benutzt
Genau, einfach weg damit. continue bricht den Schleifenrumpf ab und setzt die Schleife mit der nächsten Iteration fort. So wird weder None noch sonst etwas (falsch) weiterverarbeitet. Das sollte klappen, sofern es an dieser Stelle keine anderen Seiteneffekte gibt.
Denke nicht das das nötig ist. Ich persönlich finde die Funktion AP nach Netztrennung viel Praxistauglicher als rauswühlen und aufschrauben des Gehäuses, um den Knopf zu drücken. Interessant würde Didi’s Platine erst dann wieder werden wenn Deepsleep, größere Messintervalle und somit Batteriebetrieb überhaupt erst sinnvoll ist.
Beim Pycom Gehäuse besteht unterdessen im Feldeinsatz immer die Gefahr eine Schraube beim öffnen im Gras zu verlieren.
Das andere Gehäuse kenne ich nicht. Kann mir aber vorstellen, das dort die Schrauben gegen rausfallen gesichert sind.
Edit: habe unten noch was zum Thema geschrieben. Was diesbezüglich ganz wichtig ist !!!
OK, sende Heute Abend einen Pull reqest diesbezüglich.
Solange wir keine Funktionalität haben die Daten Zwischenzusprechen und vor allem nachträglich zu senden halte ich das für Prio 2. Also eher was für ein späteres Update.
Dadurch daß der Watchdog Aktiv wird, wenn W-Lan nicht verfügbar ist wird der Fipy praktisch bei jedem Versuch neu gestartet. Sollte also zuverlässig klappen, zumindest, wenn der Watchdog zuverlässig funktioniert.
Ganz testen konnte ich das aber noch nicht, da er bei mir ja, wenn das WLAN nach dem Neustart immer noch nicht da ist in den AP Modus wechselt, der nach Ablauf der Zeit wiederum einen Watchdog Reset ausführt.
Also muß ich noch testen was passiert, wenn er kein W-Lan nach einem WDT Start hat.
Clemens Platine braucht du übrigens zum testen nicht extra anschließen. Für das Programm sind die Platinen bis auf die fehlenden Taster Baugleich. Also nur im AP-Modus. Den Taster deaktivieren.
!!!
Es wäre übrigens fatal die FiPy mit aktivierten ap_Button= true den Teilnehmern mit der Weißen Platine zuzuschicken.
Sie kommen dann gar nicht in den AP!
Auch bei versehentlichen Aktivieren dieser Funktion wär ein wieder entfernen des Häckchens unmöglich.
!!!
Wir sollten daher auf ein generellen Start des AP nach Netztrennung auch bei Didi’s Platine nachdenken.
Oder doch, wie @Diren schon vorgeschlagen hat, die Platinen austauschen.
Was aber viel Aufwand bei den Imkern wär, gerade wenn sie die Sets schon in den Beuten verbaut sind.
Der AP-Modus wird in der Praxis sehr selten benutzt: bei z.B. Erstinstallation oder SW-Update. Für mich war es bislang sehr umständlich, draussen an der Beute auf dem Handy rumzutatzeln, Da ich auch an der Software entwickle, ist es für mich einfacher, den Rechner abzukabeln und ihn am Schreibtisch zu bearbeiten. Aus meiner Sicht sollte der AP-Modus nicht automatisch eingeschaltet werden.
Es kommt aber vor, dass sich der FiPy oder das Wlan aufhängt. Manchmal nützt auch kein “reset” sondern nur noch Strom aus/ein am Netzteil. Das geht ganz schnell ohne Aufschrauben. Wenn ich dann vom Garten wieder am PC bin, sind meistens die ersten Daten sichtbar. Ich möchte dann nicht auf einen Watchdog warten.
Dann würde ich für dich und für andere “Pro”-Nutzer eventuell noch einen extra config eintrag machen, den man über das Webinterface nicht steuern kann.
AP_PWRON = false.
Einen Noob ein Set zu geben, das er mit setzen eines unbedachten Häckchens nur komplett neu aufspielen kann, um wieder Kontrolle darüber zu bekommen, halte ich für zu gefährlich.
AP by default finde ich nicht das schlechteste! Sollte dann aber nur nach power loss sein, nach dem deep sleep gibt es ja auch einen reset, das könnte man aber über die reset cause abfangen, denke ich. Allerdings sind 30 Minuten Wartezeit dann ggf. zu viel, da in dieser Zeit ja keine Daten versendet werden?
Was mir gerade noch auffällt: Wenn der AP-mode aktiviert ist sendet der FiPy ja keine Daten an bee-observer.org. Können wir den AP-Modus mit der netten RGB-LED signalisieren, vielleicht orange? Dann würde man auch da sehen was der gerade macht und ob der AP-Mode aktiviert wurde.
Meine Idee war auch den AP nur nach power loss für 10 min zu starten. Das mit dem reset cause ist bereits integriert.
Es gibt derzeit noch eine zweite Möglichkeit das der AP Startet, die ich von früher übernommen hatte das sind die besagten 30 min wenn nach irgendeinem Neustart keine Verbindung aufgebaut werden konnte. Wie gesagt, die fliegt heute Abend ersatzlos raus.
Das mit der RGB bekomme ich auch hin.
Ist jetzt zwar ganz off Tropic, aber bekommen wir es auch hin, das bee-observer.org eine Infomail verschickt, wenn er von einem Sensor längere Zeit nichts gehört hat?
finde es nervig, ständig nachschauen zu müssen, ob da noch was an Daten kommt oder nicht.
Gute Idee, luftdaten.info verschickt z.B. solche Mails automatisch
-------- Weitergeleitete Nachricht --------
Betreff: Benachrichtigung zum Sensor [hier-ID/Name] (ChipID: esp8266-xxx)
Datum: Mon, 30 Dec 2019 13:02:05 +0100
Von: xxx@luftdaten.info
An: xxx
Hallo Sensor-Pate,
Dein Sensor [hier-ID/Name] hat seit mehr als 24 Stunden keine Daten mehr
an unsere Datenbank gesendet.
Wenn der Sensor absichtlich ausgeschaltet wurde, ist alles in Ordnung
und du kannst die Mail ignorieren.
Falls nicht, könntest du bitte nach dem Sensor schauen. Im einfachsten
reicht ein Neustart (Netzteil kurz vom Strom trennen, wieder einstecken).
Der Standort des Sensors laut Datenbank:
https://www.openstreetmap.org/?zoom=17&mlat=xx&mlon=xx
Ob wieder Daten gesendet werden, kannst du auch sehen unter:
http://www.madavi.de/sensor/graph.php?sensor=esp8266-xxx-sds011
Die Stärke der WLAN-Verbindung siehst du unter:
http://www.madavi.de/sensor/signal.php?sensor=esp8266-xxx
Beide Seiten sollten die Daten mit ca. 5-10 Minuten Verzögerung
anzeigen. Voraussetzung ist, das die Madavi API in der
Konfiguration nicht abgewählt wurde.
Bei Problemen kannst du mich unter der Mail-Adresse
xxx@luftdaten.info kontaktieren.
Schicke mir auch eine Mail, wenn der Sensor nicht mehr in
Betrieb sein sollte. Wir deaktivieren ihn dann und du bekommst
keine weiteren Benachrichtigungen mehr.
Mit freundlichen Grüßen,
xxx
Luftdaten.info
Ein unerfahrener Bob Teilnehmer wohl schon eher.
Dann würde ich eine andere Art Not-AP mit meheren Bedingungen vorschlagen. Am einfachsten wär z.B. PWR_On Reset und fehlendes W-Lan.
Dann müsste man den Fipy entweder außer Reichweite bringen oder den Router ausschalten.
Vorteil: ist, das man bei der Erstinstallation sofort sehen, das z.B das was mit dem W-Lan nicht stimmt.
Nachteil: Nach einem echten Stromausfall wär der Fipy aber schneller wieder da als der Router, das heißt erstmal AP
Besser wär daher evtl PWR_on und ein fehlender Sensor wie z.B der BME680 oder der HX711.
Bei Didi’s Platine kann es ja auch vorkommen, daß einer den AP-Pin verstellt und daher nicht mehr rauf kommt.
Auto reconnect to wlan hab ich jetzt auch.
Und ich habe P13 und P14 zur Auswahl für AP_Button im Webserver hinzugefügt.
Läuft alles zu mindest bei mir Störungsfrei.
Fällt euch sonnst noch etwas ein, was fehlt, oder stört?
Da der Watchdog bei WLan Verlust nicht mehr anspringt und Deep Sleep nicht existiert, könnten wir die Daten zwischenspeichern und nachträglich senden. Kann BEEP das überhaupt? Müssten dann ja einen Timestamp mitsenden.
Vorher bringt es meiner Meinung auch nicht zu prüfen, ob Internet oder Server da ist, darauf hat der Fipy ja gar keinen einfluss.
