MatzeTF

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.

Wenn du den Betreff nicht selbst editieren darfst, kann ich das machen. Allerdings ist das in unserem Forum unüblich.

Die 0 steht für 10^0, also ein Skalierfaktor von 1. Das passt zum falschen Wert. Ich hoffe, du hast Verständnis dafür, dass wir nicht allen Bugs anderer Hersteller hinterherlaufen können, insbesondere wenn es sich um ein eher kosmetisches Problem handelt. Wir haben aktuell eine Anfrage bei einem anderen Hersteller am laufen, dessen SunSpec-Daten noch viel schlimmer verbuggt sind, und das entwickelt sich zum reinsten Zeitgrab. Da du selbst das KOSTAL-Gerät im Einsatz hast, kannst du dich an KOSTAL wenden und ihnen deine Erkenntnisse von den selbst ausgelesenen Registern mitteilen, damit sie nicht versuchen, die Schuld auf uns abzuwälzen. Hast du ansonsten schon mal nach einem Firmware-Update für den KOSTAL-Zähler geschaut? Ich glaube es zwar nicht, aber vielleicht ist das Problem schon repariert?

Die Software von WARP 1 bis 3 unterscheidet sich fast nur aufgrund der verbauten Hardware. Wenn man nur die reine Software-Funktionalität betrachtet, fallen mir gerade diese beiden Unterschiede ein: WARP 2/3 unterstützen OCPP, WARP 1 nicht. Vielleicht kommt das irgendwann noch, vielleicht auch nicht. WARP 2/3 unterstützen 32 Benutzer, 32 NFC-Tags und 32 Wallboxen im Lastmanagement, die WARP 1 jeweils nur 10. Das Problem ist in beiden Fällen, wie mattsches schon sagte, der viel kleinere Arbeitsspeicher der WARP 1. OCPP könnten wir inzwischen vielleicht noch reinbekommen, aber wahrscheinlich wartet da niemand drauf, weil es bisher bei allen WARP 1 Nutzern auch ohne ging. @mattsches Tut mir Leid, dass du unter unseren häufigen Umbauten leidest. Die API nach außen ist uns fast schon heilig, aber intern reißen wir öfter was um, wenn sich herausstellt, dass wieder irgendwas aktualisiert oder aufgeräumt werden muss. Wahrscheinlich fällt dir insbesondere der leider notwendige Preact-Umbau im Frontend auf die Füße. Mit dem angehängten Patch compiliert zumindest das Phase Switcher Backend-Modul wieder. Ob es auch funktioniert, weiß ich natürlich nicht. 😉 Die notwendigen Änderungen im Frontend habe ich leider nicht im Kopf, um das gerade für dich zu machen. Edit: Veralteten Patch entfernt.

Ich weiß nicht, wie das SMA-System funktioniert, aber man wird auf irgendeine Weise damit kommunizieren müssen, wozu eine SMA-spezifische Lösung notwendig ist. Mit einem herstellerübergreifenden Standard wäre das einfacher, aber aktuell haben wir leider keine Sonderlösungen für verschiedene herstellerspezifische Systeme. Das mit den Wandlerverlusten habe ich schon öfters gehört, kann es aber nicht recht nachvollziehen. Wenn ich 10 kWh in mein Auto lade und 5 % Wandlerverluste habe, verliere ich 0,5 kWh. Beziehe ich den Strom dafür aus einem Batteriespeicher, der auch 5 % Wandlerverluste habe, verliere ich insgesamt 1 kWh. Dann ist vielleicht die Batterie leer und mein Haus bezieht in der Nacht Strom aus dem Netz ohne Wandlerverluste. Lade ich stattdessen das Auto aus dem Netz, habe ich dort nur 0,5 kWh Verlust. Allerdings bezieht mein Haus dann in der Nacht 10 kWh aus der Batterie und dabei entstehen 0,5 kWh Verlust, also unterm Strich auch insgesamt 1 kWh, nur zu anderen Zeiten. Ich sehe da keinen Unterschied. Vielmehr sehe ich den Nachteil, dass mein Haus den Speicher vielleicht gar nicht komplett leert und ich Strom fürs Auto gekauft habe und dafür einen Teil der Energie ungenutzt im Speicher gelassen habe, der dann am nächsten Tag nicht mal mit voller Kapazität geladen werden kann. Die Batteriezyklen schont es wahrscheinlich schon, aber noch mehr schont es die Batteriezyklen, wenn man die Batterie nie verwendet. Allerdings ist sie dann auch nutzlos. 😉 Die Batterie amortisiert sich ja nur, wenn man sie tatsächlich nutzt. Da ich auch keinen dynamischen Stromtarif habe, nehme ich daher nie Rücksicht auf die Batterie und lade bei Bedarf das Auto damit. Dann ist sie am nächsten Morgen auch schön leer, damit wieder viel PV-Energie reinpasst. Wenn ich mein Auto mittags bei schlechtem Wetter laden muss, kann am Nachmittag die Batterie sogar ein zweites Mal am Tag geladen werden und der Speicher hat mir dann sogar doppelt geholfen. Mit einem dynamischen Stromtarif sieht das natürlich anders aus. Da ist es sinnvoller, das Auto möglichst mit billigem Netzstrom zu laden und das Haus in Zeiten mit teurem Netzstrom aus der Batterie zu versorgen.

Nein, die WARP3 kann aktuell keine Batteriespeicher ansteuern. Leider gibt es auch keinen Standard bzw. irgendeine herstellerunabhängige Lösung dafür, sodass diese Funktion auch nicht ganz einfach wäre. Hast du eigentlich einen Stromtarif mit dynamischen Preisen? Falls nicht, ist es im Allgemeinen sinnvoller, das Auto aus dem Batteriespeicher zu laden statt Netzstrom zu kaufen.

Wenn du die Position von einem neueren Arduino berechnen lassen und an ein Bricklet weitergeben lassen möchtest, empfehle ich dir das RS232 Bricklet 2.0, damit du die Daten digital übertragen kannst. Bei einem 3,3 V Arduino kannst du die Pins direkt verbinden, bei einem 5 V Arduino brauchst du einen Widerstand. Das klappt allerdings nicht mit alten Arduinos, die nur eine serielle Schnittstelle haben, die fest mit dem USB-Port verbunden ist.

Wir haben hier ein KOSTAL Smart Energy Meter im Einsatz. Das verwendet auch das SunSpec Model 203 und zeigt Energiebezug und -einspeisung korrekt an, dementsprechend ist is kein Problem auf Wallboxseite. Bei KOSTAL haben nicht nur wir sondern auch andere Anbieter festgestellt, dass sie es mit der SunSpec-Spezifikation nicht so genau nehmen. Beispielsweise sind alle Energiewerte, die laut Spezifikation vorzeichenlos sein sollten, bei allen KOSTAL-Geräten vorzeichenbehaftet. Es würde mich nicht wundern, wenn die Energiewerte, die laut Spezifikation in Wattstunden angegeben werden sollen, beim PLENTICORE einfach mal als Kilowattstunden ausgegeben werden und somit um den Faktor 1000 zu klein sind. Wenn du weißt, wie du bei deinem Router eine Portweiterleitung für den Modbus-Port deines Wechselrichters anlegst, kannst du das mal machen und mir vormittags deine IP des Tages™ per privater Nachricht schicken. Dann kann ich mir mal die Rohwerte deines Wechselrichters ansehen. Ich vermute ganz stark, dass die einfach falsch sind.