poohnet

On 2/10/2026 at 6:27 AM, Raudi said:

Teste noch mal mit der Firmware, die ich oben genannt habe. Mit der vorherigen war es bei meinem Tavascan auch so, mit der neuen nicht mehr. Irgendwas hat sich da geändert.

Seitdem ich die ersten Tests gemacht (und wahrscheinlich die Nerven unserer Nachbarn arg strapaziert 😂) habe, liegt der Dongle ungenutzt in der Schublade. Aber besten Dank für den Hinweis, dann teste ich das nochmal mit der aktuellen Firmware...

@meierchen006 ,

ich habe noch einen WiCAN in der Schublade liegen, den ich nicht nutzen kann, weil bei meinem ID.4 reproduzierbar die Alarmanlage losgeht, wenn der Wagen abgeschlossen ist und auf den OBD-Bus zugegriffen wird. 🚨

Bei Interesse gerne PM…

On 2/4/2026 at 9:00 PM, Docmac said:

Was müsste denn alles beim Umbau von Warp1 smart auf Warp2 oder 3 smart getauscht werden und bekommt man das?

Die Teile gibt's alle im Shop und hier im Forum haben bereits einige User erfolgreich ein Update durchgeführt.

On 2/3/2026 at 5:17 PM, MatzeTF said:

Die Umrüstung von WARP1 zur neuesten Generation ist aber recht aufwändig.

Eine Alternative wäre evtl. "WARP-on-Steroids". Als WARP-User "der ersten Stunde" habe ich meine WARP1 in den letzten Jahren immer wieder etwas umgebaut und erweitert, insbesondere den ESP32-Brick durch den leistungsstärkeren ESP32-Ethernet-Brick (den auch die WARP2 hat) ersetzt und die Firmware entsprechend angepasst. Der aufwändigste Schritt hierbei war eigentlich das "Umlöten" einer Steckerleiste vom alten auf den neuen Brick.

https://www.tinkerunity.org/topic/11542-warp-on-steroids-u-zugehörige-firmware/

Gruß Thomas

Hi @MatzeTF ,

sorry, aber ich hätte doch noch mal eine kurze Verständnisfrage: Sehe ich es richtig, dass ein Rollback auf die vorherige Firmware nur dann durchgeführt wird, wenn der Crash innerhalb der ersten sieben Minuten stattfindet, aber nicht mehr, wenn die Bootpartition einmal als gut markiert wurde?

Ich war jetzt nämlich doch wieder in einer echten "Boot-Loop" gefangen, nachdem ich das EEBus-Modul (inkl. der letzten Korrektur) eingebunden, aber erst etwa eine halbe Stunde später aktiviert habe:

                  0,018 |                  |     **** TINKERFORGE WARP2 CHARGER V2.8.17+697CDC99 ****
                  0,018 |                  | Last reset reason was: Software reset due to exception/panic (4)
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  0,345 | coredump         | Task 'loopTask' caused exception 28: LoadProhibited
Backtrace: 0x40105a38 0x4014417d 0x4014437a 0x40117ae1 0x40225932 0x403482a6
                  0,507 | fs               | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used
                  0,682 | api              | WARP2 Charger config version: 2.8.4 (warp)
                  0,691 | esp32_eth_brick  | ESP32 Ethernet Brick UID: XSS
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  1,076 | device_module    | Phase Switcher Bricklet found. Enabling Phase Switcher support.
                  1,115 | ntp              | Set timezone to Europe/Berlin
                  1,296 | wifi             | Connecting to WiFi
