ESP32 0.5.78 Nicht mehr erreichbar nach 2-3 Tagen

[MiniOh]

Hallo,

ich habe seit der 0.5.78 der Verhalten dass alle 2-3 Tage, erst die Webseite auf dem ESP32 nicht mehr erreichbar ist, aber noch ca. 1h Daten empfangen und auch per MQTT übertragen werden.
Danch werden auch keine neue Daten mehr übermittelt.
Hier hilft bisher nur stromlos machen.

Kann ich hier sinnvollte Daten oder Logs bereitstellen, und falls ja, wie?

Danke schon mal vorab.

[Argafal]

Was bedeutet denn "die Webseite nicht mehr erreichbar ist"? Was die Fehlermeldung?

[MiniOh]

Die DTU ist noch per Ping erreichbar, aber der Webserver antwortet nicht mehr per HTTP.

[Gerri1]

Kann ich bestätigen beim ESP8266, nur das bei mir sich Ahoy auch nicht mehr anpingen lässt!

[Aikonflo]

Ähnliches Problem bei mir.
ESP ist kurz nach dem Start per Web erreichbar danach „Seite kann nicht angezeigt werden“
Laut Netzwerk-Controller ist er aber noch verbunden.
WLAN-LED leuchtet dauerhaft mit kurzem Flackern.

ESP 8266 D1 Mini
Ahoy ver. 0.5.65

[lumapu]

wir arbeiten leider seit anfang an an diesem Problem. Zusätzlich verhält sich jeder ESP anders. Meiner (ESP8266) mit Version 0.5.78 läuft jetzt aktuell seit über 6 Tagen am Stück - alles geht.

[MiniOh]

Vielen Dank für die Rückmeldung.
OK, das wusste ich nicht, dass es "solche Probelme" schon seit Beginn der Entwicklung gibt.

Ich selbst hatte das Verhalten noch nicht beobachten können.
Lediglich seit der 0.5.78 hatte ich das bereits 3 Mal.

Was "passiert" in dem Fehlerfall? Es ist ja schon etwas merkwürdig, dass zuerst die Funktion des Webservers "ausfällt", MQTT aber noch funktioniert, dann auch irgendwannd die Übermittlung per MQTT wegfällt und erst dann ist quasi die DTU selbst auch per Ping nicht mehr erreichbar ...

[E1nste1n-AUT]

Wäre ein periodischer Reset eine Option, Hausnummer jeden Tag um 05:00 Uhr? Denn wenn die ahoyDTU 24h ohne Probleme läuft dann wäre das für mich OK.
Dann besteht zwar immer noch mein Problem mit der Zeitsynchronisation, aber das habe ich hier bereits versucht zu erläutern #642

[Argafal]

Meine Meinung: Das Problem gab es mit früheren Versionen (0.5.32 und davor) in dieser Form nicht. In meinen Augen würde ein periodischer Reboot also nur das Symptom verstecken. In meinen Augen wäre es besser, die Grundursache zu finden und zu lösen.

Vorschlag: wir sind ja jetzt doch relativ viele in diesem Issue mit dem gleichen Problem. Gibt's mit zusätzlichen Debug-Flags beim Bauen vielleicht doch irgendwo eine Fehlermeldung, die jemand mit etwas Glück abfangen und hier posten kann?

[roku133]

Das beschriebene Verhalten von 0.5.78 kann ich bei meinem ESP8266 bestätigen, nach drei Tagen ist die WLAN-Verbindung plötzlich unterbrochen, ping auf die DTU-Adresse bleibt erfolglos. Netz AHOY-DTU ist als Alternative vorhanden. Die DTU bleibt über Stunden in diesem Zustand. Nach Anmeldung funktioniert ping auf 192.168.4.1 nicht, die Anmeldung auf die Weboberfläche damit ebenfalls nicht.
Interessant ist, dass nach einigen Zugriffsversuchen auf AHOY-DTU die normale WLAN-Verbindung wieder aufgebaut wird.
DTU funktioniert ohne Bootvorgang (Nachweis durch uptime) wieder normal weiter.

