Moin zusammen,

nach fast einem halben Jahr habe ich heute mal wieder meinen Fork auf den aktuellen Stand eures Repositories gebracht und mir (nach Auflösung von gefühlt zwei Dutzend Mergekonflikten) auch direkt einen Crash bzw. eine Boot-Loop eingehandelt 🙈

Eigentlich hatte ich gedacht, dass in einem solchen Fall irgendwann wieder die zuletzt funktionierende Boot-Partition verwendet wird, aber leider hat das nicht funktioniert - weder durch Abwarten (ca. 30 Minuten) noch durch mehrfaches stromlos schalten konnte ich remote auf meine WARP zugreifen. Somit blieb dann nur der Griff zum Schraubendreher...

Gibt es da irgendeinen Trick? Im Code habe ich die Commands "firmware_update/reboot_app0", "firmware_update/reboot_app1" und "firmware_update/reboot_other" gefunden, aber dafür muss der Webserver ja erstmal stabil laufen.

Besten Dank und Gruß Thomas

Hast du diese Option bei den custom_options deines Platform IO-Environments gesetzt? Kannst du aus der warp2.ini klauen.

                 firmware_update_enable_rollback = 1

Wenn die Option aktiv ist, wird bei einem Crash der neuen Firmware sofort wieder die vorige Firmware gestartet, sofern der Crash innerhalb von fünf Minuten nach dem Start passiert. Sobald eine Firmware fünf Minuten am Stück läuft, wird sie als „gut“ betrachtet und ein Crash danach startet wieder die neue Firmware.

Ja, die Option ist gesetzt.

Aber wenn das Rollback bei euch problemlos funktioniert, dann versuche ich erstmal, das Problem selbst weiter einzukreisen...

Bei uns sind keine Probleme mit dem Rollback bekannt und ein vorsätzlich verursachter Crash führte gerade auch wie erwartet zu einem Rollback.

Leider fehlt mir deine selbstgebaute Hardware. Ein frischer ESP32 Ethernet Brick + EVSE (1) + NFC + RS485 (ohne Zähler) laufen bei mir problemlos mit deinem aktuellen Github-Master.

Wir haben das hier gerade diskutiert und haben uns kein nachvollziehbares Szenario ausdenken können, in dem der Rollback – wenn er aktiviert ist – nicht funktioniert. Kannst du mir einen aktuellen Debug-Report zusammen mit der crashenden Firmware (.elf und .bin) schicken? Wir würden uns das gerne genauer ansehen.

‘n Abend @MatzeTF ,

den Stand habe ich erst nach GitHub gepushed als alles wieder lief, daher investiert bitte keine unnötige Arbeit in die Analyse eines (wahrscheinlich) Einzelfalls, d. h. wenn ihr es mit eurem Setup nicht reproduzieren könnt, dann ist das mein Problem 🙃

Hilft der Debug-Report denn noch weiter, wenn ich die Firmware per USB neu geflashed habe? Ansonsten kann ich morgen gerne mal versuchen, das Verhalten zu reproduzieren…

Den Debug-Report mit dem darin enthaltenen Crash und die Firmware, die den Crash verursacht hat, würden uns gerne ansehen. Die Rollback-Funktion ist für uns sehr wichtig und wir wüssten gerne, wie man die aushebeln kann.

Falls du das Problem reproduzieren kannst, wäre das natürlich noch besser.

Weißt du zufällig noch, ob du etwas an den platform_packages geändert hattest?

Kannst du dich noch daran erinnern, was vor dem Crash die Flash-Geschwindigkeit unten auf der Debug-Seite war?

Hast du eigentlich die Konsolenausgaben vom Crash gesehen oder hast du einfach nur die funktionierende Firmware per USB geflasht?

Puh, das sind aber viele Fragen 😂

Den Debug-Report habe ich angehängt und bei den platform_packages habe ich (zumindest bewusst) nichts geändert. Sonst ist mir nichts ungewöhnliches aufgefallen und den Crash habe ich mir leider auch nicht in der Console angeschaut.

Weiterhin fürchte ich, dass ich die problematischen bin/elf Files schon gelöscht habe. Wie gesagt, macht euch bitte keinen Stress wegen dieses (vielleicht einmaligen) Falls. Ich kann gerne erst versuchen, das Problem zu reproduzieren…

EDIT: Ich hatte die Files doch noch nicht gelöscht :)

EDIT 2: Zumindest ist das die Firmware, die im Log als "invalid" gekennzeichnet ist. Ich bin mir leider aber nicht sicher, dass das auch tatsächlich der Stand ist, bei dem der Crash aufgetreten ist...

Partitions: app0 (valid, running, 2.8.17+69762899), app1 (invalid, 2.8.17+69761260)

warp2-XSS-Debug-Report-2026-01-26T21-01-48-398.txt

firmware.zip

bearbeitet January 27, 2026 at 06:2927. Jan 2026 von poohnet

Der Crash ist von „warp_on_steroids_firmware-UNSIGNED-NIGHTLY_2_8_17_697616b5_f6a759f762d9e33“. Hast du die zufällig auch noch? Vermutlich lief die aus dem app0-Slot und wurde beim Flashen über USB überschrieben. Flashen per USB markiert auch immer app1 als „invalid“, unabhängig davon, wie gut oder schlecht die Firmware in dem Slot ist.

Leider nein, aber der "NIGHTLY"-Hinweis war perfekt, denn mit dem "EEBus"-Modul kann ich den Crash und den nicht stattfindenden Rollback reproduzieren 🙂

• "normales" "NIGHTLY"-Image flashen => Reboot ok

• abwarten bis nach ca. sieben Minuten die Partition als gültig markiert wird

• "NIGHTLY-EEBus"-Image flashen => Reboot, keine Rückmeldung mehr

