MatzeTF

Der WEM kann aktuell kein transparenter Modbus-Proxy sein und er kann auch nur einen einzigen kompatiblen Zähler an seinem RS485-Anschluss auslesen. Technisch ist das prinzipiell möglich, aber dafür müsstest du die Energy Manager Bricklet-Firmware, Bricklet-API und das ESP-Firmware-Modul dazu selbst anpassen. Was aktuell aber schon möglich ist, wenn du dir eine ESP-Firmware selber baust, ist ein Übertragen der Zählerwerte von WEM zu WARP über MQTT. Es gibt das Front- und Backend-Modul „Meters Mqtt Mirror“. Wenn du das in der WARP einbaust, kannst du einfach das Topic des entsprechenden WEM-Zählers angeben und bist fertig. Das Modul existiert, weil wir das zum Testen exakt so verwenden. Da über das Mirror-Modul jeder Zähler des WEM kopiert werden kann, kannst du auch den zweiten Zähler über die Modbus-Bridge im WEM einrichten und die WARP kopiert den dann auch. Da es MQTT mit Push-Nachrichten ist, hast du auch keine Durchsatzprobleme.

Deine Annahmen sind alle korrekt. Die Wallbox kann den Schattenscan des Wechselrichters nicht von einer durchziehenden Wolke unterscheiden. Leider ist es nicht ganz einfach, die dadurch entstehenden Artefakte aus den Stromzählerwerten rauszufiltern, ohne sich dafür andere Nachteile einzukaufen. Insbesondere würde das PV-Überschussladen dadurch träger werden. Die – im Vergleich zu anderen Wallboxherstellern – schnelle Reaktionsfähigkeit unseres PV-Überschussladens wird aber von anderen Nutzern geschätzt, weshalb ich das ungern schlechter machen möchte. Ich setze den Punkt mal auf meine Todo-Liste, aber da die schon sehr voll ist, solltest du besser keine schnelle Lösung erwarten. Ansonsten hast du den möglichen Workaround bereits erkannt: den Wolkenfilter auf „Mittel“ (4 Minuten) stellen. Alternativ könnte man auch den Schattenscan auf 9 Minuten stellen, aber ich weiß nicht, ob das möglich ist.

Ja. Sie wird übrigens auch erst nach einem Neustart aktiv. Hatte ich vergessen zu erwähnen.

Ich bin aktuell im Urlaub und kann das nicht testen, aber versuch mal das hier. Du kannst eigentlich nichts kaputt machen. Schlimmstenfalls funktioniert es nicht. Geh auf http://warp3-abcd/battery_control/low_level_config und kopiere den Text, der da steht. Vielleicht musst du erst noch die Rohansicht aktivieren oder alternativ Strg+A und Strc+C nutzen, um den Text zu kopieren. Geh auf http://warp3-abcd/recovery und nutze das Eingabefeld unter „API“. Da steht ein Beispiel drin, wie du die Eingabe formatieren musst. Du kannst die Eingabe auch erst in einem Texteditor zusammenbauen, damit du das Beispiel dabei noch sehen kannst. Die URL ist "/battery_control/low_level_config" und als Payload musst du den Text vom vorigen Schritt reinkopieren und die Zahl auf irgendwas unter 60 ändern. Achte darauf, dass die Anzahl der öffnenden und schließenden Klammern passt. Drück „Call API“. Wenn im Feld darunter „200“ angezeigt wird, ist alles ok. Falls nicht „200“ drin steht, steht üblicherweise entweder dort oder im Ereignis-Log eine Fehlermeldung. Falls du ein Linux-curl hast, kannst du die API auch mit curl -d aufrufen (ggf. mit -X PUT). Das möchtegern-curl der Windows PowerShell ist meist nicht zu gebrauchen.

Die Funktion ist bereits enthalten. Standardmäßig werden die aktiven Aktionen alle 60 Sekunden wiederholt. Die Zykluszeit ist aktuell über eine undokumentierte Debug-API auf einen beliebigen Wert im Bereich 5 – 99999  Sekunden einstellbar. Ich überlege noch, 0 zuzulassen, um die Funktion deaktivieren zu können.

Ich habe dir mal schnell eine Grafik gebaut. „raw“ ist der am Hausanschluss gemessene Überschuss, aufsummiert in Milliampere. 90000 bedeutet, du hättest dreiphasig 30 A über. „min“ und „max“ sind die durch den Wolkenfilter verschleiften Minimal- und Maximalwerte der letzten vier Minuten. Dein Ladevorgang beginnt beim Datenpunkt 7670. Eine Minute vorher ist gerade eine Wolke durchgezogen und das Minimum liegt bei ca. 11 A. Das reicht nicht für dreiphasiges Laden (mindestens 18 A in Summe). Die Entscheidung, einphasig zu laden, war auch eine gute Idee, da direkt nach Ladebeginn weitere Wolken durchgezogen sind, sodass der verfügbare Ladestrom teilweise sogar unter den minimal möglichen Ladestrom von 6 A gedrückt wurde. Ansonsten kann man an der Grafik gut sehen, dass zumindest die gesamte vorige Stunde, die im Log enthalten ist, stark wechselnd bewölkt war. Bei solchem Wetter ist es praktisch unmöglich, gutes PV-Überschussladen zu machen und ich empfehle, dass du dir das Ladeverhalten in dem Fall nicht zu kritisch ansiehst. Wir haben uns viel Mühe gegeben, auch dann noch das Bestmögliche rauszuholen, und mehr geht unserer Meinung nach nicht, zumindest nicht, ohne andere Nachteile in Kauf zu nehmen, wie z. B. mehr Strombezug aus dem Netz bei durchziehenden Wolken.