Im Gegensatz dazu lief v0.5.70 mehr als 22 Tage ohne manuellen Eingriff, DTU war dabei zeitweise nicht mit dem stärksten AP verbunden.

[beegee3]

Frage in die Runde: wie sind denn die RSSI Werte? Bei schlechter Verbindung ist die Web Verbindung träge. Auch wenn sie zustande kommt, wird die Reaktion im Laufe der Zeit zunehmend schlechter. Die Requests an AhoyDTU laufen asynchron, aber die meisten Seiten erzeugen in regelmäßigen Abständen neue Requests, die nicht zeitnah abgearbeitet werden können und es entsteht ein Stau. Vielleicht wird das System dadurch überfordert und es wäre besser, neue Requests erst dann zu erlauben, wenn der vorherige beantwortet wurde.
Auch WLAN Abbrüche und erfolglose Anmeldeversuche sind bei schlechter Verbindung natürlich häufiger zu beobachten.

[roku133]

Verbindung mit Repeater bei ca. 3 m Entfernung seitlich zwischen -72 dBm und -77 dBm, mit Router zwischen -82 dBm und -86 dBm (Wemos D1 mini v3 mit Leiterbahn-Antenne).
Web-UI war mit 0.5.70 selbst bei Verbindung mit Router trotz des sehr schwachen Pegels verfügbar, nur in seltenen Ausnahmefällen war ein Reload nötig. MQTT-Verbindung war stabil.

[Gerri1]

Da waren keine Auffälligkeiten vorhanden!
Unter System "heap_frag" waren manchmal Werte über 40!

[MiniOh]

Hallo,

ich weiß nicht, ob es bei der Fehlersuche hilft.
Ich hatte jetzt 2 ESP32 mit 0.5.78 laufen, eine hat die Kommunikation mit den Wechselrichtern aktiv, die andere nicht.
Die mit aktiver Kommunikation ist jeweils nach 2 Tagen und 3 Stunden bzw nach 2 Tagen und 14 Stunden nicht mehr erreichbar gewesen.
Die ohne Kommunikation läuft ohne Ausfall durch.

[Argafal]

Danke @MiniOh. Auf esp8266 geht ahoy für mich viel schneller kaputt, ich hab eine uptime von Minuten statt Tagen. Das ist natürlich fürs debugging ganz praktisch ;)
Deine Beobachtung deckt sich mit meiner, und @knickohr hat das auch schon erwähnt: Ohne Kommunikation scheint ahoy stabil zu laufen. Für mich läuft nachts alles stabil durch, Probleme (reboots/nicht erreichbar/webserver weg) scheinen nur tagsüber bei aktiver Kommunikation aufzutreten.

[MiniOh]

Klingt ja fast etwas danach, dass irgendein Speicher "vollläuft"?
160 vs. 512kB Ram .... was evtl. auch einen zeitlichen Unterschied macht?

[Argafal]

Ja, das kann gut sein. Vielleicht auch ein Zusammenhang zur Anzahl Inverter? Ich hab drei in AHOY.

[MiniOh]

Ja, auch möglich, ... aktuell habe ich auch 3, werden aber mehr.
Gibt es evtl. die Möglichkeit, die RAM Auslastung zu überwachen? OpenDTU macht das, wenn ich es richtig in Erinnerung habe.

[Argafal]

Gibt es zu den zwei new() Statements in web/RestApi.h ein dazugehöriges delete()?

 63             AsyncJsonResponse* response = new AsyncJsonResponse(false, 8192);
[....]
103             AsyncJsonResponse* response = new AsyncJsonResponse(false, 200);

[Gloomyeye]

Ja, das kann gut sein. Vielleicht auch ein Zusammenhang zur Anzahl Inverter? Ich hab drei in AHOY.

Ich habe auch die Version 0.5.78 installiert und nur einen Wechselrichter angemeldet (HM-600). Der ESP ist auch nach einigen Stunden nicht mehr erreichbar.

[MiniOh]