Ich flashe dann mal schnell wieder das lauffähige Image und ziehe den Debug-Report ab...

Das ist schon mal ein guter Hinweis. Ich kann den EEBUS-Crash hier reproduzieren, aber bei mir wird dann anschließend korrekt ein Rollback durchgeführt.

Hmm, das war jetzt ein klassicher Fall von "Murphys Law" - kaum hatte ich den Strom abgeschaltet und stattdessen den Rechner verbunden, schon startet der Brick wieder richtig und die Webseite begrüßt mich mit

Firmware 2.8.17+6978b2d5 scheint instabil zu sein. Es wurde auto­matisch auf die vorherige Firmware 2.8.17+6978b0a9 zu­rück­ge­wech­selt. Bitte einen Debug-Report he­runter­laden und an info@tinkerforge.com schicken.

Möchtet ihr trotzdem in den Debug-Report reinschauen oder ist der Crash im "EEBus"-Modul bekannt?

On 1/27/2026 at 2:12 PM, poohnet said:

Möchtet ihr trotzdem in den Debug-Report reinschauen oder ist der Crash im "EEBus"-Modul bekannt?

Kannst du den Backtrace gerade einmal in das decode-Script oder gdb werfen? Wenn das hier (↓) ist, ist das seit fünf Minuten bekannt und ich brauche keinen Debug-Report dafür. 😉

0x4013ce97: LpcUsecase::get_current_limit_w() const at /home/user/tf/esp32-firmware/software/src/modules/eebus/eebus_usecases.h:859

Edit: Und gefixt.

Nicht ganz:

0x40139f72 in update_evse_limit () at src/modules/eebus/eebus.cpp:84
84          auto limit_mA = eebus.usecases->limitation_of_power_consumption.get_current_limit_w() * 1000 / 230 / evse_common.backend->get_phases();

Wird wahrscheinlich aber auf's gleiche hinauslaufen...

bearbeitet January 27, 2026 at 14:1227. Jan 2026 von poohnet

Ja, das ist ein Stack-Frame vorher. Habe ich eben bei uns auf Master repariert.

On 1/27/2026 at 2:12 PM, poohnet said:

Hmm, das war jetzt ein klassicher Fall von "Murphys Law" - kaum hatte ich den Strom abgeschaltet und stattdessen den Rechner verbunden, schon startet der Brick wieder richtig und die Webseite begrüßt mich

Verstehe ich das richtig, dass der Brick vorher die ganze Zeit nicht erreichbar war und erst durch Strom aus- und wieder einschalten wieder zum Leben erweckt wurde?

On 1/27/2026 at 3:20 PM, MatzeTF said:

Verstehe ich das richtig, dass der Brick vorher die ganze Zeit nicht erreichbar war und erst durch Strom aus- und wieder einschalten wieder zum Leben erweckt wurde?

Ja, richtig. Ich habe ungefähr zehn Minuten gewartet währenddessen keine "pings" mehr durchgingen, dann die Nachricht geschrieben, die Sicherung ausgeschaltet und den Rechner mit dem Brick verbunden um die Konsolenausgaben zu prüfen. Zu meiner Überraschung habe ich keine Boot-Loop gesehen und das Webinterface war wieder erreichbar.

Wie lange sollte es denn dauern, bis der Rollback erkannt/durchgeführt wird und die WARP wieder erreichbar ist?

On 1/27/2026 at 3:33 PM, poohnet said:

Wie lange sollte es denn dauern, bis der Rollback erkannt/durchgeführt wird und die WARP wieder erreichbar ist?

Der Rollback wird eigentlich direkt beim ersten Crash durchgeführt. Es sollte somit nicht möglich sein, dass die kaputte Firmware ein zweites Mal gestartet wird. Dementsprechend sollte die WARP nach 15 Sekunden (für den Crash) plus der üblichen Neustart-Zeit wieder erreichbar sein.

Wäre es möglich, dass du dir die Konsolenausgaben ansiehst, noch während die WARP nicht erreichbar ist, also ohne vorher einmal den Strom abzuschalten?

On 1/27/2026 at 3:42 PM, MatzeTF said:

Wäre es möglich, dass du dir die Konsolenausgaben ansiehst, noch während die WARP nicht erreichbar ist, also ohne vorher einmal den Strom abzuschalten?

Ja klar, kann ich machen. Im Moment regnet es hier aber in Strömen, da schraube ich die Wallbox lieber nicht unter Strom auf ☠️ 😂

Kann man denn den ESP32-Ethernet-Brick gefahrlos per USB anschließen, während er vom Netzteil mit Strom versorgt wird? Oder soll ich nicht besser den Strom abschalten und alles über die USB-Verbindung machen?

On 1/27/2026 at 3:56 PM, poohnet said:

Ja klar, kann ich machen. Im Moment regnet es hier aber in Strömen, da schraube ich die Wallbox lieber nicht unter Strom auf ☠️ 😂

Kann man denn den ESP32-Ethernet-Brick gefahrlos per USB anschließen, während er vom Netzteil mit Strom versorgt wird?

Der Brick kann gefahrlos gleichzeitig per USB angeschlossen und vom Netzteil mit Strom versorgt werden, sofern die Wallbox korrekt geerdet ist. Am besten ist ein Laptop im Akkubetrieb, damit keine Erdschleife entstehen kann. Wenn der Berührungsschutz deiner WARP1 installiert ist und somit keine Netzpotential berührbar ist, kannst du den Brick auch im Betrieb per USB verbinden oder trennen. Ist der Berührungsschutz nicht installiert oder aus anderen Gründen Netzpotential berührbar, musst du entsprechend vorsichtig sein und das USB-Kabel ggf. vorher bei abgeschaltetem Strom verbinden.