E (1371) mqtt_client: Client has not connected
                  1,439 | firmware_update  | Firmware is signed by: poohnet
                  1,462 | firmware_update  | Partitions: app0 (valid, 2.8.17+6978b0a9), app1 (valid, running, 2.8.17+697cdc99)
                  1,551 | meters           | Meter 0: Meter declared 76 (73) values
                  1,590 | meters           | Meter 1: Meter declared 66 (60) values
                  1,769 | charge_tracker   | Found 6 records: first is 1, last is 6
                  1,802 | charge_tracker   | Last charge record size is 2464 (77, 0)
                  2,140 | device_module    | No NFC Bricklet found. Disabling NFC support.
                  2,630 | web_server       | Starting multi-port server with 2 ports
                  2,672 | network          | mDNS responder started
                  2,993 | power_manager    | External phase switching API enabled, starting with 1p
                  3,134 | eebus            | EV connected: 0, previous: 0
                  3,135 | api              | State evse/phases_connected not found. Known states are:
                  3,146 |                  |     info/modules,
                  3,146 |                  |     event_log/boot_id,
                  3,156 |                  |     info/features,
                  3,156 |                  |     info/version,
                  3,167 |                  |     rtc/time,
                  3,167 |                  |     rtc/config_modified,

                  ...

                  4,146 |                  |     ocpp/configuration,
                  4,146 |                  |     eebus/config_modified,
                  4,156 |                  |     eebus/config,
                  4,167 |                  |     eebus/state,
                  4,167 |                  |     eebus/usecases,
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40105a3b  PS      : 0x00060030  A0      : 0x80144180  A1      : 0x3ffe6b90  
A2      : 0x00000000  A3      : 0x3f429719  A4      : 0x00000000  A5      : 0x3faa2ed8  
A6      : 0x3ffb72a0  A7      : 0x3faa2ed8  A8      : 0x8011927c  A9      : 0x3ffe6b30  
A10     : 0x00000041  A11     : 0x3f45bc21  A12     : 0x00000000  A13     : 0x3f41047b  
A14     : 0x3ffe6b6c  A15     : 0x3ffbbb9c  SAR     : 0x0000001d  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x40219d34  LEND    : 0x40219d3c  LCOUNT  : 0x00000000  


Backtrace: 0x40105a38:0x3ffe6b90 0x4014417d:0x3ffe6bb0 0x4014437a:0x3ffe6bf0 0x40117ae1:0x3ffe6c40 0x40225932:0x3ffe6ca0 0x403482a6:0x3ffe6cc0




ELF file SHA256: 559d43311

Rebooting...

In einem solchen Fall gibt's wahrscheinlich keine "Selbstheilung", oder?

Danke und Gruß Thomas

P. S. Den Crash an sich braucht ihr nicht zu analysieren, der liegt daran, dass es den State "evse/phases_connected" (noch) nicht im EVSE v1 Modul gibt...

Moin @MatzeTF ,

ich schon wieder 🙈

Ihr hattet im Betatest für die Batteriesteuerung bislang noch keinen SMA SunnyBoy Smart Energy, d. h. einen der kleinen, einphasigen Hybridwechselrichter mit ennexOS, oder?