Ja, das kann gut sein. Vielleicht auch ein Zusammenhang zur Anzahl Inverter? Ich hab drei in AHOY.

Ich habe mir jetzt mal über einen Zeitraum von einer Stunde die free_heap Size angesehen.
Diese bleibt ohne Kommunkation recht gleich.
Mit aktiver Kommunikation wird diese pro Stunde ca. 7000 kleiner, in meinem Fall von rund 183000 zu 176000.
Hochgerechnet, sollte diese nach ca. 26 Stunden (Kommunikationsstunden) auf 0 sein, was bei mir ungefähr passen würde, dass nach 2 1/2 Tagen die DTU ausfällt.

[stefan123t]

@Argafal ja die new() Statements und andere dynamisch allokierte Speicherbereiche hat @lumapu aktuell auch im Verdacht und versucht sie sukszessive zu ersetzen.

[knickohr]

Reden wir wirklich von ESP32 ? Die Version 76, nicht 78 !, lief bei mir 12 Tage am Stück ohne Probleme mit 2 Invertern durch. Ja, kann gut sein das wir da schon wieder ein neues Problem haben.

Auf dem 8266 habe ich seit der letzten Stable (66) nur für wenige Stunden Erfolg, dann schlug der Watchdog zu 😪

[MiniOh]

Reden wir wirklich von ESP32 ? Die Version 76, nicht 78 !, lief bei mir 12 Tage am Stück ohne Probleme mit 2 Invertern durch. Ja, kann gut sein das wir da schon wieder ein neues Problem haben.

Auf dem 8266 habe ich seit der letzten Stable (66) nur für wenige Stunden Erfolg, dann schlug der Watchdog zu 😪

Ja, bei mir 2x ESP32 im Einsatz.
Mit Kommunikation gibts nach etwas mehr als 2 Tagen das Problem, ohne Kommunikation läuft die DTU.

[Argafal]

Ich hab (wie explizit erwähnt) den Vergleich zu ESP8266 berichtet, für den Fall das das die gleiche Ursache ist und sie beim ESP8266 nur schneller auftritt.

Ob jemand von euch die mit ESP32 unterwegs sind die Exception beim Reboot fangen kann?

[MiniOh]

Wenn du mir ein paar Infos dazu gibts, ... kann ich das evtl. machen.
Alternativ kannst du bei Dir auch mal die free_heap beobachten?

[Argafal]

Ich habe mir jetzt mal über einen Zeitraum von einer Stunde die free_heap Size angesehen.
Diese bleibt ohne Kommunkation recht gleich.
Mit aktiver Kommunikation wird diese pro Stunde ca. 7000 kleiner, in meinem Fall von rund 183000 zu 176000.
Hochgerechnet, sollte diese nach ca. 26 Stunden (Kommunikationsstunden) auf 0 sein, was bei mir ungefähr passen würde, dass nach 2 1/2 Tagen die DTU ausfällt.

Ist das immer noch so, wenn du MQTT deaktivierst? Mit anderen Worten: Können wir eingrenzen, ob dein immer kleiner werdender Heap durch die Kommunikation mit den Invertern an sich ist, oder durch die Weiterleitung der Daten über MQTT (oder beides)?

[Argafal]

Mach ich schon, deswegen kam mir ja der Gedanke. Aber wie @knickohr ganz richtig angemerkt hat, ich bin auf ESP8266, also hab ich hier in dem Issue nicht viel zu melden. Du schon ;)

Wenn du Lust auf ein Experiment musst du denke ich nur den MQTT server aus den Settings nehmen und speichern und neu starten. Und dann wieder den heap beobachten, so wie du es auch vorher gemacht hast.

[beegee3]

hab' seit einer Stunde einen ESP32 ohne MQTT laufen (Version 0.5.81): heap_free stabil bei ~190000.
Ist evtl. ein Problem bei MQTT, würde trotzdem andere Bereiche die dynamisch Speicher allokieren nicht ausschließen.

@knickohr 12 Tage 👍 Wie gut ist bei dir das WLAN? Frage wegen meines Verdachts bzgl. async response

[Argafal]

hab' seit einer Stunde einen ESP32 ohne MQTT laufen (Version 0.5.82): heap_free stabil bei ~190000.
Ist evtl. ein Problem bei MQTT, würde trotzdem andere Bereiche die dynamisch Speicher allokieren nicht ausschließen.

Dem letzten Punkt stimme ich natürlich total zu.

Hier übrigens ähnliche Ergebnisse auf ESP8266 ohne MQTT: heap um die 13000, uptime 30 minuten, Webserver nicht abgeraucht. Ein neuer Rekord für mich auf 0.5.83 tagsüber.

[lumapu]

ich habe mal meine Datenbank ausgequetscht ... diese hatte Daten für die letzen 30 Tage:
In blau der free_heap und in rot die version-patch. Die Version wurde anhand der Git Commits manuell nachgetragen, daher kann es auch teilweise fehlerhaft sein.
Anbei auch nochmal meine Rohdaten die als Basis für den Graph gedient haben.

heap_lastMonth.csv

[Gerri1]

dev 0.5.85 heap_free von der Systemseite und MQTT ioBroker!

[lumapu]

@Gerri1 ja das ist bekannt. Das liegt daran, dass zum Zeitpunkt der Ermittlung des Werts schon verschiedene Prozesse aktiv sind. Die sind für MQTT und Webrequest unterschiedlich. Daher am besten einfach per MQTT und Datenbank den Verlauf über die Zeit tracken.

[Gerri1]

... ok, das hatte ich nicht gewusst!
Bei meinem letzten "Hänger", hatte heap_frag einen Wert von über 40.

[MiniOh]

Seit einigen Tagen beobachten wir ja unter anderem die free_heap.
Bisher konnte ich immer wenn Kommuniktaktion mit den Invertern stattfindet, eine sich redurierende free_heap aufzeichnen.
Nachts, mit aktivem MQTT blieb der Wert gleich. Morgens beim booten der Inverter, begann der Werte wieder abzunehmen.
Ausnahme heute. Auch mit aktiver Inverterkommunikation bleibt der Wert gleich. Ich kann mir bisher nicht erklären warum. Ich habe keine Veränderung getätigt. Weiterhin mit Version 0.5.78.

Hier mal free_heap, uptime und Inverter total Power.

[Gerri1]

dev 0.5.87
Der Reboot lässt sich sauber provozieren!
Der heap_free im ioBroker war da 12488.
Ahoy war ne knappe 1/2 Stunde online und mit den WR'n verbunden, danach etwas in der GUI hin und her geklickt und die Systemseite aktualisiert,
... Reboot! Das Ganze habe ich jetzt das 3. mal provozieren können.

Auch wird die Serial - Control Seite nicht richtig dargestellt (linker Frame und WR keine auswählbar) was bei der Version mit Display ständig und ohne Display nach ein paar minuten kommt, ist auch nervend!

[lumapu]

Ich finde den Artikel hier sehr interessant und versuche die Vorschläge umzusetzen. Unser Ziel sollte sein, die Heap-Fragmentation so weit wie möglich nach unten zu bekommen. Zusätzlich sollten wir endlich ein dictornary im PROGMEM anlegen wie es @stefan123t schon oft vorgeschlagen hat.
Interessant klingt für mich auch der DynamicJsonBuffer, der etwas für die Rest API wäre.

https://cpp4arduino.com/2018/11/06/what-is-heap-fragmentation.html

Edit: Link vergessen 😉

[Gerri1]

Da spielt dann heap_frag doch eine größere Rolle!
Da hatte ich schon Werte über 42.

[beegee3]

DynamicJsonBuffer? Die Definition von DynamicJsonDocument zeigt bei mir

// A JsonDocument with a memory pool in the heap.
// https://arduinojson.org/v6/api/dynamicjsondocument/
typedef BasicJsonDocument DynamicJsonDocument;

Also ist das doch schon drin? Oder ist das nur bei mir so und erklärt, warum ich kein heap Problem habe?

