photron

Nach meiner Lessart steht da bloss, dass alle Komponenten, die einen Einfluss auf das Stromnetz haben können zertifiziert sein müssen. Beim AC Fall also Wallbox und Auto. So weit, so erwartet. Übrigens ist das Dokument aus September 2023. Da hat sich vermutlich in der Zwischenzeit auch einiges getan.

Zeig doch bitte trotzdem mal einen Debug-Report, da steht ja noch mehr drin als nur das Log.

Dss stimmt so nicht. Du verwechselt den virtuellen Zähler mit dem Messort. Die Situation ist typsicherweise so, dass technisch der Wechselrichter die Modbus/TCP- bzw. SunSpec-Kommunikation bereitstellt. Darüber stehen dann alle Daten bereit. Wir brauchen aber, dass die Daten thematisch gruppiert sind. Dazu dienen die virtuellen Zähler. Damit wählst du aus welche der Daten ausgelesen werden. Der Messort legt dann fest was die Daten eigentlich bedeuten, dass wird z.B. beim Energie Manager für die thematisch Zusammenfassung der Messwerte auf der Statusseite verwendet. Damit schränken wir auch ein welche Zähler z.B. als Zähler für den Netzanschluss-Zähler beim PV-Überschussladen ausgewählt werden können. Es macht keinen Sinn, dass du da z.B. den Battiere-Zähler als Netzanschluss-Zähler auswählen könntest. Bis zum letzten Firmware-Release war es möglich den Messort umzustellen, auch wenn der Messort eigentlich fest definiert war, bedingt durch den virtuellen Zähler. Das war aber völlig überflüssig und hat Kunden verwirrt wie jetzt auch N1L5. Daher ist ab der aktuellen Version der Messort fix und nur noch umstellbar, wenn der nicht von vorneherein eh schon feststeht. Wenn man einen Shelly, oder sonstigen generischen Zähler einrichtet, dann musste man schon immer den Messort festlegen, weil wir es dort nicht wissen können. Bezüglich SolarEdge und SunSpec vs. Modbus/TCP: SolarEdge implementiert leider SunSpec nicht vollständig, fast kein Hersteller tut das. Daher ist das bei SolarEdge gemischt. Der Netzanschluss-Zähler muss über SunSpec mit dem Modell 203 ausgelesen werden. Die PV-Leistung (für die Schönheit der Sache, für die Regelung wird sie nicht benötigt) liefern nur die großen SolarEdge-Wechselrichter mit Synergie über SunSpec Modell 160 aus. Für die kleinen SolarEdge-Wechselrichter ohne Synergie muss man dazu den entsprechenden Modbus/TCP Zähler einrichten. Die Batteriedaten liefert SolarEdge nie über SunSpec, sondern nur direkt über Modbus/TCP. Das ist also bei SolarEdge leider eine Mischung. SolarEdge misst typischerweise den Netzbezug, wie das sehr viele Wechselrichter tun, weil sie entweder ihre Battiere so regeln wollen, dass am Netzanschluss 0W entstehen, oder ihre Leistung so regeln müssen, dass am Netzanschluss nur ein gewisser Teil der maximal Leistung eingespeist wird. Da gibt es keine Probleme mit SunSpec, das funktioniert. Es ist nur so das SolarEdge weder alles über SunSpec noch alles über Modbus/TCP ausgelesen werden kann, sondern man eine Mischung aus beidem konfigurieren muss. Das ist leider aktuell etwas kompliziert, das alles richtig zu konfigurieren. Wir haben Pläne das längerfristig zu verbessern.

Das Bug-Fix Release kommt in den nächsten paar Tagen. Das nächste Feature-Release ist noch nicht festgelegt.

Die Verbindung besteht durchgängig, aber der Wechselrichter antwortet teilweise nicht schnell genug auf die Anfragen. Dadurch entstehen die Lücken. Hast du noch etwas anderes laufen, das den Wechselrichter abfragt?

Der WARP Charger kann grundsätzlich Batteriespeicher steueren, so dass du dazu EVCC nicht zwingend brauchst, sondern die Wallbox das selber kann. Aktuell fehlt allerdings noch der spezifische Support für SolarEdge, der kommt aber in Kürze.

Das stimmt nicht mehr. Die aktuelle Firmware unterstüzt jetzt Solis.

Das ist kein bekanntes Problem. Ladt bitte unter System > Ereignis-Log einen Debug-Report herunter und häng ihn hier an.

Das gibt es leider noch nicht, kommt aber in Kürze.

Gut zu Wissen, aber eine so schnelle Reaktionszeit ist nicht wirklich notwendig. Ich bleibe erstmal bei den 20 Sekunden und dokumentiere, dass der Timeout nicht unter 30 Sekunden konfiguriert sein darf. Für den G3 ist damit die Batteriesteuerung soweit erstmal fertig. Für den G2 will ich noch einbauen, dass beim Verlassen eines Erzwingen-Modus der Watchdog abläuft, damit der Setpoint zurückgesetzt wird.

