Verbesserung der Stabilität der BOB-Firmware

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

Jap, die Leute von Correlaid sind da dran.

Hab ich auch schon dran gedacht. Ich bereite einfach ein paar FiPys mit entsprechender Config vor.

Halte ich nicht für so sinnvoll. Ich hatte nach dem Einbauen noch nie den Fall, dass ich in den AP wollte.

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.

Habe nochmal 3 Pull Request gestartet.

  1. RGB Support wenn P2 nicht benutzt wird.
    Messung = Grün
    Leichter schlaf = Orange
    AP = Blau

  2. Hinzufügen der Übertragung der Sendeleistung ‘RSSI’ zu bee-observer.org

  3. kein 30 Min AP mehr nach verlust des Wlan’s mehr. Erst wenn zusätzlich noch ein Neustart kommt. Laufzeit dann für 5 Min .

2 Likes

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.

Die hiveeyes software kann die WLAN Signalstärke sich übermitteln und Beep kam das auch lesen.

Und was noch fehlt, hier aber vielleicht nicht so wichtig ist, Übertragung der Batteriespannung.

Hab dafür schon einen pull request gemacht.
Funktioniert auch ganz gut.

    #read RSSI 
    try:
        wlan = network.WLAN(mode=network.WLAN.STA)
        data['rssi']= wlan.joined_ap_info().rssi
    except:
        data['rssi']= 0
        pass

Batterie noch nicht, aber die Software ist aktuell auf alle fälle nicht für Batterie ausgelegt.

Hmm, wenn er die ap_info nicht bekommt wird 0 übermittelt, kann man das auch einfach leer setzen? 0 ist nicht missing das ist dann für eine spätere Fehleranalyse schwierig, hier vielleicht nicht so tragisch, sollten wir uns aber angewöhnen missings von echten Messungen zu unterscheiden, s. die Diskussion um den 85-Wert bei den DS18B20!

Noch eine Frage zur LED da steht bei dir jetzt

“wenn P2 nicht benutzt wird.” Momentan funktioniert P2 für AP-Mode und für die LED doch auch, klar ist das unschön und doof, dass wir das nicht gleich bemerkt haben:

2020-02-23 13_02_44-BOB-Platine für FiPy - Bee Observer _ BOB Entwicklung - Hiveeyes - SeaMonkey

Aber können wir nicht versuchen das erst mal beizubehalten, bisher funktioniert es ja. Ich weiß ehrlich gesagt nicht genau warum, vielleicht schluckt das debouncing für den Taster da einiges und wir schaffen so die freidliche Koexistenz. Ich fände es aber schade, wenn wir nun mit dem firmware-update die LED-Funktion für alle alten boards deaktivieren würden, gerade wenn sie – bei mir zumindest – keine Probleme machen!

Funktioniert eben nicht. Man kann die LED einschalten und auch die Farben Ändern allerdings nur bis der Interrupt für P2 eingerichtet wird. Ab diesen Zeitpunkt läßt sich die RGB nicht mehr ansteuern. Daher bisher auch kein Farbwechsel für den AP. Falls du Mal in den Code schaust sind aktuell fast alle Farbwechsel auskommentiert. Mit den alten Boards, also das von Dir hat der neue Code eh keine Auswirkungen. Bei Didi’s Board bleibt es auch wie bisher. Mehr Farbe ins spiel kommt erst wenn P2 nicht benutzt wird. Für DiDi’s Platine ist weiter oben der Vorschlag gekommen, die Taster an P13 oder P14 nehmen zu können. Habe sie auch im letzten request im Webinterface für den AP_button freigegeben.

Stimmt können wir so machen.
Allerdings wird die 0 eh, wegen der fehlenden Verbindung nicht übermittelt und ist auch kein möglicher Wert.

Hmm, bei Direns Version ändert sich die Farbe von gelb auf grün, wenn der FiPy eine WLAN-Verbindung hat und auch wieder von grün auf gelb, wenn die Verbindung verloren geht. Hab’ mir den code dazu aber nicht angesehen, kann auch sein, dass der watchdog zuschlägt, der fipy hochfährt und dann die LED ändert und dann erst den Interrupt setzt …

Ja, so ist es. Bei Verlust der Verbindung startet der Fipy über den WDT neu daher die Farbänderung.
Farbwechsel bei WLAN Verlust hab ich noch gar nicht dran gedacht.
Eine Idee wär vor jedem Farbwechsel den Interrupt zu stoppen die Farbe zu ändern und ihn danach wieder zu starten.

1 Like

Das Dumme ist, dass P2 bei RGB-LED-Ansteuerung als Ausgang programmiert werden muss, als Taster wird er aber als Eingang benutzt. Das beisst sich.

Was haltet Ihr davon, wenn wir SW3 an “P13” für den AP-Modus nehmen?

Recht viel.
Hab sie im Webinterface auch schon freigegeben und getestet siehe Add P13 and P14 to allowed AP_Buttons at Webserver by MKO1640 · Pull Request #25 · Hiverize/FiPy · GitHub.
Läuft super mit P13 und P14, man hat dann keine Probleme mit der RGB mehr.
Einzig der Herzschlag macht Probleme, hatte versucht, ihn für sleep zu verwenden. Dann gab es sporadisch aber einen kritischen Core 1 dump error beim ein und auschalten.

Vermutlich wird der heartbeat auch über normalen code wie LED an und aus erzeugt, und das kann der FiPy vermutlich nicht, wenn er schläft. Irgendwo hatte ich mal gelesen, dass deep sleep den heartbeet automatisch deaktiviert … ggf. kommt der core dump gar nicht davon?

können tut er das im light sleep schon. Er hat dann auch artig geblinkt, zumindest, wenn man die Messzyklen etwas länger gemacht hat. Allerdings hatte er dann reproduzierbar so alle 20-30 Zyklen einen Totalcrash.
kann sein , das man eine gewisse zeit warten muß bevor man ihn schlafen legt, oder ist ein zusammenspiel mit irgendeinem Timer wie z.B den vom Interrupt.

Der einzige Nachteil ist hier, dass die SW1 bis 3-Taster keinen internen pullup haben, der müsste noch zusätzlich verlötet werden!

Wie ist das mit der Abwärtskompatibilität für Leute, die sich den button nicht drauf löten können? Bekommen wir den sketch so hin, dass die LED-Umschalterei nur dann gemacht wird, wenn P2 nicht als AP-Modus eingestellt ist?

Wenn sich jemand nun neue firmware installiert und nur die alte Platine hat sollte das irgendwie dennoch funktioneren, wenn auch mit eingeschränkter LED-Statusbenachrichtigung.

Entweder er Deaktiviert den AP_Button und hat dan die gleiche funktionalität wie bei deiner Weißen Platine. = RGB_LED geht und der AP nur bei Neustart nach Power On.
Oder er hat die RGB LED mit den bisherigen einschränkungen (bleibt also wie bisher).

Ich weiß nicht ob ihr Didi´s Platine bei den BOB Teilnehmern voll bestückt habt. Wenn ja, stellt er einfach auf P13 oder P14 und hat Vollen RGB Support und AP auf Knopfdruck.

Wenn nein, und der jenige RGB-Support haben will/muß, dann:

  • Entweder selbst Nachbestücken
  • oder Platine austauschen, und Ihr bestückt nach.
    Sollte ja nur ein Schalter und ein 10K Widerstand sein.

Afaik nicht voll bestückt, nur die beiden linken Taster Reset und Flash.

Ok, haben beide keinen Vorwiderstand also auch nicht einfach nur umlöten.
Ich kann ja mal die Option mit dem Kurzzeitigen init und deinit des interrups zum wechsel der RGB versuchen. Vieleicht klappt das ja. Muß nur rausfinden wie, und ob ich den Pin zurücksetzen kann das die RGB wieder geht.

EDIT: habs leider nicht hinbekommen. Mir gehen auch mittlerweile die Ideen aus.