@Gerri1 das ist doch genau das, worauf @lumapu in dem link hinweist

[lumapu]

@beegee3 ja habe es gestern auch gesehen, dass das schon drin ist. Wahrscheinlich ist das Problem, das wir überall Strings zusammenbauen und damit den Heap durchlöchern.
Ich habe hierzu schon Ideen und will bald was veröffentlichen I'm die Probleme in Griff zu bekommen.

JSON scheint nicht das Problem zu sein. Wir müssen nur schauen, das wir zB /setup auf zwei kleinere XHR aufteilen, da wir hier aktuell 8192 Bytes reservieren.

[MiniOh]

Vor einigen Tagen hatte ich ja geschrieben, dass meine free_heap immer dann weiter abnimmt, sofern die Inverter Kommunikation aktiv ist. Seit vorgestern war es aber so, dass die free_heap beim ESP32 bei 142 - 144.000 recht gleich blieb.
Gestern Abend um 22:40 war die DTU aber dann nicht mehr erreichbar, trotz "genug" free_heap.
Version ist immer noch die 0.5.78 auf der Prod DTU.

[MiniOh]

Keine Ahnung ob es hilfreich ist, hier mal noch free_heap von 2 DTUs.
Beide heute morgen händisch neugebootet. Beide Inverterkommunikation und MQTT aktiv.

0.5.78

0.5.88

[MiniOh]

Hallo,

von mir mal was positives.
Mit dem ESP32 und 0.5.89 zum ersten mal eine Uptime von 3.5 Tagen und free_heap nicht unter 170.000.

[Argafal]

Für mich auf ESP8266 ist 0.5.89 auch eine echte Verbesserung. Uptime von mehreren Stunden, mal sehen wie weit ich komme. Bin begeistert.

[lumapu]

möchte nicht angeben aber mein ESP8266 hat jetzt eine uptime von 5Tagen und 17 Stunden.
Ich habe nur einen Inverter dran. Free Heap schwankt zwischen 12000 und 14000, immer wenn der Inverter aktiv ist.

Website ist teilweise tot, zB. Webserial aber das Problem ist ja bekannt und wird demnächst gefixt

[E1nste1n-AUT]

Kann ich ebenfalls bestätigen, mit einem Inverter aber ich glaube sogar ohne toter Website (zumindest die Male wo ich drauf geschaut habe, war alles intakt) ;)

[knickohr]

Nicht kaputt machen 😲

[MiniOh]

Auch hier 5 Tage 10h.
Keine Fehler oder Resets bisher.
8 Inverter konfiguriert, 3 zur Zeit mit aktiver Kommunikation.

[lumapu]

@MiniOh welchen ESP verwendest du?

[MiniOh]

Hallo,

Ich habe einige ESP32, ESP-WROOM-32 Chip CP2102.
Die laufen mit der 0.5.89 fehlerfrei.
free_heap geht nicht mehr unter 170.000.

Lediglich der ESP8266 macht gelegentlich reboots, beim Klicken auf der GUI.

[knickohr]

Sooo, vor dem Update auf die 90 😎

Möge Waldi für immer schlafen und gut gefüttert sein in der Zukunft. Preise den Uptime-Gott ! 😅

[MiniOh]

So, ich bin jetzt mit einer Prod DTU nach 21 Tagen fehlerfreier Uptime von der 0.5.89 auf die 0.5.96 gewechselt.

[E1nste1n-AUT]

Und zahlt es sich aus? Bleibe einstweilen bei 0.5.89 da die Version einfach wirklich stabil läuft - seit mittlerweile schon 24 Tagen, mehr brauche ich nicht :)

[MiniOh]

Bisher alles OK.
Ich beobachte noch eine Weile die free_heap, aber bisher OK.
Bei der 0.5.89 ging diese am ersten Tag von 188.000 auf 171.000 runter, blieber aber dann dort recht stabil.
Bei der 0.5.96 von 188.000 auf 168.000, aber offenbar dann auch stabil.