MatzeTF

Das sieht nach dem Zähler für die PV-Leistung aus. Der hat dementsprechend nur Einspeisung. Der Zähler für den Batteriespeicher sollte sowohl Einspeisung (Entladen) als auch Bezug (Laden) haben und auch einen Wert für den SOC (Ladestand). Vielleicht verrät @pene8, wie er den Batteriespeicher in der Wallbox konfiguriert hat.

Die Beschreibung der Optionen bei der Energieflussrichtung bezieht sich auf den Leistungswert, der für den Speicher auf der Stromzähler-Unterseite der Wallbox angezeigt wird. Sieh dir einfach den Wert an, wenn am Abend die Sonne weg ist und der Speicher garantiert entladen wird. Ich vermute stark, dass der Wert dann negativ ist und die Energieflussrichtung auf „Normal“ stehen sollte. Falls der Wert beim Entladen doch positiv ist, ist „Invertiert“ richtig.

Zu (1): Und was passiert, wenn du mit mbpoll auch 38 Register ausliest? Versuch das ein paar Mal. Ansonsten scheinen die Timeouts so selten aufzutreten, dass sie eigentlich kein Problem darstellen sollten. Im Min+PV-Modus sollte ein eingestecktes Auto eigentlich sofort anfangen zu laden. Wenn das nächste Mal das Auto angesteckt ist, aber nach 3 Minuten im Min+PV-Modus noch nicht lädt, lade wieder einen Debug Report runter und hänge ihn hier an. Vorher nicht die Modus-Buttons benutzen oder irgendwas anderes ändern, da wir genau den festhängenden Zustand brauchen. Zu (2): 4,424 | ethernet | Connected: 100 Mbps Full Duplex, MAC: 58:BF:25:B8:9E:CF 2024-10-13 09:59:39,000 | rtc | Set system time from RTC at 5,996 2024-10-13 09:59:39,034 | gen_mbtcp_client | Meter configured with hostname 'kostal.home', but no DNS server is configured! 2024-10-13 09:59:39,045 | gen_mbtcp_client | Meter configured with hostname 'kostal.home', but no DNS server is configured! 2024-10-13 09:59:40,942 | ethernet | Got IP address: 192.168.1.25/24 Die Fehlermeldung ist Zugegebenermaßen etwas irreführend. Bei der Wallbox ist DHCP aktiviert und nach dem Aufbau der LAN-Verbindung dauert es ca. 3,5  Sekunden, bis der Router eine IP mit DNS-Server zuweist. In der Zeit hat die Wallbox noch keinen DNS-Server, daher die Fehlermeldung. Warum der Router so lange braucht, weiß ich nicht, aber du kannst das auch einfach ignorieren, da es nach 3,5 Sekunden schließlich funktioniert.

Du kannst mehrere NFC-Karten mit fester ID dranhalten, aber meist weiß man ja nicht, ob eine NFC-Karte eine feste oder wechselnde ID hat. Sicherer ist also, immer nur die Karte für die Wallbox alleine dranzuhalten. Wenn die Netzwerkverbindung im Status „verbinde“ hängenbleibt, heißt das, dass DHCP aktiviert ist und die Wallbox entweder keine Adresse bekommt oder bei bestehender LAN-Verbindung der DHCP-Server nicht erreichbar war, während die Lease-Zeit der DHCP-Adresse abgelaufen ist. Bei statischer Adresskonfiguration sollte der Zustand „verbinde“ eigentlich nicht auftreten können. Bitte lade nächstes mal per integriertem AP einen Debug-Report runter, während die Wallbox gerade im „verbinde“-Zustand hängt.

