MatzeTF

Die gute Nachricht ist, dass die Abschaltung funktioniert, wie sie soll. Man sieht sowohl im nicht gekürzten Trace-Log als auch im Debug-Report, dass die zur Verfügung stehende Leistung vor dem Abschalten immer weniger wurde. Zwischenzeitlich war sie schon mal kurz auf Minimum, hat sich dann aber noch etwas erholt, bis sie dann zu lange unter dem Minimum lag und abgeschaltet wurde. Die Frage ist eher, wieso das bei überhaupt funktioniert, da du den Batteriespeicher falsch eingerichtet hast: nämlich gar nicht. Du hast das Fronius Smart Meter am Netzanschluss als Zähler eingetragen und verwendest das sowohl für den Netzbezug, als auch für die Speicherleistung, was nicht richtig ist. Der Stromzähler für den Batteriespeicher muss die Lade- und Entladeleistung der Batterie messen können. Da kann man nicht einfach stattdessen den Netzbezug reinstecken. Wenn ich das richtig sehe, führt die falsche Zählereinstellung bei dir dazu, dass immer der doppelte Netzbezug gemessen wird. Eigentlich wird die Leistung des Batteriespeichers vom Netzbezug abgezogen, aber da du den Batteriespeicher auf „Invertiert“ gestellt hast, wird „Netz - (-Batterie)“ gerechnet. Durch den doppelt so großen Wert wird jetzt einfach das Ausschaltkriterium sicher erreicht, was vorher nur mit dem Netzbezugszähler nicht funktioniert hat. Auch wenn jetzt abgeschaltet wird, hast du jetzt weder gutes PV-Überschussladen, noch eine korrekte Speicherunterstützung. Die Frage wäre, ob man an die Batterieleistung deines Speichers drankommt, um sie korrekt zu verarbeiten. Kannst du mal einen SunSpec-Scan gegen deinen Wechselrichter laufen lassen und das Log hier anhängen? Wahrscheinlich ist es dafür am besten, den WR aus der Zählerliste zu löschen, dann einmal neustarten und erst dann den Scan laufen lassen. Teilweise stehen sich der Scan und die Abfragen von einem bereits laufenden Zähler gegenseitig auf den Füßen.

Ja, sieht so aus. 👍 Kannst du mal einen Debug-Report posten? Damit meine ich nicht das Trace-Log, sondern das Ding, das man unter dem Menüpunkt „Ereignis-Log“ runterladen kann. Ich würde gerne deine Einstellungen für den Batteriespeicher auf der Stromzähler-Unterseite sehen und in einem Trace-Log sind keine Einstellungen drin.

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.