Verbesserung der Stabilität der BOB-Firmware

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.

Ich habe die hiverize/FiPy-Software überarbeitet und einige Änderungen vorgenommen. Da ich mich in Github nicht so gut auskenne, gibt es hier die Software: FiPy-200225.zip (65,4 KB)
Die geänderten Dateien gibt es im Original und mit Änderungen:

  1. main-ori.py und main.py
    mehr und verbesserte Ausgabe auf serieller Schnittstelle
    IP-Adresse, RSSI, data[…] mit string usw.

  2. ds18x20-ori.py und ds18x20.py
    Abfangen von CRC-Check mit Wert ’ ’

         try:
             tmp = self.read_temp(rom)
             ds18b20tmp = str(int(tmp*10)/10)
         except:
             print("CRC-Err", end = ' ')
             # ds18b20tmp =  '99.9'
             ds18b20tmp =  '    '
    
  3. csv-ori.py und csv.py
    Datenfile yyyy-mm-dd.csv und yyyy-mm-dd.plt für Gnuplot

    “”" Datenfile yyyy-mm-dd.csv mit time, value1, … value10 “”"
    def add_data(self, data):
    date_string = self.get_date()

Datei: hiverizelog.zip (107,5 KB)

image

Die Daten des BME280

Die Temperaturen ( CRC-Fehler durch ’ ’ ersetzt )

Nur beim HX711 stören Messwertausreisser

Das relativiert sich, wenn man bei 720 Messungen pro Stunde 6 Ausreisser nach oben und 2 nach unten hat.

Auf dem Bienenmonitor sieht das so aus

2 Likes

@didilamken bauen deine Änderungen auf dem aktuellen Stand im Git auf, oder aus einer früheren Version?
Müsste Mal schauen, ob ich die Änderungen rausfiltern und aus dem Ergebnis einen neuen Zweig oder pull requests erstellen kann.

@Diren gibt es einen Grund, warum Du die 2 letzten Pull Requests von mir noch nicht gemerged hast? (RGB-LED und Reconect)
Wenn ja bitte um Info, das ich weiß, ob und wo ich noch nachbessern muss.

Habe bei mir jetzt alle mir bekannten Varianten und Probleme durchgespielt.

Den alten Stand hab ich dabei schon mehrmals zum Stillstand gebracht anscheinend läuft der WDT als Reconect nicht ganz zuverlässig.

Ich habe mir am 20.2. abends das *.zip von Github gezogen und auf meinem Rechner ausgepackt.

1 Like

Jo, ich hab damit auch schon 2 Stunden verbracht und keinen Weg gefunden. Ist auch nicht so super dokumentiert.

Danke Didi, ich schau mir das gleich an und versuche das noch einzubauen. Wir wollen heute die ersten geupdateten FiPys rausschicken.

Danke für deinen ganzen Pull-Requests. Den RGB-Request hatte ich einfach vergessen.
Bei dem WLan musste ich noch mal drüber nachdenken, ich hab ein paar Gedanken in den Kommentar geschrieben: try to reconect if Wlan is demiss by MKO1640 · Pull Request #24 · Hiverize/FiPy · GitHub

Ich weiß ist quick and dirty.
In die “If connectet” Else fällt er sobald W-Lan nicht mehr vorhanden ist.
Er versucht dann 3 Mal zu verbinden macht eine Messung und trägt diese auch ins Log und auf SD falls vorhanden.

Ohne diesen Patch läuft er meißtens in den Watchdog und Startet dadurch so lange Neu bis eine Verbindung wieder möglich ist, oder er hängen bleibt. Bin mir unsicher ob er dabei überhaupt noch eine Messung macht.
Wenn der Watchdog nicht zuschlägt, versucht er nicht mehr zu verbinden und macht weiter artig seine Messungen, versucht diese aber nicht Mal ansatzweise zu übertragen. Selbst wenn das WLan wieder verfügbar wäre.

Getestet habe ich das indem ich entweder nur das 2,4 Band im Router Deaktiviert habe oder den FiPy aus dem Sendebereich gebracht habe. Der Router würde also nicht Neu gestartet und hatte so jederzeit die IP noch zugewiesen.
Wenn ich ihn Neu gestartet habe war das Ergebnis aber das gleiche.

Mir ist bei mir gestern Nacht noch was aufgefallen. Und zwar, das Die LED noch ein Mal die Farbe ändern kann, wenn der AP Modus gestartet wurde und die main.py beendet wird/wurde. Anscheinend ist dann die Funktion wieder verfügbar und sie setzt anscheinend die letzte? Anforderung um.
Habe da gestern Nacht aber keine Muße mehr gehabt dem noch nachzugehen.

Ich bin da gerad irgendwie nicht reingekommen.

Ah, cool, das klingt viel versprechend!

Ich hab das gerade reingemergt.
@didilamken Bei mir dauert die Messung jetzt ziemlich lange ca. 13 Sekunden statt 5. Liegt das am Schreiben auf die SD? Dem müssen wir noch mal auf den Grund gehen.