Hast du zufällig eine deiner NFC-Karten im Portmonee oder einer Smartphonehülle oder bei etwas anderem, das NFC-Funktionalität bietet? Einige NFC-Dinge, insbesondere Persos, einige Kreditkarten und Smartphones rotieren ihre NFC-IDs zufällig. Wenn man so ein Ding zusammen mit einer WARP-NFC-Karte an die Wallbox hält, kann es passieren, dass der NFC-Leser verwirrt wird. Wir arbeiten noch an einer Problemlösung, aber vorerst würde es reichen, die WARP-NFC-Karte nicht zusammen mit einem anderen NFC-Ding an die Wallbox zu halten. Mit „Debug-Report vor einem Neustart runterladen“ meinte ich übrigens auch Neustarts, nicht nur stromlos schalten. Anscheinend hast du die Wallbox 15 Minuten vor dem Debug-Report neugestartet, sodass nichts Hilfreiches mehr drinsteht. Zu deinem Netzwerkproblem: Was meinst du mit „Webserver“? Wenn das Webinterface der Wallbox nicht erreichbar ist, wie kannst du dann die rote Fehleranzeige sehen? Hier würde uns auch ein Debug-Report vom Fehlerzustand helfen. Wenn du die rote Statusanzeige sehen kannst, solltest du auch einen Debug-Report runterladen können.

A1 und A2 kannst du miteinander tauschen und 23 und 24 kannst du miteinander tauschen, aber nicht beide Gruppen miteinander. Tauschen hat aber keinen Vorteil, außer, dass die Drähte vielleicht einfacher zu verlegen sind. A1 und A2 zu tauschen ändert sonst nichts, da das Schütz mit Wechselspannung angesteuert wird, und 23 und 24 tauschen ändert nichts, da das ein simpler Schließer ist, der keine Vorzugsrichtung hat. Wird der Schützfehler sofort nach einem Neustart des WEM angezeigt oder erst nachdem versucht wurde, eine Phasenumschaltung durchzuführen? Kannst du das Schütz schalten hören, wenn eine Phasenumschaltung versucht wird? Ansonsten gibt es beim Verdrahten des Schützes zwei klassische Fehler: 11 und 12 am Hilfskontakt angeschlossen. 23 und 24 sind weiter „hinten“, bzw. die Klemme ganz oben und ganz unten. Eingang 3 am WEM benutzt. Es muss Eingang 4 sein. Wenn es das beides nicht ist, lade bitte einen Debug-Report von der Ereignis-Log-Seite des WEM runter und hänge ihn hier an.

Mach mal ein Debug-Protokoll (nicht den Report), in dem der Zeitpunkt mit der fehlenden Abschaltung enthalten ist. Wir hatten die gleichen Symptome hier schon mal aufgrund falscher Kalibrierung.

Ja, das ist alles richtig. Der Hilfskontakt wird am Schütz eingehakt und für die Schützüberwachung verwendet. Damit kann der WEM erkennen, ob das Schütz korrekt angezogen hat oder nicht. (Ich bin übrigens nicht Thomas.)

Wie rtrbt schon schrieb, ist das aktuell leider nicht machbar. Das betrifft auch die WARP3 Pro, die exakt die gleiche LAN- und WLAN-Funktionalität bietet, wie der ESP32 Ethernet Brick. Falls das in Zukunft mal machbar wird, werden wir versuchen, das umzusetzen, da das Feature schon mehrfach gewünscht wurde.

Es gab noch ein Problem bei der Unterstützung von Batteriespeichern, die per Modbus TCP ausgelesen werden. Mit den neuen Firmware-Dateien aus dem ersten Post sollte das jetzt auch funktionieren.

Wird auf der Zählerseite in der Tabelle (nicht aufgeklappt) ein Leistungswert für den Zähler angezeigt und gibt es für ihn eine Kurve in der Grafik? Der Batteriespeicher verwendet den selben Wert und sollte funktionieren, wenn Wert und Kurve angezeigt werden. Poste mal einen Debug-Report, damit ich sehen kann, was für Werte der Zähler vom Speicher tatsächlich hat.

