rtrbt

Dafür musst du übrigens den EM300 auswählen. Mit der nächsten Firmware wird der EM340 mit erwähnt: https://github.com/Tinkerforge/esp32-firmware/commit/563ec60583389d03fb3422c23d5d7a3d41415d21

https://github.com/Tinkerforge/dbus-warp-charger die hohe CPU-Load sollte gefixt sein. Stellt sich raus das Script hat alle 250ms 9 HTTP-Requests gemacht, das war etwas viel. Es gibt jetzt in der config.ini den Wert UpdateInterval, der angibt wie oft die Daten aktualisiert werden, mit default 1 (=Sekunden). Außerdem macht ein Update nur noch die Hälfte an Requests und die Auto-Start-Logik war kaputt, das sollte jetzt auch passen.

Die config liest nicht den error_state, sondern den charger_state. charger_state 4 bedeutet, dass irgendein Fehler vorliegt.

Leider noch nicht.

Zieh bitte einmal einen Debug-Report (unter System->Ereignislog) und poste ihn hier oder schicke ihn an erik@tinkerforge.com

Das steht leider nicht direkt auf der API, sondern das Webinterface baut den Text zusammen. Im Endeffekt musst du evse/slots auswerten. Jeder Slot dessen Wert gleich dem Minimalwert ist, ist einer der vom Webinterface aufgelistet werden würde. Die Namen der Slots findest du z.B. hier: https://github.com/Tinkerforge/esp32-firmware/blob/586496e0e54e6ab4c4fa5e9efe5e6e9877dae3ff/software/web/src/modules/evse_common/translation_de.tsx#L123-L139 (da steht ein TODO an der API-Dokumentation, weil die Slotnamen fehlen, das hat leider noch keiner geschafft einzubauen)

Das liegt vermutlich daran, dass deine WARP2 als Energiewert (für Ladetracker usw.) noch den Bezugs + Einspeisungswert verwendet. Der wird dann auch im Modbus Register 2004 ausgegeben. Details hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (letzte Zwischenüberschrift) Du kannst jetzt entweder stattdessen Register 2160 lesen oder wie im Blogpost beschrieben einmal die aufgezeichneten Ladevorgänge löschen, dann wechselt die Wallbox auf den Bezugswert. (Oder das "offizielle" Registerset aus der Testfirmware verwenden)

Genau, die werden nur im RAM gehalten. 7680 Ladevorgänge lang. Da war die Idee, dass selbst eine sehr gut genutzte Wallbox (10 Ladevorgänge am Tag) mehr als 2 Jahre aufzeichnen können soll. Wenn die 7680 Ladevorgänge erreicht sind, wird der erste Block (256 Ladevorgänge) weggeworfen, damit neue aufgezeichnet werden können.

Uns ist adhoc nicht klar, wie es sein kann, dass die Konfiguration kaputt ist. Versuch bitte mal die Firmware im Anhang. Die sollte dir ins Ereignislog ausgeben, was in der Konfiguration drin steht. [Edit: Test-Firmware entfernt]

Du kannst übrigens unter Energiemanagement -> Lastmanagement die Details aufklappen und da bei den Limits einen Blick auf PV Min werfen. Das ist der Wert, der mindestens bei 18,000 A (= 4140W/230V) liegen muss. Edit: Drei Phasen -> 18 A statt 6.

Laut https://docs.evcc.io/docs/devices/chargers#solaredge-home-ev-charger spricht die SolarEdge-Wallbox Modbus TCP mit dem selben Registerset wie die Keba Wallboxen. Das Keba-Registerset kann der WARP Charger emulieren (unter Schnittstellen -> Modbus TCP aktivieren und als Registerset "Kompa­tibel zu Keba P30 C-Series" auswählen) Mit Glück funktioniert das dann einfach.

Das Verhalten kennen wir von fast allen VWs: Wenn der Stecker nicht ganz drin steckt, dann kann das Auto nicht den Verriegelungsstift ausfahren und lädt in einer Art Notlademodus. Siehe z.B. hier

Hier noch mehr Leute mit dem selben Problem (und auch anderen Wallboxen. Das Verhalten von EVCC ist aber sehr ähnlich zu dem was wir tun) https://github.com/evcc-io/evcc/discussions/15964

Leider nur noch die absurden: Es gibt bei diversen VW-Autos (auch Cupra, Skoda usw.) Probleme nach dem Software-Update auf/über Version 3.7, wenn du die per OTA-Update (also nicht in der Werkstadt) bekommen hast. Abhilfe schafft da gerüchteweise, wenn du eine bestimmte Sicherung im Motorraum ziehst. Siehe z.B.: https://github.com/evcc-io/evcc/discussions/12791 und

Das ist geplant, aber leider noch nicht implementiert: https://github.com/Tinkerforge/esp32-firmware/issues/47