MatzeTF

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. Während sich die Wallbox die ganze Zeit über WIFI_REASON_AUTH_EXPIRE beschwert, steht im Log des Pi dann nichts Neues? 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. Danke für deine Ausdauer, dem Problem auf den Grund zu gehen.

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.

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. Ich werde das jetzt trotzdem erstmal nicht weiter verfolgen, da ich hoffe, dass sich das Problem üblicherweise durch ausreichend lange Strom abschalten umgehen lässt. 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. 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. 🙈

Ich wollte damit nicht sagen, dass die Schuld beim Pi liegt. 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. Wegen zwei möglicher Ursachen hatte ich vorgeschlagen, mal in den Logs des Pi nachzusehen: Nach dem Rollback sendet der Brick Unsinn und der Pi lässt ihn deswegen nicht rein. Der Pi hat irgendein Problem, das der Brick aber nur durch den Rollback trifft.

Im nächsten Release entferne ich WLAN. 🙈 Dein AP ist angeblich ein Raspberry Pi. Vielleicht sagen dir dessen Logs, warum sich die Wallbox nicht verbinden darf.

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.

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?

Ja, das ist ein Stack-Frame vorher. Habe ich eben bei uns auf Master repariert. 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?

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:859Edit: Und gefixt.

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.

Weißt du, ob der Wechselrichter an den Stromzähler vom Netzbetreiber oder einen anderen externen Netzbezugszähler angeschlossen ist?

Auf welcher Seite des Wechselrichters ist die Wallbox angeschlossen? Load- oder Grid-Seite?

Beim „Grid“-Zähler hast du den virtuellen Zähler „Inverter“ ausgewählt, also die Wechselrichterleistung. Stell das doch mal auf „Grid“ um. Tipp: Wenn man glaubt, eine abweichende Location einstellen zu müssen, hat man meist was falsch gemacht. Falls die Einstellung „Grid“ auch nicht hilft, lade bitte einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

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.

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?

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.

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.

Wenn du nur den oben auf der Seite des Ladetrackers angezeigten Strompreis ändern möchtest, ist das möglich. Schick einfach den Preis in Cent an „warp/2345/charge_tracker/config_update/electricity_price“. Beachte allerdings, dass der Preis nicht pro Ladung gespeichert wird. Wenn du den Preis änderst, werden anschließend auch alle vorigen Ladungen mit dem neuen Preis berechnet. Ansonsten setz das besser nicht 24 Mal am Tag, da jede Preisänderung immer in den Flash-Speicher der Wallbox geschrieben wird.

Hast du diese Option bei den custom_options deines Platform IO-Environments gesetzt? Kannst du aus der warp2.ini klauen. firmware_update_enable_rollback = 1Wenn 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.

Also laut Debug Report ist die Phasenumschaltung der Wallbox aktiv und bereit. Ich weiß leider nicht, was EVCC da noch zu meckern hat. Da hinter „wakeup“ ebenfalls ein ✘ steht, kannst du mal unter Wallbox → Einstellungen den Fahrzeug-Weckruf umstellen? Da die Zeiten vom EVCC-Log früher sind als die vom Debug-Report, hast du schon EVCC neugestartet? Möglicherweise überprüft EVCC die Wallbox-Einstellungen nur beim Start und bekommt nicht mit, wenn man sie erst später richtig einstellt.

Die Batteriesteuerung ist im heutigen Firmware-Release nicht enthalten. Es wird voraussichtlich bald eine neue Firmware mit Batteriesteuerung geben.

War damals auch so erlaubt und genießt meines Wissens Bestandsschutz. Inzwischen muss man üblicherweise bei neu installierten 11 kW-Wallboxen auch eine Möglichkeit zur Leistungsreduktion vorsehen.

Bist du sicher, dass das ein Type 2-Sensor ist? Die werden nämlich immer zwischen der positiven Versorgungsspannung und dem Messeingang angeschlossen, da sie keine eigene Spannungsversorgung haben. Der Beitrag von borg bezog sich auf einen Sensor mit eigener Spannungsversorgung, was meines Wissens kein Type 2-Sensor ist. Dessen Ausgang benötigt in der Tat Masse als Bezugspunkt.

Beides hatte die selbe Ursache und sollte nun repariert sein. Bitte melde dich, falls mit der Firmware aus meinem vorigen Post eines der Probleme immer noch besteht.

Kommt voraussichtlich mit dem nächsten Firmware-Release.