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 2:28 PM, poohnet said:

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.

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.

Fun-Fact: Ich nutze ein Dual AC In Bricklet an einem ESP32 Ethernet Brick, um die Stromversorgung einer Tauchpumpe für Drainagewasser im Keller zu überwachen, und das Ding kann zuverlässig über Netzwerk den Ausfall seiner eigenen Versorgungsspannung melden. Als Netzteil verwende ich das gleiche, das auch in einer WARP1 sitzt.

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?

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

bearbeitet January 28, 2026 at 19:3628. Jan 2026 von poohnet

Da die Verbindungsprobleme einen Neustart der Wallbox überstanden haben, hatte ich schon den Pi in Verdacht. Dass die Session beim Pi hängen bleibt, ist gut möglich, da die WARP direkt nach dem Verbindungsaufbau nicht mehr antwortet und das den Pi durcheinanderbringen könnte. Es ist auch möglich, dass sich die WLAN-Bibliothek der WARP immer mit den selben Session-Daten versucht anzumelden und der Pi das nicht akzeptiert, wenn er die exakt gleichen Daten gerade erst gesehen hat.

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

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

                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

Das Lost-IP-Event habe ich in der Kombination schon mal gesehen. Die WLAN-Bibliothek hat anscheinend einen Bug, der dazu führt, dass ein IP-Timer bei einer getrennten Verbindung nicht richtig abgebrochen wird und dann kurz nach dem erfolgreichen Aufbau der Verbindung auslöst. Da die WLAN-Bibliothek ein Closed-Source-Blob ist, den ich nicht debuggen kann, und sich das Problem sofort selbst behebt, habe ich das nicht weiter verfolgt.

[Später] Ich habe nun tatsächlich jemanden gefunden, der genau die gleichen Symptome beobachtet hat. Anscheinend war da der Reset direkt nach dem Verbindungsaufbau relevant. Leider hat derjenige nicht gepostet, wie er schlussendlich das Problem gelöst hat. Andere Nutzer hatten überwiegend das Problem, dass am IO0-Pin des ESP32 eine zu hohe Spannung anlag. Das kann beim ESP32 Ethernet Brick aber eigentlich nicht der Fall sein. Andere Nutzer hatten wohl auch wegen zu schwacher Versorgungsspannung das Problem. Du überlastest nicht zufällig die 3V3-Versorgung mit deinen ganzen zusätzlichen Bricklets? Ansonsten hatten anscheinend auch einige Nutzer Probleme mit DHCP vom AP und eine statische IP hat das Problem gelöst.

Puh, war das eine schwere Geburt... 🥵

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

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 😊

On 1/29/2026 at 6:00 AM, poohnet said:

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

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

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.

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. Das Problem ist, dass die Bibliothek im Hintergrund anscheinend einen eigenen Timeout für DHCP-Leases hat. Den können wir leider nicht beeinflussen.

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

bearbeitet January 29, 2026 at 14:2529. Jan 2026 von poohnet

On 1/29/2026 at 3:14 PM, poohnet said:

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

Mich wundert, dass es ein bis zwei Minuten gedauert hat, bis der Pi die Wallbox vergessen hat, nachdem es vorher fast 25 Minuten lang hing. Die Standardeinstellung des WPA Supplicant für nicht antwortende Stations ist fünf Minuten, also hätte ich irgendwas in dem Bereich erwartet:

# Station inactivity limit
#
# If a station does not send anything in ap_max_inactivity seconds, an
# empty data frame is sent to it in order to verify whether it is
# still in range. If this frame is not ACKed, the station will be
# disassociated and then deauthenticated. This feature is used to
# clear station table of old entries when the STAs move out of the
# range.
#
# The station can associate again with the AP if it is still in range;
# this inactivity poll is just used as a nicer way of verifying
# inactivity; i.e., client will not report broken connection because
# disassociation frame is not sent immediately without first polling
# the STA with a data frame.
# default: 300 (i.e., 5 minutes)
#ap_max_inactivity=300

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 dachte eher daran, dass jemand bewusst seinen AP wieder einschaltet und dann u. U. noch zwei Minuten warten muss, bis sich die Wallbox wieder verbindet.

Ich kann das Problem hier mit UniFi-APs nicht reproduzieren. Ich habe den Brick 0, 1, 2 und 3 Sekunden nach dem Got-IP-Event crashen lassen und die WLAN-Verbindung wurde trotzdem immer problemlos aufgebaut.

Aktuell ist mir das Verbindungsproblem noch zu nebulös und selten, als dass ich dafür die Zeit für neue Verbindungsversuche derart deutlich verlängern möchte.

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 🚓

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

bearbeitet January 31, 2026 at 15:3131. Jan 2026 von poohnet

On 1/31/2026 at 4:30 PM, poohnet said:

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

Korrekt. Rollback für die Config, ist, wie so Vieles, angedacht, existiert aber aktuell nicht.