Keeping WebConsole "open" causes reboot

[schlimmchen]

What happened?

We know, and in a discussion with Aviv on discord this was shown once more, that the ESP32 performs unexpected reboots when the web console is kept "running" for a longer periode of time.

To Reproduce Bug

Open a browser and navigate to the web console. Keep it running for long (how long is unclear). Possibly this happens faster if more than one tab is open with the web console. Observe that the ESP32 reboots unexpectedly.

Expected Behavior

Keeping a browser connected to the web console should not crash the ESP32.

Install Method

Pre-Compiled binary from GitHub releases

What git-hash/version of OpenDTU-OnBattery?

2025.01.10

What firmware variant (PIO Environment)?

generic_esp32s3_usb

Relevant log/trace output

Anything else?

No response

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU-OnBattery, not something specific to my installation.
• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.
• I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported.

[Sorbat]

Also ich habs gerade nochmal getestet, bei mir ist es nicht nach längerer Zeit. Sobald ich die Webkonsole öffne, wird innerhalb von 15-20 Sekunden ein Reboot durchgeführt, welcher sich dann alle 25-30 Sekunden wiederholt.
Ich habe dabei einen Tab mit der Webkonsole geöffnet, nicht mehrere.

[schlimmchen]

Hast du die Möglichkeit, per USB einen Backtrace mitzuschneiden, wenn das bei dir so leicht reproduzierbar ist? Ist es bei mir "leider" nicht... Das wäre super! Muss dann bitte wissen, welche Version genau du einsetzt, auch welches PIO Environment.

[Sorbat]

Ich kann es versuchen. Aber was ist ein Backtrace?

Ich vermute, ich soll über die USB Konsole ein Log erstellen, während die Webkonsole läuft?

[schlimmchen]

Genau. Während die Büchse unerwartet neu startet. Im seriellen Log steht dann was für mich drin (der Backtrace). Das Wort steht da auch. Sieht z.B. so aus:

abort() was called at PC 0x401ec56f on core 0

Backtrace: 0x400840ed:0x3ffef420 0x4008fb61:0x3ffef440 0x40095f31:0x3ffef460 0x401ec56f:0x3ffef4e0 0x401ec5b6:0x3ffef500 0x401ec8fb:0x3ffe0

ELF file SHA256: 38eee8b326b2eef7

Bitte mind. zwanzig Zeilen vorher und nachher mit kopieren, zwecks des Kontexts. Danke für deine Hilfe!

[schlimmchen]

@Sorbat Welche Batterieschnittstelle verwendest du? Ist es eine Pytes oder Pylontech oder eine andere per CAN angeschlossene Batterie?

@AndreasBoehm Aviv hat gerade für uns herausgefunden, dass das Problem verschwindet, wenn er die Batterieschnittstelle zu seiner Pytes abschaltet. Vorher habe ich anhand seiner Backtraces stark vermutet, dass es sich um ein out-of-memory Problem handelt. Das konnte er zusätzlich untermauern: Wenn er auf den Heap schaut in der Web UI unter Info -> System, dann steigt die Heap Usage (mehr oder weniger) kontinuierlich an, bis zu bei >90% ist und der ESP neu starten muss.

Ich versuche das Problem jetzt nochmal zu reproduzieren unter der Annahme, dass es nicht am Battery Provider liegt, sondern daran, dass ein Task, der nicht die main loop() ist, Ausgaben erzeugt.

[AndreasBoehm]

Weißt du wie lange es bei Aviv dauert bevor der heap voll läuft? Dann versuche ich das mal nachzustellen.

[schlimmchen]

Dreißig Sekunden wenn er viel verbose logging hat, sonst Sechzig Sekunden.

Die Frage an Sorbat ist redundant. Gerade habe ich gelernt dass Sorbat@github = Aviv@discord 😉

Wenn ich Ausgaben vom MQTT Task oder vom Huwei Grid charger Task machen lasse, kann ich kein Speicherleck entdecken...

Mir ist schleierhaft, warum ausgerechnet der Pytes/Pylontech/CAN Battery-Provider ein solches Leck haben soll, wo der JK BMS Provider definitiv keins hat. Und dass das Leck nur da ist, wenn die Webkonsole läuft...

[schlimmchen]

@gitisgreat2023 Du hast diesem Issue ein 👍 spendiert. Bist du von dem Problem betroffen in dem Sinne, als dass du es reproduzieren kannst? Hast du eine Batterie per CAN angebunden?

[AndreasBoehm]

Nach 5 minuten mit verbose logging für die folgenden komponenten hat sich nichts getan, läuft immer noch.

• MQTT
• DTU
• Solarladeregler Ve.Direct
• Stromzähler MQTT
• DPL
• Batterie Pytes CAN

[AndreasBoehm]

Wenn ich 5 Tabs der Konsole aufmache läuft der Heap innerhalb von 10 Sekunden voll. Dann gibts nen reboot.

[schlimmchen]

Danke fürs Testen! Schade, dass wir scheinbar woanders weitersuchen müssen. Ist das ein Release oder ein development Build?

[AndreasBoehm]

Build ist von einem PR hoylabs/OpenDTU-OnBattery/pr1558-202501192043 #1558

[schlimmchen]