Ich habe die aktuelle Beta-Firmware bislang zwar noch nicht getestet, nach meinen bisherigen Tests mit Node-RED (und auch den wenigen Beiträgen hier: https://www.photovoltaikforum.com/thread/231398-sma-sbse-4-0-einpasiger-hybrid-%C3%BCber-modbus-steuern/) funktioniert das aber wohl nicht mehr über die bekannten Modbus-Register 40793ff.

Stattdessen muss man das interne Energiemanagement des WRs deaktivieren und kann (bzw. muss) die Ladesteuerung dann selbst über die Register 41467 und 41469 übernehmen.

Sagt einfach Bescheid, wenn ich diesbezüglich etwas testen soll oder anderweitig unterstützen kann...

Gruß Thomas

Ja, stimmt schon, das Problem ist wohl schon sehr speziell. Evtl. löst es sich ja mit irgendeinem Update des Pis von selbst wieder, denn ich kann mich nicht daran erinnern, dass es in der Vergangenheit so schon mal aufgetreten wäre. Andererseits war die Wallbox (wenn ich sie denn mal ausgeschaltet hatte) immer deutlich länger als zwei Minuten getrennt.

Als abschließenden Test habe ich das Szenario gerade nochmal mit einer alten FRITZ!Box als AP durchgespielt. Wie erwartet hat sich auch meine WARP nach dem Neustart direkt wieder verbunden.

Ich denke, damit wäre der Raspberry Pi / WPA Supplicant als Täter eindeutig identifiziert 🚓

On 1/29/2026 at 1:51 PM, MatzeTF said:

Hast du zufällig noch den entsprechenden Abschnitt aus dem Log vom Pi? Möglichst mit den erfolgreichen Verbindungsversuchen davor und danach.

Ja, schicke ich dir heute Abend.

EDIT: Das hier ist eigentlich der relevante Block - mehr steht im Log im relevanten Zeitraum nicht drin:

Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78
Jan 28 20:22:44 raspi wpa_supplicant[527]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78

• Crash kurz nach 19:57:27

• WARP gegen 20:21 ausgeschaltet

• WARP gegen 20:23 wieder eingeschaltet (nachdem die "AP-STA-DISCONNECTED"-Meldung im Log stand)

• erfolgreiche Verbindung 20:23:35

On 1/29/2026 at 1:51 PM, MatzeTF said:

Die Retry-Logik ist prinzipiell von uns. Aktuell wird drei Mal mit 10 Sekunden Abstand ein Verbindungsversuch gestartet, danach alle 30 Sekunden. Das auf anderthalb Minuten zu erhöhen, würde bei manchen Verbindungsproblemen schon eine ziemlich lange Verzögerung bedeuten.

Deshalb die Idee des Exponential Backoff, d. h. Retry nach 4, 8, 16, 32, ... Sekunden. Damit würden kurzzeitige Verbindungsabbrüche weiterhin relativ schnell behoben und auch bei mir wäre die Verbindung spätestens bei 128 Sekunden (in Summe also unter fünf Minuten) wieder aufgebaut worden, da dann zwei Minuten zwischen den Verbindungsversuchen gelegen und der Pi die "Stale"-Verbindung gelöscht hätte.

Ich kann mir das WiFi-Modul aber gerne auch selbst mal anschauen...

On 1/29/2026 at 1:58 AM, MatzeTF said:

Während sich die Wallbox die ganze Zeit über WIFI_REASON_AUTH_EXPIRE beschwert, steht im Log des Pi dann nichts Neues?

Nein, erst wenn ich die WARP für etwa anderthalb Minuten stromlos schalte, wird die Verbindung gelöscht.

On 1/29/2026 at 1:58 AM, MatzeTF said:

Da die WLAN-Bibliothek ein Closed-Source-Blob ist, den ich nicht debuggen kann

Ich habe jetzt noch nicht ins WiFi-Modul reingeschaut, aber heißt das, dass die Retry-Logik im Fehlerfall von der Bibliothek selbst übernommen wird? Ansonsten könnte ggf. ja ein Exponential Backoff helfen. Im Log sieht man zwar, dass die Abstände zwischen den Verbindungsversuchen nach einiger Zeit etwas größer werden, allerdings nicht so groß, dass der Pi die Connection löscht.

On 1/29/2026 at 1:58 AM, MatzeTF said:

Du überlastest nicht zufällig die 3V3-Versorgung mit deinen ganzen zusätzlichen Bricklets?

Da hängen tatsächlich nur zwei Bricklets dran - EVSE und der (selbstgebaute) Phase-Switcher. Und im Normalbetrieb läuft die WARP damit absolut problemlos, d. h. keine Verbindungsaussetzer, Ladeprobleme o. ä.

On 1/29/2026 at 1:58 AM, MatzeTF said:

Danke für deine Ausdauer, dem Problem auf den Grund zu gehen.

Genau diese Probleme spornen mich an, eine Lösung, zumindest aber eine plausible Ursache zu finden. Den Dank gebe ich aber gerne auch zurück, denn ohne deine Unterstützung bzw. den Austausch hier wären wir sicherlich nicht so weit gekommen 😊

Die Gretchenfrage ist jetzt aber, warum es funktioniert, wenn ich die Wallbox kurz stromlos schalte.

Die Antwort: Es funktioniert momentan nicht, d. h. nach einem harten Reset verbindet sie sich auch erstmal nicht mehr. Anscheinend gibt es da aktuell einen Bug im WLAN-Treiber, der mich auf eine völlig falsche Fährte gebracht hat. Das hat früher definitiv mal (besser) funktioniert.

EDIT: Ganz unschuldig ist die WARP aber wohl doch nicht, denn anscheinend verhindern die ständigen Verbindungsversuche, dass die Verbindung AP-seitig geschlossen werden kann. Erst durch ein Abschalten der Stromversorgung für etwa anderthalb Minuten wurde die Verbindung dann gelöscht - und danach konnte die WLAN-Verbindung auf Anhieb wieder hergestellt werden:

Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78
Jan 28 20:22:44 raspi wpa_supplicant[527]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78

Puh, war das eine schwere Geburt... 🥵

On 1/28/2026 at 4:23 PM, MatzeTF said:

Wie lange waren „ein paar Sekunden“? Das 12 V-Netzteil einer WARP1 hält nach einem Stromausfall noch mehrere Sekunden durch. Fünf Sekunden solltest du mindestens warten.

Fünf bis zehn Sekunden waren's bestimmt, aber auch 30 Sekunden helfen leider nicht. Nach einem Blick in die Logs des Raspberry Pis und ein paar Tests habe ich jetzt aber auch eine neue Theorie - bitte korrigiere mich, falls das Blödsinn sein sollte...

Nach einem Neustart des Pis verbindet sich die WARP problemlos mit dem AP:

Jan 28 19:26:41 raspi wpa_supplicant[2099170]: Successfully initialized wpa_supplicant
Jan 28 19:26:52 raspi wpa_supplicant[2099170]: nl80211: kernel reports: Registration to specific type not supported
Jan 28 19:26:55 raspi wpa_supplicant[2099170]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: interface state UNINITIALIZED->ENABLED
Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: AP-ENABLED
Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-CONNECTED - Connection to e4:5f:01:04:d4:08 completed [id=0 id_str=]
Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78

Dann die (kaputte) Firmware eingespielt - WARP meldet sich korrekt vom AP ab und nach dem Neustart (aber vor dem Crash) dann auch wieder an:

Jan 28 19:30:00 raspi wpa_supplicant[2099170]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78
Jan 28 19:30:05 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 19:30:06 raspi wpa_supplicant[2099170]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:30:06 raspi wpa_supplicant[2099170]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78

Durch den WARP-Crash bleibt die Session Pi-seitig anscheinend aber bestehen, sodass sich die WARP nicht mehr authentifizieren kann:

                  7,860 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 11,265 | wifi             | Connecting to WiFi, BSSID lock enabled
                 17,688 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 21,269 | wifi             | Connecting to WiFi, BSSID lock enabled
                 27,692 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)

