MatzeTF
Administrators
-
Benutzer seit
-
Letzter Besuch
-
Firmware Auto-Recovery
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.
-
Firmware Auto-Recovery
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?
-
Firmware Auto-Recovery
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?
-
Firmware Auto-Recovery
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.
-
Firmware Auto-Recovery
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.
- WARP2 Charger und Sungrow WR - ModBus
- WARP2 Charger und Sungrow WR - ModBus
-
WARP2 Charger und Sungrow WR - ModBus
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.
-
MatzeTF folgt jetzt dem Inhalt: Firmware Auto-Recovery , WARP2 Charger und Sungrow WR - ModBus und Aktuellen Strompreis per MQTT setzen
-
Firmware Auto-Recovery
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.
-
Firmware Auto-Recovery
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?
-
Firmware Auto-Recovery
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.
-
Firmware Auto-Recovery
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.
-
Aktuellen Strompreis per MQTT setzen
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.
-
Firmware Auto-Recovery
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.
-
WARP3 EVCC: "Automatische Phasenumschaltung" wird im User Interface nicht angeboten
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.