Growatt Support ist jetzt in der aktuellen Firmware enthalten.

Ich hatte bisher nur aus Screenshots gefunden, dass niemand den "Timeout ext. Batteriesteuerung" kleiner als 60 stehen hatte. Und da das 1288 Register mit 30 bis 10800 Sekunden dokumentiert ist habe ich mal 20 Sekunden genommen. Den "Timeout ext. Batteriesteuerung" auf eine Sekunden stellen zu können halte ich für nicht sinnvoll, dann muss man ja wirklich mit unter einer Sekunden Wiederholrate schreiben. Hast du mal probiert, ob du den "Timeout ext. Batteriesteuerung" wirklich auf eine Sekunde stellen kannst und dann auch die Werte wirklich nach einer Sekunde zurückgesetzt werden. Ich vermute fast das die wirkliche untere Grenze nicht 1 ist. Ich würde nicht unter einer Sekunde Wiederholzeit arbeiten wollen. Die untere Grenze wären eher so 5 bis 10 Sekunden.

Anbei die WEM2 Firmware. Aktuell muss beim Einrichten der Batteriesteuerung noch ausgewählt werden, oder der Kostal Wechsleichter im Big- oder Little-Endian Modus läuft. Ich habe aber gerade gesehen, dass in Register 5 steht welche Endianess aktiv ist. Daher wird diese Auswahl noch wegfallen und ich werde das automatisch ermitteln. energy_manager_v2_firmware_1_4_0_69e7ad53_3848db61ba8366d_feature-kostal-battery-control_merged.bin

Hier eine Test-Firmware für Kostal Plenticore Plus G2 und Plenticore G3. Bedingt dadurch wie bei Kostal das automatische Register-Zurücksetzen funktioniert sind bestimmte Modus-Wechsel verzögert, um die Dauer der automatischen Register-Zurücksetzzeit. Wenn möglich sollte diese Zeit also auf das Minimum von 30 Sekunden konfiguriert werden. Beim G3 ist jedes Beenden eines erzwugenen Ladens/Entladens verzögert. Beim G2 ist jeder Beginn des Normal-Modus verzögert. Beim G3 nur dann, wenn vorher das Laden/Entladen erzwungen wurde. Beim G2 kann aktuell das Laden nicht unabhängig vom Entladen blockiert werden. Es wird immer beides zusammen blockiert. Das hängt aber damit zusammen wie aktuell unsere Batteriesteuerung funktioniert. Das wird noch verbessert werden. warp3_firmware_2_9_0_69e7a6eb_3848db61ba8366d_feature-kostal-battery-control_merged.bin

@laubblaeser Was passiert, wenn du den Setpoint über Register 1034 auf 0W setzt, wenn das Auto schnelllädt? Dann ist zwar auch das Laden blockiert, aber dann sollte der Speicher sich ja auch nicht mehr mit 0,5A entladen können.

@laubblaeser Manuelle Modus-Überstimmung ist angedacht, es gibt aber noch keinen Fertigstellungstermin dafür. @CptHildi Änderungen werden erst nach Neustart übernommen. In der nächsten Firmware-Version werden viele Einstellungen auch ohne Neustart übernommen werden. Die Batteriesteuerung ist aber noch nicht dabei. Kommt aber in Kürze. Bezüglich, dass die Änderungen auch nach Neustart nicht wirken: Kann es sein, dass du die Batteriesteuerung gar nicht aktiviert hast, sondern bisher nur über den Testmodus Befehle an den Speicher geschickt hast? Siehe den "Bat­te­rie­steu­e­rung aktiviert" Schalter. Falls es das auch nicht ist, dann zeig bitte mal einen Debug-Report vor.

Bindings: C# 2.1.34 Add IPv6 support Add support NFC forum tag type 5 and phone with HCE (host card emulation) as tag type to NFC Bricklet API Add CardemuSet/GetTagID function to NFC Bricklet API Add WriteLine2 function to OLED 128x64 Bricklet 2.0 API Add Set/GetMotorStalledCallbackConfiguration functions and MotorStalled callback to Silent Stepper Bricklet 2.0 API Add Set/GetCaptureInputCallbackConfiguration functions and CaptureInput callback to IO-4 Bricklet 2.0 API Download: C#

Bindings: C# 2.1.34 Unterstützung für IPv6 hinzugefügt Unterstützung für NFC Forum Tag Type 5 und Phone mit HCE (Host Card Emulation) zur NFC Bricklet API hinzugefügt CardemuSet/GetTagID Funktion zur NFC Bricklet API hinzugefügt WriteLine2 Funktion zur OLED 128x64 Bricklet 2.0 API hinzugefügt Set/GetMotorStalledCallbackConfiguration Funktionen und MotorStalled Callback zur Silent Stepper Bricklet 2.0 API hinzugefügt Set/GetCaptureInputCallbackConfiguration Funktionen und CaptureInput Callback zur IO-4 Bricklet 2.0 API hinzugefügt Download: C#