Nach fünf Minuten habe ich den "wpa_supplicant" Dienst neugestartet und kurze Zeit später hat sich die WARP dann kurz verbunden, wieder abgemeldet und dann erfolgreich verbunden:

an 28 19:36:00 raspi wpa_supplicant[2100852]: Successfully initialized wpa_supplicant
Jan 28 19:36:11 raspi wpa_supplicant[2100852]: nl80211: kernel reports: Registration to specific type not supported
Jan 28 19:36:14 raspi wpa_supplicant[2100852]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: interface state UNINITIALIZED->ENABLED
Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: AP-ENABLED
Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-CONNECTED - Connection to e4:5f:01:04:d4:08 completed [id=0 id_str=]
Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78
Jan 28 19:36:24 raspi wpa_supplicant[2100852]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78
Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78
Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78

                338,174 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                361,135 | uptime_tracker   | Wrote last uptime to flash
                361,330 | wifi             | Connecting to WiFi, BSSID lock enabled
                364,199 | wifi             | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -68dBm, BSSID E4:5F:01:XX:XX:XX
                368,160 | wifi             | Lost IP. Forcing disconnect and reconnect of WiFi
                368,168 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_ASSOC_LEAVE) (8)
                391,335 | wifi             | Connecting to WiFi, BSSID lock enabled
                394,209 | wifi             | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -75dBm, BSSID E4:5F:01:XX:XX:XX
                394,734 | wifi             | Got IP address: 192.168.110.213/24, GW 192.168.110.1
                396,031 | network          | Network connected (WiFi)

Es scheint also so zu sein, dass ein Crash nach dem Aufbau der WLAN-Verbindung zumindest den AP eines Raspberry Pis durcheinander bringen kann.

Macht das Sinn? Oder wie würdest du das interpretieren?

On 1/28/2026 at 1:57 PM, MatzeTF said:

Leider haben viele Nutzer ihre WARPs per WLAN verbunden und wenn die Wallbox nach einem Rollback komplett aus dem WLAN verschwinden kann, wüssten wir schon gerne, wie es dazu kommen kann.

Ok, das ist definitiv ein Argument ;-)

Wenn ich die Wallbox heute nochmal installieren würde, dann würde ich definitiv auch ein LAN-Kabel legen, da WARP1 seinerzeit aber ausschließlich per WLAN verbunden werden konnte (und auch der Netzbetreiber noch keine Steuerbarkeit vorgeschrieben hat), habe ich nicht weiter darüber nachgedacht.

Mit einem AP in unmittelbarer Nähe (bei mir eben der Raspberry Pi in der UV, Abstand zur Wallbox weniger als zwei Meter) hatte ich damit bislang auch noch keinerlei Probleme - weder im regulären Betrieb, noch bei Firmware-Updates o. ä.

