Jump to content
View in the app

A better way to browse. Learn more.

Tinkerunity

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Geschrieben
  • Autor
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 😂

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

Geschrieben
  • Autor
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?

Geschrieben
  • Autor

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 von poohnet

Geschrieben

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.

Geschrieben
  • Autor
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 😊

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.