MatzeTF

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.

Es gibt bei der Wallbox eigentlich nichts, das sich durch neu installieren beheben ließe. Ein WARP3 Charger ist schließlich kein Windows PC oder sowas. 😉 Wenn es eine falsche Einstellung wäre, würden wir dir das sagen und du könntest sie einfach ändern. Wenn es ein Softwareproblem ist, hilft neu installieren auch nicht, weil du dann die selbe Firmware mit exakt dem selben Problem installierst. Falls du mit „neu installieren“ Zurücksetzen auf den Werkszustand meinst, also ein Löschen aller Einstellungen, hilft das bei einem Softwareproblem auch nicht. Das Problem mit den immer wieder auf 04:00 zurückspringenden Zeiten beim PV-Überschussladen kommt daher, dass keine neuen Werte vom SHM empfangen werden. Das ist ein bekanntes Problem, das im Dezember durch ein Bibliotheksupdate entstanden ist, und wird mit dem nächsten Firmware-Release repariert. Du kannst schon jetzt die angehängte Testfirmware ausprobieren und beobachten, ob sie das Problem behebt. Edit: Veraltete Firmware entfernt.

Die zweite Entladeregel ist aktiv. Anscheinend hast du den Vorschlag von meierchen006 umgesetzt und eine Regel angelegt, die den Speicher blockiert, wenn keine Schnelladung aktiv ist. Das trifft aber immer zu, wenn keine Schnelladung aktiv ist, also sowohl wenn eine PV-Ladung aktiv ist, als auch wenn gar keine Ladung aktiv ist oder nicht mal ein Fahrzeug angeschlossen ist. Die Regel „Kein Entladen beim Laden“ solltest du also entfernen.

Kannst du bitte einen Debug-Report runterladen (unter System → Ereignis-Log) und hier anhängen? Ein Ladeprotokoll hilft mir hier leider nicht weiter. Falls möglich, lade den Debug-Report runter, kurz nachdem die springende Zeit aufgetreten ist. Falls die Zeit gerade nicht springt, lade trotzdem einen Debug-Report runter, damit ich mir schonmal andere Sachen ansehen kann. Weißt du zufällig, ob außer dem Smart Home Manager 2.0 noch ein SMA Energy Meter irgendwo verbaut ist?

Dass die Anzeige beim Runterzählen um ein paar Sekunden vor und zurück springt, ist ein bekanntes Problem. Es handelt sich dabei aber nur um ein Problem bei der Anzeige; die Wallbox selbst zählt richtig runter. Dass die Zeit immer wieder auf 04:00 (oder kurz davor) springt, ist bei fallender PV-Leistung auch erwartet, wenn auch zugegebenermaßen etwas verwirrend. PV-Überschussladen nutzt eine vier Minuten lange Historie des Netzbezuges. Die angezeigte Zeit ist die Dauer, bis der schlechteste Wert aus der Historie gewandert ist. Fällt der PV-Überschuss gerade, kommt immer wieder ein neuer schlechtester Wert dazu und die Zeit springt zurück auf vier Minuten.

Der Topic-Präfix kann etwas fast beliebiges sein. „warp/2at5“ funktioniert genauso gut wie „warp2at5“ oder „wallbox“. Der Topic-Präfix sollte nicht mit „homeassistant“ beginnen. Der Discovery-Topic-Präfix muss für Home Assistant exakt „homeassistant“ sein, ohne etwas dahinter. Die Wallbox sorgt selbst dafür, dass dort das korrekte Device und die korrekte ID angehängt werden. Das Device ist weder „device“ noch „warp“, sondern etwas Home Assistant-spezifisches, wie z. B. „sensor“, „number“ oder „button“, je nach Element. Der Discovery-Modus muss natürlich auf „Home Assistant“ eingestellt werden. „Generisch“ versteht Home Assistant nicht. Für die Neugierigen, die korrekt generierten Topics sehen z. B. so aus: homeassistant/sensor/warp2-2abc/chargerstate/config homeassistant/sensor/warp2-2abc/allowedcurrent/config homeassistant/number/warp2-2abc/globalcurrent/config homeassistant/button/warp2-2abc/startcharge/config homeassistant/button/warp2-2abc/stopcharge/config homeassistant/binary_sensor/warp2-2abc/cable/config homeassistant/binary_sensor/warp2-2abc/ready/config homeassistant/binary_sensor/warp2-2abc/charging/config homeassistant/binary_sensor/warp2-2abc/error/config homeassistant/binary_sensor/warp2-2abc/online/configMan erkennt hoffentlich, warum der Discovery-Topic-Präfix exakt „homeassistant“ sein muss.