On 1/28/2026 at 1:57 PM, MatzeTF said:

Es ist zwar suspekt, dass Strom abschalten bei dir nicht geholfen hat und du erst USB anschließen musstest, aber das WLAN-Modul speichert nichts über einen Stromausfall hinaus und nach einer gewissen Zeit sollte auch der AP das Gerät vergessen haben.

Ja, da kann ich mir auch keinen Reim drauf machen, habe allerdings auch nur die üblichen "ein paar Sekunden" zwischen "LSS aus" und "LSS wieder an" gewartet. Ich werde daher nochmal versuchen, ob längeres Ausschalten, ggf. auch ein Reboot des Pis irgendetwas an dem Verhalten ändern.

On 1/28/2026 at 1:57 PM, MatzeTF said:

Mir ist allerdings bei der Suche nach dem WLAN-Problem aufgefallen, dass das Arduino-Framework unsere WLAN-Buffereinstellungen überschreibt. Das erklärt zwar nicht dein Problem, könnte aber alte Probleme mit langsamen Verbindungen oder Crashes wegen zu wenig RAM erklären. 🙈

Dann war's ja wenigstens nicht ganz umsonst. Ich schaffe es ja immer irgendwie, die merkwürdigsten Probleme anzuziehen 😂

On 1/28/2026 at 12:37 PM, MatzeTF said:

Ich wollte damit nicht sagen, dass die Schuld beim Pi liegt.

Alles gut, das hatte ich so auch nicht verstanden... 🙃

On 1/28/2026 at 12:37 PM, MatzeTF said:

Ich kann allerdings sagen, dass ich das WLAN-Problem hier mit anderen APs nicht reproduzieren kann. Nach dem Crash wird bei mir ein Rollback durchgeführt und der Brick verbindet sich sofort mit dem WLAN, auch mit aktiviertem BSSID-Lock.

... und das ist doch schon mal eine wichtige Erkenntnis. Bitte steckt da von eurer Seite nicht noch mehr Arbeit rein. Der Rollback funktioniert grundsätzlich, d. h. ich werde jetzt erstmal die Logs analysieren und berichten.

On 1/28/2026 at 12:04 AM, MatzeTF said:

Dein AP ist angeblich ein Raspberry Pi.

Nicht nur angeblich. Der Pi in der UV fungiert seit mehr als zwei Jahren u. a. als AP und bislang hatte ich damit noch keinerlei Probleme. Irgendwas scheint beim Rollback anders zu laufen als bei einem normalen Firmwareupdate.

Ich schaue heute Abend aber mal in die Logs - und schalte den BSSID Lock aus…

Hi @MatzeTF ,

jetzt wird's richtig spooky und wahrscheinlich wirst du mich jetzt für verrückt erklären - vermutlich würde ich es selbst nicht glauben, wenn ich nicht ein Console Log hätte...

TL;DR: Der Rollback der Firmware auf die vorherige Version funktioniert korrekt, allerdings kann sich der Brick danach nicht mehr per WLAN verbinden. Auch ein (zugegebenermaßen recht kurzes) stromlos schalten hat ändert daran erstmal nichts. Erst in dem Moment, als ich das Notebook per USB angeschlossen habe, wurde die Verbindung hergestellt.

Hier die zugehörigen Logs:

1. Installation der problematischen Firmware

2026-01-27 19:03:18,501 | firmware_update  | Installing firmware from file upload
2026-01-27 19:03:18,752 | firmware_update  | Changed app1 partition OTA state from undefined to invalid
2026-01-27 19:03:33,571 | evse             | external slot default -1
2026-01-27 19:03:46,637 | evse             | external slot default -1
2026-01-27 19:03:58,739 | firmware_update  | Firmware successfully installed
2026-01-27 19:03:58,811 | tools            | Reboot requested by firmware update.
2026-01-27 19:03:59,847 | modbus_tcp_srvr  | Client 192.168.110.144:41254 disconnected: ServerStopped (error -1)
2026-01-27 19:03:59,850 | modbus_tcp_srvr  | Client 192.168.100.8:50438 disconnected: ServerStopped (error -1)
2026-01-27 19:03:59,861 | meters_mbtcp     | Meter 0: Disconnected from 192.168.110.145:502
2026-01-27 19:03:59,874 | meters_mbtcp     | Meter 0: Modbus error repeated 1 time while reading 16 registers starting at address 366: Aborted (257) / Connection got closed
2026-01-27 19:03:59,885 | meters_sun_spec  | Meter 2: Disconnected from 192.168.110.144:502
2026-01-27 19:04:01,532 | wifi             | Disconnected from WiFi: Unknown reason (WIFI_REASON_ASSOC_LEAVE) (8). Was connected for 643 seconds.

2. 1. Reboot nach Installation Firmware inkl. "Core 1 Panic"

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4980
load:0x40078000,len:16600
load:0x40080400,len:3500
entry 0x400805b4
                  0,018 |                  |     **** TINKERFORGE WARP2 CHARGER V2.8.17+6978B2D5 ****
                  0,018 |                  | Last reset reason was: Software reset via esp_restart (3)
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  0,489 | fs               | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used
                  0,672 | api              | WARP2 Charger config version: 2.8.4 (warp)
                  0,681 | esp32_eth_brick  | ESP32 Ethernet Brick UID: XSS
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  1,058 | device_module    | Phase Switcher Bricklet found. Enabling Phase Switcher support.
                  1,096 | ntp              | Set timezone to Europe/Berlin
                  1,287 | wifi             | Connecting to WiFi, BSSID lock enabled
E (1356) mqtt_client: Client has not connected
                  1,431 | firmware_update  | Firmware is not signed
                  1,454 | firmware_update  | Partitions: app0 (valid, 2.8.17+6978b0a9), app1 (pending-verify, running, 2.8.17+6978b2d5)
                  1,553 | meters           | Meter 0: Meter declared 76 (73) values
                  1,589 | meters           | Meter 1: Meter declared 66 (60) values
                  1,759 | charge_tracker   | Found 6 records: first is 1, last is 6
                  1,792 | charge_tracker   | Last charge record size is 2464 (77, 0)
                  2,134 | device_module    | No NFC Bricklet found. Disabling NFC support.
                  2,618 | web_server       | Starting multi-port server with 2 ports
                  2,658 | network          | mDNS responder started
                  2,985 | power_manager    | External phase switching API enabled, starting with 1p
                  3,195 | eebus            | EEBUS Module disabled
                  3,316 | event            | State evse/phases_connected not found
                  3,317 | main             | Initialization done
                  3,335 | device_name      | This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW
                  3,898 | wifi             | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -53dBm, BSSID E4:5F:01:XX:XX:XX
                  4,411 | wifi             | Got IP address: 192.168.110.213/24, GW 192.168.110.1
                  4,565 | modbus_tcp_srvr  | Client 192.168.100.8:47218 connected
                  5,138 | ethernet         | Started after 4033ms
                  5,371 | network          | Network connected (WiFi)
                  5,377 | meters_speedwire | Meter 1: Joined multicast group 239.12.255.254:9522
                  5,394 | mqtt             | Connected to broker at mqtt://192.168.100.8:1883.
2026-01-27 19:04:08,655 | ntp              | NTP synchronized at 5,396
2026-01-27 19:04:08,660 | meters_mbtcp     | Meter 0: Connected to 192.168.110.145:502
2026-01-27 19:04:08,674 | meters_sun_spec  | Meter 2: Connected to 192.168.110.144:502
2026-01-27 19:04:08,825 | meters_sun_spec  | Meter 2: Looking for device Mn='SMA' Md='SBSE5.0-50' SN='3023075914'
2026-01-27 19:04:08,835 | meters_sun_spec  | Meter 2: Device Mn='SMA' Md='SBSE5.0-50' Opt='' Vr='03.14.24.R' SN='3023075914' is matching
2026-01-27 19:04:08,848 | meters_sun_spec  | Meter 2: Enabling quirks mode 0x12 for SMA device
2026-01-27 19:04:09,226 | modbus_tcp_srvr  | Client 192.168.110.144:34922 connected
2026-01-27 19:04:09,233 | meters_sun_spec  | Meter 2: Configured SunSpec model 701/0 found at 192.168.110.144:502:126:40096
2026-01-27 19:04:09,270 | meters           | Meter 2: Meter declared 49 values
2026-01-27 19:04:09,272 | meters_sun_spec  | Meter 2: Checking phase voltages for float-is-le32 quirk
2026-01-27 19:04:09,283 | meters_sun_spec  | Meter 2: Check for float-is-le32 quirk completed due to normal L3-N voltage value: 226.1 V
2026-01-27 19:04:09,707 | solar_forecast   | Using test data
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40139f72  PS      : 0x00060d30  A0      : 0x801f2975  A1      : 0x3ffe6c00  
A2      : 0x3ffe13a0  A3      : 0x00000000  A4      : 0x0000002d  A5      : 0x3ffe6c18  
A6      : 0x3ffb74e0  A7      : 0x3ffc5068  A8      : 0x00000000  A9      : 0x3ffe6be0  
A10     : 0x3ffb74a8  A11     : 0x473c1ab7  A12     : 0x3ffe6bdc  A13     : 0x00000000  
A14     : 0x3ffc50d4  A15     : 0x00000000  SAR     : 0x00000001  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000013c  LBEG    : 0x40083151  LEND    : 0x40083159  LCOUNT  : 0x00000027  


Backtrace: 0x40139f6f:0x3ffe6c00 0x401f2972:0x3ffe6c20 0x4020c620:0x3ffe6c40 0x40117761:0x3ffe6c80 0x4022261e:0x3ffe6ca0 0x40341a52:0x3ffe6cc0




ELF file SHA256: fd51f4e36

Rebooting...

3. 2. Reboot nach "Core 1 Panic" inkl. korrektem Rollback - aber ohne WLAN

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4980
load:0x40078000,len:16600
load:0x40080400,len:3500
entry 0x400805b4
                  0,017 |                  |     **** TINKERFORGE WARP2 CHARGER V2.8.17+6978B0A9 ****
                  0,018 |                  | Last reset reason was: Software reset due to exception/panic (4)
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  0,344 | coredump         | Task 'loopTask' caused exception 28: LoadProhibited
Backtrace: 0x40139f6f 0x401f2972 0x4020c620 0x40117761 0x4022261e 0x40341a52
                  0,505 | fs               | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used
                  0,674 | api              | WARP2 Charger config version: 2.8.4 (warp)
                  0,682 | esp32_eth_brick  | ESP32 Ethernet Brick UID: XSS
Found device 2t8ndc of type 9002 at port A
Found device SSm of type 2159 at port F
                  1,058 | device_module    | Phase Switcher Bricklet found. Enabling Phase Switcher support.
                  1,092 | ntp              | Set timezone to Europe/Berlin
                  1,274 | wifi             | Connecting to WiFi, BSSID lock enabled
E (1344) mqtt_client: Client has not connected
                  1,414 | firmware_update  | Firmware is not signed
                  1,437 | firmware_update  | Partitions: app0 (valid, running, 2.8.17+6978b0a9), app1 (aborted, 2.8.17+6978b2d5)
                  1,448 | firmware_update  | Firmware 2.8.17+6978b2d5 rolled back to 2.8.17+6978b0a9
                  1,512 | meters           | Meter 0: Meter declared 76 (73) values
                  1,548 | meters           | Meter 1: Meter declared 66 (60) values
                  1,711 | charge_tracker   | Found 6 records: first is 1, last is 6
                  1,744 | charge_tracker   | Last charge record size is 2464 (77, 0)
                  2,056 | device_module    | No NFC Bricklet found. Disabling NFC support.
                  2,393 | web_server       | Starting single-port server on port 80
                  2,427 | network          | mDNS responder started
                  2,697 | power_manager    | External phase switching API enabled, starting with 1p
                  2,874 | main             | Initialization done
                  2,882 | device_name      | This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW
                  5,132 | ethernet         | Started after 4032ms
                  7,876 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 11,278 | wifi             | Connecting to WiFi, BSSID lock enabled
                 17,702 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 21,283 | wifi             | Connecting to WiFi, BSSID lock enabled
                 27,705 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 31,261 | wifi             | Starting scan to select unoccupied channel for soft AP
                 31,287 | wifi             | Scan failed
                 31,288 | wifi             | Connecting to WiFi, BSSID lock enabled
                 31,764 | wifi             | Selecting channel 1 for soft AP
                 31,944 | wifi             | Soft AP started
                 38,279 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 61,302 | wifi             | Connecting to WiFi, BSSID lock enabled
                 68,151 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                 90,782 | require_meter    | Charger energy meter stuck or unreachable! Blocking charging.
                 91,306 | wifi             | Connecting to WiFi, BSSID lock enabled
                 98,156 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                121,310 | wifi             | Connecting to WiFi, BSSID lock enabled
                128,156 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                151,316 | wifi             | Connecting to WiFi, BSSID lock enabled
                158,165 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                181,319 | wifi             | Connecting to WiFi, BSSID lock enabled
                188,167 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                211,323 | wifi             | Connecting to WiFi, BSSID lock enabled
                218,174 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)
                241,327 | wifi             | Connecting to WiFi, BSSID lock enabled
                248,176 | wifi             | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)