Du musst das nicht händisch eintragen. Ich habe die Anbindung hier schon fast fertig liegen. Siehe Detail in der PM.

@KNX Ich denke du hast deine Zähler nicht richtig konfiguriert. Ich sehe im Debug Report folgende Struktur: Wallbox: Carlo Gavazzi EM24 E1 mit Messort Netzanschluss. Hast du eine WARP3 Smart und extern einen Carlo Gavazzi EM24 E1 davorgesetzt, um daraus eine WARP3 Pro zu machen? Hier solltest du den Messort von Netzanschluss auf Last ändern. Eigentlich sollte der Messort Wallbox sein, aber den gibt es aktuell noch nicht. Netz: Victron Energy GX mit virtuellem Zähler Netzanschluss am Messort Netzanschluss. So weit so gut, aber du hast den ESS Zähler im PV-Überschussladen als Stromzähler gewählt. Hier muss du stattdessen den Netz Zähler wählen, denn das PV-Überschussladen muss wissen was am Netzanschluss passiert, nicht was deine PV-Anlagen gerade produziert. ESS: Carlo Gavazzi EM24 E1 mit Messort Speicher. An sich okay, aber ein externer Zähler am Speicher liefert den SoC nicht. Besser wäre, wenn du stattdessen den Speicher auch über Victron Energy GX mit virtuellem Zähler Speicher anbinden würdest, dann wäre auch der SoC verfügbar. Diesen Zähler mit SoC kannst du dann auch für das PV-Überschussladen als Batteriezähler wählen. Huawei: Huawei Smart Logger 3000 mit virtuellem Zähler PV am Messort PV. Das hier ist die PV-Leistung deiner Huawei-Anlage. Diesen Zähler kannst du zu Recht im PV-Überschussladen nicht auswählen, weil die reine PV-Leistung nicht interessant ist, sondern nur das was davon am Netzanschluss übrig ist und das wird am Netzanschluss gemessen.

Wir haben das hinter den Kullissen debuggt. Das wirkliche Problem scheint zu sein, dass der SolarEdge Wechselrichter bis zu 30 Sekunden nach einem Neustart braucht, bis dieser die Informationen über den angeschlossenen Zähler wieder korrekt initialisiert hat. In den ersten 30 Sekunden liefert der Wechselrichter fehlerhaft bzw. unvollständige Informationen über den Zähler. Dadurch kann die Wallbox den Zähler zuerst nicht korrekt finden. Diese Problem behebt sich aber von selbst nach 30 Sekunden.

Um welche Huawei-Anlage geht es genau? Alle Huawei-Zähler, die wir unterstützen, liefern die gerichtetet Wirkleistung. Kannst du mir einen Debug Report (im Webinterface der Wallbox unter System > Ereignis-Log abspeichern) zeigen, bei dem der betroffene Zähler in der Wallbox eingerichtet ist?

Teste mal bitte die angehängt Firmware. Siehst du damit noch die "Configured SunSpec model 203/0 not found at 192.168.1.12:502:1" Meldungen nach einem Reconnect? warp3_firmware_2_9_0_69b9334d_5772f5ed618f546_feature-sun-spec-fixes-MERGED_merged.bin

Der Registersatz lässt mich glauben, dass wir die Werte des Marstek CT002 am Netzanschluss über den Batteriespeicher auslesen können. Es sollte also ohne extra Zähler und ohne das wir direkt den Marstek CT002 auslesen gehen. Wir brauchen nur eine Modbus/TCP Verbindung zum Batteriespeicher selbst für das PV-Überschussladen.

Der Marstek CT002 Zähler ist für uns nicht drekt interesant. Wir müssen wenn dann mit dem Marstek Venus 3.0 direkt reden. Spricht der SolarEdge Wechselrichter mit dem Batteriespeicher, oder arbeiten die beide unabhängig von einander? Falls der Wechselrichter mit dem Batteriespeicher spricht, dann sollte das schon alles funktionieren, weil wir schon mit einem Batteriespeicher am SolarEdge Wechselrichter reden können. Falls die beiden unabhängig von einander arbeiten, dann müssten wir Support für Marstek hinzufügen. Die Register-Dokumentation habe ich schon gefunden, denke ich. Marstek und Duravolt scheinen baugleich zu sein. Ich schlage folgendes Vorgehen vor: Du gibst uns vorübergehen Fernzugriff auf die Wallbox im Ferienhaus, und ich kann dann die Unterstüzung implementieren und auf deiner Anlage testen. Der Marstek Venus 3.0 scheint direkt einen LAN Anschluss zu haben. Ich hoffe darüber läuft dann auch direkt Modbus/TCP und es ist nicht noch ein extra Modbus/RTU-nach-Modbus/TCP-Wandler notwendig, wie das leider oft bei anderen Herstellern der Fall ist.