Gute Nachrichten für alle mit Batteriespeicher: In dieser Beta-Firmware ist eine Unterstützung für Batteriespeicher enthalten, mit der zwei der am häufigsten gemeldeten Probleme der Vergangenheit angehören sollten: Wenn morgens genug PV-Leistung zur Verfügung steht, fängt keine Ladung an, sondern es wird erst der Batteriespeicher vollgeladen. Wenn abends die PV-Leistung nicht mehr ausreicht, wird weiter das Auto geladen und dafür die Batterie geleert. Neu in dieser Version ist: Es kann ausgewählt werden, ob der Speicher oder das Auto bevorzugt geladen werden soll. Abends wird bei nicht ausreichender Leistung abgeschaltet, statt den Batteriespeicher zu leeren. Soll abends trotzdem weiter geladen werden, muss man auf den Schnell-Modus oder Min + PV wechseln. Abgeschaltet wird wie üblich erst nach ein paar Minuten nicht ausreichender PV-Leistung, die mit der Batterie überbrückt werden. Das Ganze funktioniert mit allen Batteriespeichern, die von der Wallbox ausgelesen werden können, sowie über die üblichen HTTP- und MQTT-APIs. Auch wenn die aktuelle Wetterlage leider nicht mehr viel PV-Leistung hergibt, freue ich mich auf reges Feedback zu dieser Testversion, sowohl hinsichtlich der reinen Funktionalität, als auch zur Verständlichkeit der Einstellungsmöglichkeiten, die ihr bei den anderen Einstellungen zum PV-Überschussladen findet. 04.10.2024 Update: Unterstützung für Batteriespeicher per Modbus TCP repariert. Edit: Angehängte Firmwares gelöscht. Diese Funktion ist schon Teil der offiziellen Firmware.

Die Wallbox gibt 16 A frei und das Auto muss die Freigabe auch sehen, da es sonst nicht anfangen würde zu laden. Trotzdem lädt es nicht mit mehr als 5 A pro Phase. Aktuell sieht es so aus, als würde sich die Wallbox korrekt verhalten und das Problem wäre eher auf Autoseite zu suchen. Bei VW ist die Ursache oft der von rtrbt bereits erwähnte Notlademodus, der z. B. hier diskutiert wird. Versuche, alle dort genannten möglichen Ursachen auszuschließen. (Ich bin übrigens nicht der Matze77 dort.) Ansonsten wäre der nächste Test, dein Auto an einer anderen Wallbox zu laden und ein anderes Auto an deiner Wallbox, sofern du das irgendwie hinbekommen kannst.

Kannst du mal einen Debug-Report runterladen (von der Ereignis-Log-Unterseite), während das Problem besteht, also das Auto angeschlossen ist und weniger zieht als erlaubt? Anschließend bitte hier anhängen.

Ich glaube, bei "topic" muss das ganze Topic aus den MQTT-Einstellungen der Wallbox hin, also sowas wie "topic: warp3/2ab3"

Poste mal den Eintrag der Wallbox in der EVCC-Konfigurationsdatei.

Ist die WARP3-Firmware auf dem neuesten Stand? Wenn ich mich recht erinnere, muss man für die WARP3 in EVCC noch einen Eintrag in der Konfigurationsdatei hinzufügen, damit sie Phasenumschaltung kann. Hast du dazu was beachtet?

Kurz zur Zoe-Sonderoption: Diese Option setzt an einer ganz anderen Stelle an und sorgt nur dafür, dass bei dreiphasigem Laden ein Ladestrom von 9,2 A nicht unterschritten wird, da Zoe & Co. bei dreiphasigem Laden nicht mit kleineren Ladeströmen zurechtkommen. Das ist ist also nicht mehr als einfach eine Begrenzung für einen Zahlenwert.

Das Abfrageintervall der WARP ist eine Sekunde. Das längstmögliche Update-Intervall ist zwei Sekunden. Wenn du deinen Huawei maximal alle 30 Sekunden abfragen kannst, ist der als Datenquelle für die Warp nicht geeignet. Solltest du versuchen, irgendwie 30 Sekunden lang den gleichen alten Wert als neu vorzutäuschen, wird das auch nicht funktionieren. Du kannst versuchen, deinen Modbus Proxy zum Laufen zu bringen, aber wenn der auch nichts anderes macht, als 30 Sekunden lang den selben Wert auszuliefern, kannst du dir die Mühe auch sparen. In welcher Konstellation bekommst du alle zwei Sekunden Fehler? Ist das beim direkten Zugriff auf den Huawei? Da die Daten im Sekundentakt angefragt werden, würde das bedeuten, dass die Werte alle zwei Sekunden geliefert werden und dazwischen immer ein Fehler liegt. Wenn du dir die Huawei-Linie im Graphen mit den Leistungsdaten ansiehst, ist sie größtenteils durchgängig mit vielleicht gelegentlichen kleinen Unterbrechungen oder hast du viele oder gar große Lücken?

Hast du die PT100 testweise mal direkt an den Bricklets angeschlossen? Werden sie da erkannt? Ansonsten sollten bei vieradriger Beschaltung 30 m Kabellänge kein Problem sein. Falls du Probleme mit der Kabellänge hast, hätte ich noch diese beiden Alternativvorschläge für dich: Wenn die PTC Bricklets an einem Master Brick angeschlossen sind, kannst du die RS485 Master Extension nutzen. Du schließt einen Master mit Extension an deinen PC an und die PTC Bricklets schließt du an einen weiteren Master mit Extension an und platzierst den Stapel dann nah an den PTCs. Wenn die PTCs weit auseinander liegen, kannst du auch mehrere Master mit Extension verteilen. Zwischen den Extensions kannst du dann einen RS485-Bus legen und alle PTC Bricklets so benutzen, als wären sie direkt an deinen PC angeschlossen. Alternativ kannst du die PTC Bricklets auch an einen ESP32 (Ethernet) Brick anschließen und den bei den PTCs platzieren. Von deinem PC aus verbindest du dich dann nicht mit dem lokalen Brick Daemon, sondern mit dem ESP32 Brick. Dafür muss bei den PTCs aber eine Netzwerkverbindung möglich sein, entweder LAN oder WLAN.

Ein nachträglicher Debug-Report hilft uns leider nicht. Der Report muss in dem Moment, in dem der Fehlerzustand besteht, runtergeladen werden, damit die entsprechenden Zustandsinformationen drin sind. Nächstes Mal bitte als Dateianhang anhängen und nicht komplett reinkopieren. Das ist so sehr unübersichtlich.

Das hört sich erstmal unerwartet an, da die selbe Logik Updates ans Webinterface und über MQTT schickt. Um das genauer einzugrenzen, brauchen wir einen Debug-Report vom Fehlerfall. Wenn das Problem wieder auftritt, also das Webinterface verbunden meldet, MQTT aber nicht, bitte einen Debug-Report von der Ereignisprotokollseite runterladen und hier anhängen. Möglichst auch zusätzlich die aktuellen MQTT-Daten, in denen zu sehen ist, dass MQTT „nicht verbunden“ meldet.

Die Bohrschablone mit eingezeichneten Befestigungslöchern und Zuleitungen findest du hier. Die Zuleitung ist von unten oder von hinten möglich. Bei Zuleitung von hinten werden die unten eingezeichneten Kabeldurchführungen rausgeschraubt und stattdessen von hinten eingeschraubt. Die Löcher hinten haben im Auslieferungszustand Blindstopfen, die dann stattdessen unten reinkommen.

Das siehst du genau richtig. Im Moment sind das deine Optionen. Der Energy Manager bekommt aber in hoffentlich nicht allzu ferner Zukunft ein Update, mit dem er von außen gesteuert die Phasenumschaltung für eine Wallbox durchführen kann. Du könntest dann einen zweiten Energy Manager für die Phasenumschaltung in die Unterverteilung der Wallbox setzen und die Steuerung übernimmt dein bereits vorhandener Energy Manager. Das ist wahrscheinlich die einfachste Lösung, wenn auch nicht die günstigste. Eine günstigere Variante wäre den SDM-Stromzähler durch einen Stromzähler mit Netzwerkanschluss zu ersetzen, wie z. B. einen Shelly Pro 3EM, und den Energy Manager in die Unterverteilung der Wallbox zu versetzen und per Netzwerk mit dem Stromzähler zu verbinden.

Wenn wir in Zukunft OCPP 2.0 unterstützen, wird das wahrscheinlich auch für die älteren Wallboxen nachgelegt (kann ich aber nicht versprechen), aber anscheinend hast du für OCPP 2.0 selbst ja gar keinen konkreten Anwendungsfall. ISO15118 unterstützen die WARP Charger aktuell noch nicht und für bestehende Wallboxen kann das auch nicht per Softwareupdate nachgelegt werden, da dafür zusätzliche Hardware nötig ist. Die zusätzliche Hardware ist auch der Grund, warum wir das noch nicht anbieten, da sie aktuell nur für einen unrealistisch hohen Preis zu haben ist. Wir sind aber auch sehr an dem Thema interessiert und wollen ISO15118 integrieren, sobald wir eine Möglichkeit finden, das für einen akzeptablen Preis zu machen.