Build ist von einem PR hoylabs/OpenDTU-OnBattery/pr1558-202501192043 #1558

Frage is jetzt obsolet, da du es reproduzieren kannst mit fünf Tabs.

Was bei mir aber sowohl beim Staging- als auch beim Produktivsystem trotzdem nicht "hilft" das Problem zu sehen 🤷‍♂

Bei mir macht eher der Browser die Krätsche (weil er den ganzen Kram auch noch zwischenspeichern und anzeigen muss) als dass der ESP32 aus der Puste kommt.

Vermutung: Meine Netzwerkbandbreite ist "zu hoch" um den Fehler zu sehen. Am Staging-System hab ich LAN über das Fusion PoE Add-On. Das lässt sich vermutlich nicht sättigen. Die WLAN-Verbindung zum Produktivsystem ist gut, möchte ich behaupten.

Wie ist denn die Situation bei euch?

Ich kann mir vorstellen, dass der Speicher volläuft, wenn der Netzwerkstack nicht hinterherkommt, den ganzen Kram rauszublasen, während munter weiter Daten anfallen. Für dieses Phänomen gäbe es dann eine Schwelle. Und das tritt dann auch nur auf, wenn Websocket Clients verbunden sind, d.h. wenn das Browserfenster mit der Konsole bzw. den Konsolen offen sind.

[AndreasBoehm]

Ich teste nachher mal mit meinem Poe Add-On und LAN Kabel am Macbook. Würde mich schon interessieren ob das einen unterschied macht.

EDIT: Als Browser nutze ich Arc

[AndreasBoehm]

Wenn die DTU und das Macbook per LAN im Netzwerk hängen brauch ich 12 Tabs um einen reboot zu provozieren.

Macbook ist dann auch komplett ausgelastet.

[AndreasBoehm]

Sobald der Client (Browser) nicht mehr nachkommt gibts nen reboot.
Das es jetzt 12 Tabs gebraucht hat und vorher nur 5 halte ich für einen Zufall, vielleicht durch den reboot bedingt den es gebraucht hat um den PoE HAT zu montieren.

EDIT: Hab nochmal mit WLAN am Client probiert, macht keinen unterscheid.

[gitisgreat2023]

@gitisgreat2023 Du hast diesem Issue ein 👍 spendiert. Bist du von dem Problem betroffen in dem Sinne, als dass du es reproduzieren kannst? Hast du eine Batterie per CAN angebunden?

Ja, bei früheren releases war der uptime sehr hoch, nur wenn ich neu gebootet habe fing der uptime neu an. Seit einige releases war der uptime max einige Tage, eher 1 Tag oder weniger. Ich dachte es wäre der power supply, WiFi usw... weiter nicht drauf geachtet.

Long story short, ja, an dem 4MB board hängt ein Huawei R4850 und seit einige Tage statt Pylontech 5000 einen JK BMS. Ich beobachte jetzt mal ob der uptime besser ist mit dem JK BMS CAN interface.

Edit: okay network ist vielleicht ein Faktor. Das schliesse ich bei mir aus. Macht CAN JK BMS vs Pylontech einen Unterschied? Ich melde in einige Tage mal ob es mit dem CAN emulation JK BMS besser ist als Pylontech. Vielleicht gibt es mehrere memory leaks die zu einem reboot führen.

[Sorbat]

Das sind meine Werte unter Netzwerk.

[Sorbat]

Ich habs gerade nochmal am Mini M1 mit Safari getestet, ein Tab mit der Konsole, neustart nach ca. 1 min.

Könnte es vielleicht an meinem ESP liegen? Also an der Hardware?

[schlimmchen]

Könnte es vielleicht an meinem ESP liegen? Also an der Hardware?

Meh... Hast du nicht ein OpenDTU Fusion? Solange das genügend Spannung/Strom hat, suche ich da keinen Fehler. Ausnahme: Interferenzen. Es ist ja noch ungeklärt, warum der Reboot bei dir plötzlich nicht mehr auftritt, wenn du das Battery Interface ausschaltest. Das ist ja hochgradig merkwürdig...

[Sorbat]

Ja das Fusion. habe seit gestern aber wieder ein zweites hier und könnte es mal tauschen.
Das Hutschienennetzteil hat 2.4A. Spannung kann ich nochmal messen, aber normalerweise stelle ich die immer auf 5,01V ein.

Es ist ja noch ungeklärt, warum der Reboot bei dir plötzlich nicht mehr auftritt, wenn du das Battery Interface ausschaltest. Das ist ja hochgradig merkwürdig...

ich dachte, vielleicht sind es einfach zu viele daten und wenn der Esp nen knacks hat, verabschiedet er sich

Ich weiß nicht, ob das relevant sein könnte. Aber ich hab nicht die Pytes v5, sondern die 48100. Vielleicht ist da was anders?

[Sorbat]

Mir war eben aufgefallen, durch Andreas Kommentar oben, dass Batterie auch noch ein Verbose log hat 🙈

Das hab ich jetzt mal deaktiviert, seitdem läuft die Konsole ohne reboot seit 20min

Heap ist von 55 auf 79 gestiegen in der Zeit

Dann Batterie verbose wieder aktiviert, reboot nach 30 Sekunden