Erbitte Mithilfe, bei Coreumstellung keine Kompilierung mehr möglich ESP8266

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.

LG

Quellcode: hier

Und die Exception sollen wir uns jetzt erwürfeln?

Installiere Dir mal den ESP-Exceptiondecoder, damit es mehr Infos von Dir gibt.

Gruß Tommy

Hallo, die ESP-Exception sind installiert aber diese nützen mir noch nichts an der Stelle.
Leider erhalte ich den Fehler nur im Logfile vom Device

20.01.2020 13:00:01 GZ16 ESP8266 Restart (Exception)

Hier muss ich erst ansetzen um da eine klarere Aussage zu halten weil das Device nicht ständig an einem PC angesteckt ist.

Wäre es nicht angepasstet mit einer aktuelleren Bibliothek es zu testen? Es können ja auch Fehler darin versteckt sein.

Dann suche mal in Deinen Quellen, den Code, der diese Meldung schreibt. Evtl. hat GZ16 ja eine Bedeutung.

Gruß Tommy

keine Kompilierung mehr möglich

Wie bekommst du denn ein aktuelles Log, wenn die Kompilierung nicht funktioniert?

combie:
Wie bekommst du denn ein aktuelles Log, wenn die Kompilierung nicht funktioniert?

:wink:

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:

    String logText = F("GZ16 ESP8266 Restart (");
    logText += ESP.getResetReason();
    logText += F(")");
    Serial.println(logText);

""ESP.getResetReason() returns String containing the last reset resaon in human readable format.""

ArduNewBee:
Quellcode: 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!

Gruß Fips

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

Lg

Für Hilfe ist doch ein Forum wie gemacht.

Das ganze Html Gedöns wäre im Spiffs besser aufgehoben!

Gruß Fips

Hallo,

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.

Oder neu bauen...

Gruß aus Berlin
Michael

Hi

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.

MfG

Hallo,

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.

Gruß aus Berlin
Michael

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.

Link 1 / Link 2

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 :frowning: