rtrbt

Kannst du nochmal mit der Firmware im Anhang testen? Mit der kannst du unter Wallbox -> Einstellungen die "Wartezeit bei Phasen­umschaltung" einstellen. Standardwert sind 45 Sekunden. Reichen 45 Sekunden bei dir, oder musst du auf 60 Sekunden erhöhen? warp3_firmware-NIGHTLY_2_8_10_6904e3be_ee6c990911f5cea_merged.bin

Nochmal zum rekapitulieren: Hast du mit der Firmware die immer 60 Sekunden zum Phasenwechsel braucht, noch das Problem, dass die Willkommensladung immer dreiphasig sein muss? Oder hat sich das mit den längeren Phasenwechseln behoben?

The MQTT module for ESP32 bricks is not an implementation of the MQTT bindings (https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#api-bindings-mqtt) that allow you to control Bricklets via MQTT. You have to run the MQTT bindings on some PC, Raspberry Pi, etc. and can then use the unmodified ESP32 firmware to control attached Bricklets. If you want to build a custom firmware, you have to implement / pass-through calls to the Bricklets yourself, as is described here: https://www.tinkerforge.com/en/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html This is not very convenient, but currently there is no complete implementation of the MQTT bindings that can run on the ESP32 brick directly.

Ist sie im Moment, das ist aber ein Bug. Wird mit dem nächsten Firmware-Release gefixt.

Mit ISO 15118 kann man außerdem weniger als 6 A Ladeleistung freigeben -> besseres PV-Überschussladen (manche) Autos erkennen, ohne dass man ein NFC-Tag ö.Ä. verwenden muss, siehe z.B. https://docs.evcc.io/docs/features/vehicle#erkennung-via-plug--charge eventuell auslesen, was die maximale Ladeleistung des Autos ist -> besseres Lastmanagement möglicherweise verhindern, dass Autos so einschlafen, dass man sie nicht wieder aufwecken kann -> das ist auch relevant für's PV-Überschussladen

Wir haben hier einen älteren Enyaq, einen Born, einen neueren ID.3, einen ID.Buzz und seit neustem zwei Elroqs und ich wüsste nicht, dass wir spezifisch dieses Problem schon einmal hatten. Fairerweise laden die aber fast immer an WARP2, also Wallboxen ohne Phasenumschaltung. Der ID.3 hatte einmal Probleme mit der Phasenumschaltung, denen wir aber bisher noch nicht nachgegangen sind, weil sie nicht wieder aufgetreten sind. Ich habe mit dem ID.3 gerade nochmal genau das versucht, was du beschrieben hattest, also einphasig laden (da waren noch 32 A eingestellt) für 5 Minuten 5 Minuten Ladepause einphasig laden 6A für 5 Minuten einphasig laden 16A für 2 Minuten umschalten auf dreiphasig Das hat funktioniert. Ist also anscheinend nicht bei allen VWs identisch kaputt.

Sieht gut aus! Je nachdem ob du das Regel-Intervall von EVCC umgestellt hast (https://docs.evcc.io/docs/reference/configuration/interval, Standardwert sind 30 Sekunden) solltest du die Verzögerung um ein paar Sekunden (z.b. auf 35) erhöhen. Wenn du richtig Pech mit dem Timing hast, könnte es sein, dass EVCC die "pv"-Nachricht sieht, bevor es die Information auswertet, dass ein Auto angesteckt ist.

Vielleicht kannst du dich da kreativ raushacken. Eine Idee: Du kannst auf der Wallbox Automatisierungsregeln anlegen und EVCC hat eine MQTT-API (siehe hier https://docs.evcc.io/docs/integrations/mqtt-api#loadpoints). Du könntest also folgendes bauen: - Wenn ein Auto angesteckt wird (das sieht die Wallbox sofort und EVCC mit einer Latenz von bis zu 30 Sekunden), setzt du den Lademodus von EVCC auf Schnell (in der Erwartungshaltung, dass EVCC dann dreiphasig laden wird) - Nach X Minuten (also eine zweite Regel mit der gleichen Bedingung, aber einer Verzögerung von X * 60 Sekunden) setzt du den Lademodus wieder auf PV z.B: Die Namen der Lademodi sind bei EVCC anscheinend nur in der REST-API dokumentiert, hier: https://docs.evcc.io/docs/integrations/rest-api einmal nach /mode suchen. Damit dir das dreiphasige Willkommensladen dann nicht zu viel aus dem Netz zieht, kannst du noch zwei Regeln mit identischer Bedingung anlegen, die den Ladestrom auf 6 A begrenzen bzw. nach X Minuten dann wieder auf 32 A freigeben (das ist ein von EVCC unabhängiges Limit) z.B: Problematisch daran ist, dass es im Moment ein hartes Limit für die MQTT-Automatisierungsregeln gibt, ein Topic darf maximal 32 Zeichen lang sein. D.h die ID des Loadpoints musst du in der EVCC-Konfiguration eventuell zusammenkürzen.

This sentence is worded somewhat misleadingly: ESP32 Bricks (and ESP32 Ethernet Bricks) don't show up as Bricks in the list of connected devices if connected via USB: They still show up in the "Updates / Flashing" window under Bricks: If you (re)flash the ESP32 Ethernet firmware here, this will also do a factory reset.

Das geht den Menschen wie den Leuten :D https://github.com/Tinkerforge/esp32-firmware/commit/82e9b46b

Hast du daran gedacht in der ::setup-Methode deines Backend-Moduls initialized = true zu setzen? Das macht die Standard-Implementierung von IModule für dich, aber wenn du ::setup überschreibst, musst du das selbst machen. Das NavbarItem ist so gebaut, dass es den Eintrag versteckt, wenn das Backend-Modul nicht initialisiert werden konnte.

Sollte nicht: Dieses Verhalten des ioBroker-MQTT-Plugins ist der Grund warum wir leere Nachrichten nicht mehr auf "payload-losen" Topics erlauben, sondern etwas fordern, das nach JSON riecht. Und es kam in dem Fall eine leere Nachricht an: Topic evse/stop_charging is an action. Ignoring empty message.

Über die API kannst du da im Moment nicht viel tun, ggfalls flexibilisieren wir das irgendwann. Du könntest aber folgendes machen: Die dynamischen Strompreise werden von api.warp-charger.com abgerufen, konkret https://api.warp-charger.com/v1/day_ahead_prices/de/60min Der Host ist Teil der Konfiguration der dynamischen Strompreise: https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/day_ahead_prices/#day_ahead_prices_config_any Du könntest also theoretisch einen kleinen Webserver aufsetzen, der statt einem dynamischen Strompreis immer deinen Nachttarif zurückgibt.

Wenn ich die Regeln richtig verstehe ist also in folgenden Intervallen der Strom günstig: Mo 22:00 bis Di 06:00 Di 22:00 bis Mi 06:00 Mi 22:00 bis Do 06:00 Do 22:00 bis Fr 06:00 Fr 22:00 bis Sa 06:00 (das ist der folgende Tag vom Freitag, der ein Wochentag ist) Sa 13:00 bis Mo 06:00 (Sa 13:00 bis 24:00 und So 00:00 sind der gleiche Zeitpunkt, Regel 3 gilt bis 06:00 des folgenden Tags, also Montag) korrekt? (Feiertage ignorieren wir mal :D) Dann hast du also jeden Tag von 22:00 bis 06:00 günstigen Strom und zusätzlich noch Sa von 13:00 bis 22:00 und So von 06:00 bis 22:00 Das sollte also mit folgenden Regeln gehen: Jeden Tag 22:00 Lademodus auf Schnell Wochentags (gibt es als Extra-Eintrag bei der Tages-Auswahl der Zeitpunkt-Bedingung) 06:00 Lademodus auf PV Samstags 06:00 Lademodus auf PV Samstags 13:00 Lademodus auf Schnell (das wird dann Montag 06:00 aufgehoben) Das stimmt. Alternativ könntest du als Standard-Lademodus Schnell benutzen und den im Sommer auf PV umstellen, dann machen die ganzen Regeln im Sommer nichts mehr.

Button heißt in dem Fall der Fronttaster. Du solltest dann noch unter Wallbox -> Einstellungen die Taster­ein­stellung auf "keine Aktion" setzen. Sonst wird der Ladevorgang beendet wenn du den Taster drückst. Alternativ kannst du als Bedingung der 1. Regel auch folgendes einstellen (blah ersetzen durch was auch immer du willst :D ), dann hast du einen Link den du im Webinterface auch anklicken kannst.

Wäre dir geholfen, wenn du mit Automatisierungs-Regeln (die können schon Wochentage als Bedingung haben) Ladepläne für den Eco-Modus setzen kannst? Also z.B. einen Plan der eine Stunde pro Tag laden lässt, aber am Wochenende bzw. nur Sonntags wird auf einen Plan umgeschaltet, der die billigsten 10 Stunden benutzt.

Steht auf der Liste: https://github.com/Tinkerforge/esp32-firmware/issues/425

Firmware: WARP2 2.8.10, WARP3 2.8.10 Weiteres Problen behoben, durch dass eine CP-Trennung manchmal dazu führte, dass das Fahrzeug als getrennt betrachtet wurde (durch Update auf Ladecontroller-Firmware 2.2.16) Download: WARP2 2.8.10 bzw. WARP3 2.8.10

Firmware: WARP1 2.8.9, WARP2 2.8.9, WARP3 2.8.9, WARP Energy Manager 2.4.9, WARP Energy Manager 2.0 1.3.9 Hinzugefügt, dass Teile einer API mit einem URL- oder Topic-Suffix gelesen (nur über HTTP) und geschrieben (HTTP und MQTT) werden können Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: VARTA Element/Flex Batteriespeicher, Chisage ESS Hybrid-Wechselrichter SunSpec: Falsche Phase-zu-Phase-Spannungswerte für WattNode-Stromzähler erneut korrigiert Fortschrittsanzeige des Firmware-Updates verbessert Behoben, dass lastgemanagte Wallboxen nach 49 Tagen fälschlicherweise als "gestört" angezeigt wurden (Nur WARP1, WARP2, WARP3) Behoben, dass Fronttaster-LED-Steuerung per API nicht immer akzeptiert wurde, wenn der letzte Steuerbefehl auch über die API erhalten wurde (Nur WARP2, WARP3) Behoben, dass eine CP-Trennung manchmal dazu führte, dass das Fahrzeug als getrennt betrachtet wurde (durch Update auf Ladecontroller-Firmware 2.2.15) (Nur WARP2, WARP3) Unnötig lange Wartezeit nach Ende der CP-Trennung behoben (durch Update auf Ladecontroller-Firmware 2.2.15) (Nur WARP2, WARP3) Unterstützung für Eltako DSZ16DZE hinzugefügt Download: WARP1 2.8.9 bzw. WARP2 2.8.9 bzw. WARP3 2.8.9 bzw. WARP Energy Manager 2.4.9 bzw. WARP Energy Manager 2.0 1.3.9

Als letzten Akt der Verzweiflung kann ich dir noch vorschlagen, dass du die LAN-(nicht WLAN-)Schnittstelle komplett deaktivierst. Laut Debug-Report hast du kein Kabel angeschlossen, aber die Initialisierungsreihenfolge der Schnittstellen ist interessant: 2025-08-30 07:12:59,651 | wifi | Connected to 'Ironangel', b+g+n ch.6 HT20 WPS [DEI] -68dBm, BSSID 60:B5:8D:57:67:80 2025-08-30 07:12:59,663 | wifi | Got IP address: 192.168.1.4/24. Own MAC address: 58:BF:25:B8:59:E4 2025-08-30 07:13:00,114 | ethernet | Started 2025-08-30 07:13:00,392 | network | Network connected (WiFi) Ich habe das Timing hier nachgestellt und es hat dein Problem nicht verursacht, aber eventuell ist dein Setup so speziell, dass das trotzdem hilft.

Ja, die EVCC-Einrichtungsdoku ist ziemlich veraltet, müssen wir mal angehen.

Kannst du nochmal über den Fernzugriff einen Debug-Report ziehen?

Das klingt nach einem Problem mit den DHCP-Leases, aber laut Log hat die Wallbox die per DHCP zugeteilte IP nie verloren; seltsam. Aber hauptsache es funktioniert jetzt.

Gut dass du das herausgefunden hast, das hätte ich nicht aus der Ferne diagnostizieren wollen :D

Die 192.168.1.98? Kurze Bestandsaufnahme: Du konntest mit http://192.168.1.98 auf die Wallbox zugreifen, bevor du den Fernzugriff/die App eingerichtet hast Die Wallbox kann sich zum Fernzugriffs-Server verbinden Die Wallbox kann deinen Shelly im lokalen Netz erreichen Du kannst weder vom Smartphone noch vom PC aus (die beide im gleichen lokalen Netz sind wie vorher) die Wallbox erreichen Die Netzwerkeinstellungen usw. auf der Wallbox sind wie ich sie erwarten würde (keine IP-Adresskonflikte, der Webserver-Port ist nicht verstellt usw.) -> Das ist kein prinzipielles Netzwerkproblem der Wallbox, irgendetwas muss subtiler kaputt sein. Um das weiter einzugrenzen: Kannst du die Wallbox-IP anpingen und bekommst Antworten? Wenn ja: Bekommst du eine Antwort wenn du z.B. auf http://192.168.1.98/info/version zugreifst? Müsste ungefähr so aussehen: {"firmware":"2.8.8+68935ab2","config":"2.8.4","config_type":"warp"} Wenn das auch geht: Kannst du auf die Recovery-Seite unter http://192.168.1.98/recovery zugreifen? Erreichst du mit dem gleichen PC/Smartphone das Webinterface von deinem Shelly?