Nein, die hier ist neu gebaut von heute Mittag. Das kann man an der achtstelligen Hexadezimalzahl hinter der Versionsnummer erkennen. … wobei mir gerade auffällt, dass die alte Datei nicht mehr da ist und man die Nummern nicht mehr einfach vergleichen kann. Dann kann man sie nur noch in Dezimal umrechnen und als Unix-Timestamp interpretieren. 😉 $ date -d @$((0x6888a212)) '+%F %T' 2025-07-29 12:27:30

Die Wallbox könnte das Kabel höchstens auf ihrer Seite freigeben, wenn es dort eingesteckt und nicht fest angeschlossen wäre. Die Verriegelung im Fahrzeug wird ausschließlich vom Fahrzeug gesteuert. Die Wallbox hat darauf keinen Einfluss. Bei einigen Fahrzeugen kann man einstellen, dass das Kabel am Ladeende freigegeben wird. Bei anderen Fahrzeugen kann man das Kabel nur per Schlüssel bzw. Annäherung mit Schlüssel freigeben. Sinn und Zweck des Ganzen ist natürlich, dass dir an einer öffentlichen Ladesäule nicht einfach jemand das Ladekabel klauen kann.

Wenn du möchtest, dass seltener geschaltet wird, kannst du schon jetzt den Wolkenfilter auf „Stark“ stellen. Die Pausen werden dem Ladegerät ziemlich egal sein. Wenn etwas relevant ist, wird es die Anzahl der Schaltvorgänge sein.

Das Log hilft mir leider nicht weiter. Ich glaube, mit diesem Problem bist du bei der EVCC-Community besser aufgehoben. Soweit ich weiß gibt es dort viele Nutzer, die auch eine WARP2 oder WARP3 haben, und die kennen sich dort besser mit den EVCC-Problemen aus.

Dass ein Ladevorgang manchmal anscheinend unnötigerweise einphasig beginnt, ist ein bekanntes Problem. Leider hatten wir noch nicht genug Protokolle dazu und da sich das Problem nach kurzer Zeit selbst korrigiert, waren bisher andere Dinge wichtiger, sodass das liegen geblieben ist. Mit deinem Protokoll haben wir schon mal einen zusätzlichen Datenpunkt, um das Problem weiter einzukreisen.

Hast du schon unter Wallbox → Einstellungen den automatischen Phasenwechsel deaktiviert? Ansonsten ist die EVCC-Meldung ziemlich nutzlos, da sie nicht sagt, was als „enabled“ erwartet wird. Da EVCC den Fehler meldet, wird ein Ladeprotokoll nicht weiterhelfen. Such mal das EVCC-Log und hänge es hier an, wenn der Fehler drinsteht.

Die Statusanzeige zeigt dir an, zu welchem Ergebnis die eingestellten Regeln führen. Wenn du die einzelnen Aktionen von Hand ausführst, beeinflusst das die Statusanzeige nicht.

Kannst du mir mal deinen Breiten- und Längengrad per PM schicken?

Keine Ahnung. Das musst du vielleicht einfach ausprobieren.

Soweit ich weiß, ist das im OCPP-Standard vorgeschrieben. Vielleicht ist es möglich, den OCPP-Server über eine lokale Freigabe zu informieren, aber das hilft nicht in den Fällen, wenn der Server trotzdem „nein“ sagt oder nicht erreichbar ist.

Ein OCPP-Server erwartet immer, die volle Kontrolle über eine Wallbox zu haben. Mit einer Oder-Verknüpfung ist es da nicht getan. Es ist bestimmt möglich, da irgendwas zu hacken, aber das ist voraussichtlich viel mehr Aufwand, als wir aktuell in einen derartigen Hack investieren können. Die vorgesehene Variante ist genau das, was du schon genannt hast: Der OCPP-Server muss deine Tags kennen. Es würde mich wundern, wenn du der einzige bist, der genau das mit charge@friends machen möchte, und es dazu noch keine öffentlichen Informationen in irgendwelchen Foren gibt. Für den Fall, dass der charge@friends-Server ausfällt und du nicht laden kannst, kannst du natürlich mit wenigen Klicks OCPP aus- und NFC einschalten, damit du dich lokal authentifizieren kannst. Deine NFC-Tags können dauerhaft in der Wallbox registriert bleiben, selbst wenn du die lokale NFC-Authentifizierung ausschaltest.