4. 3. Reboot durch stromlos schalten - WLAN-Verbindung wird erst mit Verbindung des Notebooks aufgebaut

Processing empty (board: esp32_brick; platform: https://github.com/Tinkerforge/platform-espressif32.git#tf-54.03.21-2; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--- Terminal on /dev/cu.usbserial-10 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
                 61,276 | wifi             | Connecting to WiFi, BSSID lock enabled
                 64,140 | wifi             | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -53dBm, BSSID E4:5F:01:XX:XX:XX
                 64,660 | wifi             | Got IP address: 192.168.110.213/24, GW 192.168.110.1
                 66,044 | network          | Network connected (WiFi)
                 66,050 | meters_speedwire | Meter 1: Joined multicast group 239.12.255.254:9522
                 66,067 | meters_mbtcp     | Meter 0: Connected to 192.168.110.145:502
                 66,073 | mqtt             | Connected to broker at mqtt://192.168.100.8:1883.
                 66,084 | meters_sun_spec  | Meter 2: Connected to 192.168.110.144:502
                 66,351 | meters_sun_spec  | Meter 2: Looking for device Mn='SMA' Md='SBSE5.0-50' SN='3023075914'
                 66,353 | meters_sun_spec  | Meter 2: Device Mn='SMA' Md='SBSE5.0-50' Opt='' Vr='03.14.24.R' SN='3023075914' is matching
                 66,365 | meters_sun_spec  | Meter 2: Enabling quirks mode 0x12 for SMA device
                 66,519 | meters_sun_spec  | Meter 2: Configured SunSpec model 701/0 found at 192.168.110.144:502:126:40096
                 66,694 | meters           | Meter 2: Meter declared 49 values
                 66,694 | meters_sun_spec  | Meter 2: Checking phase voltages for float-is-le32 quirk
                 66,705 | meters_sun_spec  | Meter 2: Check for float-is-le32 quirk completed due to normal L3-N voltage value: 225.9 V
2026-01-27 19:12:19,385 | ntp              | NTP synchronized at 67,066
2026-01-27 19:12:20,128 | solar_forecast   | Using test data
2026-01-27 19:12:22,725 | require_meter    | Charger energy meter working again. Allowing charging.
2026-01-27 19:12:28,684 | modbus_tcp_srvr  | Client 192.168.100.8:50628 connected
2026-01-27 19:13:01,128 | modbus_tcp_srvr  | Client 192.168.110.144:51552 connected

WTF ?!?!? Wie tief wollen wir noch in dieses "rabbit hole" hinabsteigen?! 😂

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

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...

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?

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...

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

‘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…

Ja, die Option ist gesetzt.

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

Nein, das ist kein Murks, ein Topic "charge_tracker/electricity_price_update" habe ich in meinem Firmware-Clone schon seit einiger Zeit drin 🙃

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

On 9/2/2025 at 12:53 PM, MatzeTF said:

Ansonsten haben VW IDs Probleme mit der Phasenumschaltung, die du vermutlich nutzt, da du evcc im Einsatz hast. Ich glaube, man muss was an der Steckerverriegelung des Fahrzeuges umstellen, aber dazu kann hoffentlich ein ID-Nutzer hier im Forum mehr sagen.

Ich habe auch einen ID.4 (MJ 2023) und hatte am meiner "WARP1-on-Steroids" mit selbstgebauter Phasenumschaltung und evcc bislang noch keine Probleme mit der Ladung. Wenn ich den Wagen verbinde und die Ladung nicht innerhalb von ein, zwei Minuten starte, dann leuchtet die Ladekontrollleuchte am Auto ebenfalls rot und ich erhalte eine "Ladung abgebrochen" Push-Benachrichtigung von der VW-App. Nichtsdestotrotz kann ich die Ladung auch Stunden später noch problemlos starten.

Unter Ladeort "zu Hause" habe ich allerdings festgelegt, dass der Stecker nach Abschluss der Ladung automatisch entriegelt wird. Damit könnte jemand theoretisch zwar den Stecker  im Vorbeigehen ziehen, praktisch ist das aber noch nicht vorgekommen...