Hallo,
ich habe ein Projekt welches meinen Gaszähler ausliest.
Es wurde durch einen Kollegen entwickelt und leider sind immer noch kleine Bugs drin welche ich versuchen möchte zu finden.
Größter Bug, das Filesystem vom ESP8266 lässt sich sporadisch nicht mehr schreiben / lesen und somit werden die Werte von heute auf morgen nicht mehr geloggt. Kennt jemand das Problem mit dem Filesystem? sobald ich den ESP komplett mit allem neu flashe inklusive Filesystem Daten so läuft dieser vorerst ein paar Monate.
Vielleicht kommt es zu stande aufgrund eines Arduino Fehlers "Exception". Was kann es sein?
Der letzte Stand mit dem Core 2.5.2 geht zu kompilieren. Da ich wegen dem Problem mal den Core wechseln sollte, so versuchte ich mein Glück aber dann erscheinen Fehlermeldungen das einiges nicht mehr 'not been declared' wäre.
combie:
Wie bekommst du denn ein aktuelles Log, wenn die Kompilierung nicht funktioniert?
Ich habe den derzeit "defekten" noch still laufen und habe den Code auf einen anderen schreiben wollen zwecks der Statistikrekonstruktion. Mit dem alten Core geht es aber sobald ich die oder den neuen nutze, erhalte ich Probleme.
Tommy56:
Dann suche mal in Deinen Quellen, den Code, der diese Meldung schreibt. Evtl. hat GZ16 ja eine Bedeutung.
Gruß Tommy
Ich werde es zufügen. GZ16 ist nur die Bezeichnung des Projektes. Der Fehler ist das Sammelereignis (Exception) was ständig dazu führt, das die Hardware neu gestartet wird.
20.01.2020 03:00:09 MQTT Broker 192.168.1.14 connected
20.01.2020 13:00:01 GZ16 ESP8266 Restart (Exception)
20.01.2020 13:00:09 Wifi connected to Online, channel 11
20.01.2020 13:00:08 NTP time sync OK (3 Sek)
20.01.2020 13:00:10 MQTT Broker 192.168.1.14 connected
20.01.2020 18:00:00 GZ16 ESP8266 Restart (Exception)
20.01.2020 18:00:09 GZ16 ESP8266 Restart (Exception)
20.01.2020 18:00:17 Wifi connected to Online, channel 11
20.01.2020 18:00:18 NTP time sync OK (1 Sek)
20.01.2020 18:00:20 MQTT Broker 192.168.1.14 connected
20.01.2020 18:00:41 Logfile rotated
21.01.2020 18:01:01 NTP time sync OK (-1 Sek)
22.01.2020 04:00:02 GZ16 ESP8266 Restart (Exception)
22.01.2020 04:00:10 Wifi connected to Online, channel 11
22.01.2020 04:00:09 NTP time sync OK (3 Sek)
22.01.2020 04:00:11 MQTT Broker 192.168.1.14 connected
23.01.2020 04:00:31 NTP time sync OK (-1 Sek)
24.01.2020 04:00:33 NTP time sync OK (-2 Sek)
24.01.2020 05:59:58 GZ16 ESP8266 Restart (Exception)
24.01.2020 06:00:08 GZ16 ESP8266 Restart (Exception)
Die Ausgabe Exception kommt von dieser Codestelle hier:
Der originale Code ist schon mindestens zwei Jahre alt, da sich in den EspCore Versionen immer etwas ändert musst du diese Änderungen einpflegen. Ist wohl für CoreVersion 2.4.0 geschrieben wurden.
Die extrem vielen String basteleien sind ja grauenhaft.
Nie wird geprüft ob noch Platz im Spiffs ist, es wird immer einfach geschrieben!
Hallo Fips,
wärest du bereit mir da behilflich zu sein?
1)In erster Linie würde ich ja erstmal das Ziel verfolgen den Code an die aktuelle Core anzupassen.
2)Schauen ob der Fehler dann immer noch Auftritt mit dem Filesystem.
3)Codeoptimierungen
Derfips:
Der originale Code ist schon mindestens zwei Jahre alt, da sich in den EspCore Versionen immer etwas ändert musst du diese Änderungen einpflegen. Ist wohl für CoreVersion 2.4.0 geschrieben wurden.
ich habe das github Projekt gerade mal durch meine IDE-Sammlung getragen:
IDE 1.8.5 und ESP8266 2.3.0 compiliert ohne Fehler und (fast) ohne Warnungen.
Mit 1.8.6/2.4.2 fliege er bei setuoAP() raus mit einem WPS-Problem.
Entwerde die alte Version reparieren, vermutlich überschaubar aber langwierig, oder auf die aktuelle gehen mit noch viel mehr Zeit und Aufwand.
Habe das Projekt jetzt nur überflogen - Da geht's im Grunde 'nur' um einen Reed-Kontakt/Hall-Sensor, Der einen Zähler inkrementiert und als Webseite anzeigbar macht?!?
Wie ich bereits las, gibt's Webserver-Beispiele - was sollte mich daran hindern, dort eine Variable anzeigen zu lassen?
Was, diese Variable durch einen Digital-In hochzählen zu lassen?
Bei meinem jetzigen Kenntnisstand wäre meine Wahl: kompletter Neubau, bevor auch nur eine Sekunde Zeit in dem verhunstem Projekt versickert ist.
Ob das Projekt früher besser lief - möglich, aber mit aktueller Umgebung ist's wohl eine größere Baustelle - und Da würde ich doch lieber Fehler in bekanntem Code suchen (also meinem neu Geschriebenem), als die Gedankengänge eines völlig Fremden enträtseln zu wollen, wo mir dann hier auch noch die aktuelle IDE regelmäßig in den Schritt tritt.
ja, würde ich selbst wohl auch machen. Der TO und auch Fips hat aber wohl mit seiner Vermutung recht, daß er mit dem SPIFFS auf die Nase fällt. Wenn es Monate läuft, kann es so schlecht nicht sein, ist twar auch nicht mein Programmierstil, sieht aber nicht soo schlimm aus.
Problem ist eher, daß es langwierig wird, bzw. man müßte es so ändern, daß er viel öfter logt, um den Fehler zu provozieren, kann man durchaus auch ins SPIFFS machen.
Das alles in meiner alten IDE, wo es durchläuft, prinzipiell einen D1 mini nehmen, eine DS1307 sollte auch in der Kiste liegen und einen Taktgeber extern als "Kontakt" und abwarten.
Erfahrungsgemäß versinken solche Sachen hier aber ohnehin, bei den Fragern wird Aufwand zu groß und/oder Interesse zu klein...
Außerdem habe ich eigentlich auch genug eigene Projekt-Leichen, die außer mir und einem Bekannten keinen wirklich interessieren.
Hallo und danke der Beteiligung.
Ich habe als ersten Schritt das Projekt mal geforkt auf mein Account und habe einen Branch erstellt worin wir die Änderungen einarbeiten können. Hier ist auch eine kurze Erläuterung vom Projekt.
Dieser Stand konnte nun mit dem Core 2.6.3 fehlerfrei kompiliert werden.
Nun stellt sich die Frage, ob der neue Core, gegenüber dem alten 2.5.3 nun "besser" läuft.
postmaster-ino:
Habe das Projekt jetzt nur überflogen - Da geht's im Grunde 'nur' um einen Reed-Kontakt/Hall-Sensor, Der einen Zähler inkrementiert und als Webseite anzeigbar macht?!?
Das ist genau richtig.
Es gab mal eine Anmerkung von extern, das das Problem vielleicht ein Memory-Leak sein könnte. !??
Ich habe gelesen, die Exception bei Arduino können verschiedene Ursachen bzw. Fälle unterscheiden.
Wäre es vielleicht ein Schritt nach vorn, wenn man sich diese Numbre ausgeben lassen könnte und somit eine bessere Eingrenzung erzielen könnten? Manche Code´s im Netz fand ich schonmal aber auf die schnelle soeben nicht wieder