Es gibt keine direkte Kommunikation zwischen der Wallbox und EVCC. Die Kommunikation läuft üblicherweise über MQTT. EVCC hört auf die Statusmeldungen, die die Wallbox immer rausschickt, und schickt Kommandos an die MQTT-API der Wallbox. Wenn du EVCC steuern möchtest, versuch rauszufinden, ob man das per MQTT-Nachrichten an EVCC machen kann, und verschicke die entsprechenden MQTT-Nachrichten per Automatisierungsregeln.

Es gibt bereits eine Ertragsprognose, die logischerweise vom Wetter abhängt. Die vorhergesagten Kilowattstunden für den aktuellen Tag kannst du schon jetzt für die Regeln der Batteriesteuerung verwenden.

Es gibt ein neues Feature zum Ausprobieren: Es ist nun möglich, dass ein Zeitplan in Abhängigkeit vom dynamischen Strompreis angelegt und bei den Regeln benutzt werden kann. Beispielsweise können die günstigsten drei Stunden in einem Zeitfenster von 20:00 bis 20:00 des Folgetages ausgewählt werden, um einen Speicher zu laden. Sinnvollerweise sollte das mit der PV-Vorhersage und dem Batterieladestand kombiniert werden. Die Firmware-Datein im ersten Post wurden durch die neuen Versionen ersetzt.

Während das Problem gerade besteht, lade bitte einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

Dass das Feature in Arbeit ist, kannst du bei uns – im Gegensatz zu anderen Herstellern – in unseren öffentlichen Software-Repositories verifizieren, sofern du das entsprechende Programmierwissen dazu hast. Da fast noch kein Energieversorger EEBus-kompatible Steuerboxen ausliefert, ist das in der Tat ein Henne-Ei-Problem. Ich weiß von einem Kunden, der schon eine EEBus-Steuerbox hat, die aber wohl noch nicht nutzbar ist. Das war schon immer nur eine Notlösung. Wir setzen hier auf EEBus. Die WARP3 schöpft in dem Bereich inzwischen alle Möglichkeiten aus, die die Signalisierung einer AC-Wallbox erlaubt. Wenn das Fahrzeug mitspielt, hast du mit einer WARP3 eine der besten (die beste?) PV-Überschussladen-Funktionen, die du kriegen kannst. Spielt das Fahrzeug nicht mit, wirst du auch mit keiner anderen Wallbox bessere Chancen haben, nicht mal mit der VW-eigenen Wallbox. Einige der Skoda/VW-Probleme hat VW inzwischen gelöst. Mir ist aktuell nur ein altes Skoda Enyaq-Modell von 2021 bekannt, das immer noch Probleme hat. Als Workaround kann man tagsüber beim PV-Überschussladen den Min+PV-Modus der WARP3 nutzen; dann schläft nicht mal der problematische Enyaq ein. Plug & Charge benötigt ISO15118, was die WARP3 nicht hat, sondern erst mit WARP4 kommt. Ansonsten ist aktuell noch nicht klar, bei welchen Fahrzeugmodellen Plug & Charge nutzbar ist, egal ob Skoda/VW oder andere. Beispielsweise funktioniert Plug & Charge mit einem Citroën eC3 an ENBW-Schnellladern generell nicht. Unsere Wallbox-Generationen bekommen alle Features immer gleichzeitig. WARP 3 und 4 würden EEBus also gleichzeitig bekommen. Das spielt also bei der Entscheidung zwischen WARP3 und WARP4 keine Rolle. Das funktioniert schon, aber die Einrichtung ist noch nicht benutzerfreundlich. Daran arbeiten wir noch. 😀

Der Wallbox hat keinen Einfluss darauf, wo der Strom herkommt. Wenn du einen Batteriespeicher hast, wird der wohl einspringen und das Auto wird aus der Batterie geladen. Prinzipiell ist das auch sinnvoll, da du ja keinen Strom kaufen möchtest. Wir arbeiten gerade an einer Erweiterung, die es der Wallbox ermöglicht, im „Schnell“-Modus den Batteriespeicher zu blockieren, sofern der Speicher das unterstützt. Das kann sinnvoll sein, wenn man einen dynamischen Stromtarif hat und sich den Speicherinhalt lieber für teurere Stunden aufheben will.

Da eine Wallbox ihre eigene Rotation nicht kennt, wirst du da wohl auf das EVCC-Feature warten müssen. Wenn sich mehrere WARP Charger gegenseitig managen, kann man auch nur auf dem Lastmanager die Rotation aller Wallboxen einstellen.

Was für eine Ausgabe meinst du? Ansonsten ist die Phasenrotation nur relevant, wenn du dynamisches Lastmanagement machst. Das kann EVCC aber meines Wissens nicht. Für PV-Überschussladen ist die Phasenrotation prinzipiell egal. Die Wallboxen durchrotiert anzuschließen ist trotzdem sinnvoll, damit die Zuleitung(en) bei mehreren einphasig ladenden Fahrzeugen gleichmäßiger belastet werden.