Ich versuche immer noch (verzweifelt) meine Solaredge-Batterie im UI darstellen zu können. Ich habe mir jetzt mal den Code einer Fenecon Home-Battery angeschaut, diesen kopiert und mit meinen relevanten Modbus-Adressen versehen. Daten wie SOC, Strom und Spannung kommen in der Instanz battery0 an.
Wenn ich das recht verstehe, muss für die Darstellung im UI noch ein Speichersystem erstellt werde welches mit der Batterie verknüpft wird, richtig? Wenn ja, welches? Mit dem generischen kam ich nicht klar. Es verlangt nach einem Batterie-Inverter.
Für einen Denkanstoß wäre ich wirklich dankbar.
Gruß
Klinki
ich gehe davon aus, dass du einen Solaredge Batteriewechselrichter mit einer (z. B. BYD)-Batterie hast, oder? Da du in der Konstellation nur mit dem Solaredge kommunizierst, wäre die bessere Vorlage z. B. ein FENECON Pro 9-12 in OpenEMS.
Wenn es erstmal nur lesend sein soll, brauchst du lediglich das SymmetricEss Interface implementieren und die entsprechenden Channel für Leistung, SoC, etc. zu füllen. Das sollte eigentlich recht schnell gehen.
Wenn es ein Hybrid-Wechselrichter ist, ist evtl. noch das HybridEss-Interface interessant (siehe z. B. beim KACO Blueplanet Hybrid 10)
Die Architektur für einen FENECON Home oder auch Commerical- und Industrial-Systeme ist komplexer, weil dort OpenEMS direkt und separat mit den Batteriewechselrichtern und den Batterien spricht. Dann braucht es einen Generic-ESS, der diese BatteryInverter und Battery zusammenbringt.
Richtig, ein Solaredge-WR mit einer Solaredge Home Battery.
Ich bin zunächst Deinem Rat gefolgt und habe versucht ein SymmetricEss zu implementieren. Ich habe das orginäre kopiert und alle doppelten Methoden und Channels vom SymmetricMeter rausgeworfen. Im Debug-Log sehe ich nun die Channels zu SOC und Capacity, usw.
Nur die Berechnung zu den aktuellen Wh zu Charge und Discharge funktionieren nicht. Brauche ich diese überhaupt? Der WR liefert mir nur folgende (Momentan-)Daten zur Batterie: Strom, Spannung, Leistung.
Sehe ich das richtig und für die Anzeige der Batterie benötige ich “nur” die Channels für Charge/Discharge-Energy, SOC und Capacity?
ich habe einen separaten Branch und Pull-Request dafür erstellt:
Du hast eine Einladung zum Schreibzugriff auf das Repository. Dann können wir gemeinsam daran arbeiten. Wenn du was entwickelst, ‘pushe’ es gerne einfach auf den Branch.
Die Implementierung umfasst einen AbstractSunSpecEss und die Referenz-Implementierung für SolarEdge
Via SunSpec funktioniert das ganze Auslesen der Modbus-Adressen und Scalefactors in OpenEMS automatisch
Von welchen SunSpec Blöcken welche Informationen genau kommen müssen ist mir aber für ein Speichersystem noch nicht ganz klar. Auch die von dir gefunden Modbus-Register-Adressen konnte ich nicht genau nachvollziehen.
Die Register habe ich von Solaredge. Das PDF war gar nicht so einfach zu beschaffen und folgt leider auch auch nicht vollständig den Sunspec-Vorgaben. Ich habe es mal angehangen…
Bisher nur Model S1 und S103 sinnvoll.
Da Solaredge offentsichtlich nicht dem SunSpec-Protokoll folgt, müsste ich die Register für die Batterie wohl “von Hand” auslesen und auf die Channels mappen.
Ok stimmt. Die Batteriedaten laufen leider nicht über SunSpec, sondern in einem proprietären Bereich. Schade. Du kannst trotzdem auf meiner Implementierung aufbauen. Ich habe dazu nochmal was gepusht.
…mehr als schade - Solaredge hatte sich das eigentlich groß auf die Fahne geschrieben.
Anyway. Dein Code sieht sehr gut aus. Ich habe lediglich die Adresse für ActivePower angepasst.
Ich weiß nicht warum, aber ich konnte meine Änderung nicht committen. Deshalb der kleine Auszug meiner Änderung hier:
new FC3ReadRegistersTask(0xE174, Priority.LOW, //
m(SymmetricEss.ChannelId.ACTIVE_POWER, //
new FloatDoublewordElement(0xE174).wordOrder(WordOrder.LSWMSW)), //
new DummyRegisterElement(0xE176, 0xE17D), m(SymmetricEss.ChannelId.CAPACITY, //
new FloatDoublewordElement(0xE17E).wordOrder(WordOrder.LSWMSW)),
new DummyRegisterElement(0xE180, 0xE183), //
m(SymmetricEss.ChannelId.SOC, //
new FloatDoublewordElement(0xE184).wordOrder(WordOrder.LSWMSW))));
Es sieht so aus, als wenn es jetzt funktioniert. Ich kann Dir nur noch kein OK aus der Praxis geben: Der Speicher ist aktuell leer
Aber es sieht sehr gut aus. Falls sich die Sonne ein bisschen blicken lassen sollte, werde ich berichten.
Ich danke Dir von Herzen! Die Geschichte ist für den Rest meiner Haussteuerung eminent wichtig!
Super. Kannst du bitte noch deine Anpassungen zur Verfügung stellen? Am liebsten als Commit direkt auf Github - dazu kann ich https://desktop.github.com/ empfehlen - ansonsten auch gerne hier als Text, dann füge ich das selbst ein. Ich würde dann den PR fertig machen und auch mergen.
Vielleicht findet sich ja zukünftig noch ein Batterie-Wechselrichter der wirklich mit SunSpec 802 arbeitet. Bis dahin müssen wir das erstmal noch zurückstellen und mergen ohne diese Kompatibilität.
Meine Änderung hatte ich zwei Posts weiter oben eingefügt. Ich nutze ebenfalls GitHub-Desktop. Aber es ließ mich die Änderungen nicht committen. Authentifizierungsfehler.
Werde ich mich in den nächsten Tagen mit befassen - aber Du bist sicher schneller. Ich hatte nur eine Register-Adresse geändert.
Ich habe die SunSpec-Nicht-Konformität mal Richtung SolarEdge weitergegeben. Wie gesagt: es war auch schwierig überhaupt an das PDF mit den Adressen zu kommen. Es tauchte über einen User im ioBroker-Forum auf. Auf dessen Grundlage hatte er ein python-Skript geschrieben welches die Daten zum Speicher auslesen kann. Dieses war eine große Hilfe.
Der Solaredge-WR scheint übrigens nur eine Modbus-Verbindung zeitgleich zuzulassen. Keine Ahnung ob das üblich ist…Jedenfalls dient OpenEMS u.A. jetzt auch als Modbus-Slave für den Rest meiner Haussteuerung.
Ich werde mich mal daran versuchen den Speicher auch zu steuern. Aber für den Moment bin ich mit dem aktuellen Stand sehr zufrieden .
hm…doch noch nicht alles gut.
Der Wechselrichter produziert gerade ca. 2kW, ist aber der Meinung nur 51W zu erzeugen. ESS ist der Meinung sich zu entladen mit 1751W.
Ess SoC:15 %|L:1751 W Grid:206 W Production:51 W Consumption:2008 W
In Wirklichkeit wird der Speicher mit 1751W Beladen; 51W gehen in´s Netz und der Rest wird im Haus verbraucht. Verstehe ich nicht so richtig - heute morgen ging es ja.
Meine aktuelle Konfiguration umfasst einen Wechselrichter und ein ESS als getrennte Geräte. Sollte ich besser den WR als Hybrid-Wechselrichter konfigurieren?
Nachtrag:
Es sieht so aus als wenn ActivePower für das ESS nicht negativ wird. Warum auch immer…
Das Gerät liefert mir Strom und Spannung mit Vorzeichen:
…nur der resultierende Power-Wert ist wohl absolut
Es müsste demnach ausreichen, wenn ich die Leistung selbst ausrechne. Kannst Du mir einen Tipp geben an welcher Stelle das am besten gemacht werden soll?
Den PV-Inverter musst du bei dir löschen, weil der als AC-Quelle addiert wird und nicht als DC-Quelle (wie ein EssDcCharger).
Ich vermute mal, dass der SolarEdge diese Werte in verschiedenen SunSpec-Blöcken bereitstellt. Genau für SolarEdge hatte ich nämlich mal den [READ_FROM_MODBUS_BLOCK](https://github.com/OpenEMS/openems/blob/feature/solaredge-sunspec-ess/io.openems.edge.solaredge/src/io/openems/edge/solaredge/ess/SolarEdgeEss.java#L47) Parameter eingeführt. Alles in Allem leider nicht so einfach, an die richtigen Daten zu kommen und die dann richtig für OpenEMS zu übersetzen.
Versuche mal:
den READ_FROM_MODBUS_BLOCK zu erhöhen (von 0 starten und dann erhöhen, bis keine Daten mehr kommen)
dann jeweils schauen, welche Blöcke gelesen werden (S1 und S103 für READ_FROM_MODBUS_BLOCK 1 haben wir schon)
und mal mit einem DetailedLog jeweils alle verfügbaren Werte ausgeben lassen und mit den tatsächlichen aktuellen Werten abgleichen (also z. B. Wert entspricht aktueller PV-Produktion, Wert entspricht aktueller Battierie-Entladung, etc.)
Die Ausgabe des DetailedLog kannst du dann hier posten.
Die Verwirrung wird größer.
Es sieht so aus, als wenn sich die aktuelle Gesamt-Leistung der PV aus der Summe Batterieladung + dem aktuellen Verbrauch des Hauses ergibt:
2022-11-23T13:53:33,514 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] =======================================
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ID : ess0
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ---------------------------------------
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103A : 4.0 A
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103AphA : 1.0 A
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103AphB : 1.0 A
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103AphC : 1.0 A
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Dca : 1.0 A
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Dcv : 817.0 V
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Dcw : 1032.0 W
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Pf : -98.0
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103VAr : -185.0 var
2022-11-23T13:53:33,515 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Va : 1033.0 VA
2022-11-23T13:53:33,516 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103W : 1017.0 W
2022-11-23T13:53:33,516 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] S103Wh : 1.4489251E7 Wh
2022-11-23T13:53:33,516 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ---------------------------------------
2022-11-23T13:53:36,532 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] =======================================
2022-11-23T13:53:36,532 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ID : ess0
2022-11-23T13:53:36,532 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ---------------------------------------
2022-11-23T13:53:36,532 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] ActivePower : 3755 W
2022-11-23T13:53:36,532 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] Current : -4.577032 A
2022-11-23T13:53:36,533 [_cycle ] INFO [g.detailedlog.DebugDetailedLog] [ctrlDetailedLog1] Voltage : 819.94806 V
Zu diesem Zeitpunkt lag die PV-Produktion bei ca. 4,5kW.
Die Werte von oben stammen vom python-Skript. Dort finde ich nirgends ein Register welches den aktuellen PV-Ertrag darstellt.
Ab Modbus-Block 3 kommt nichts mehr…
Viel habe ich bisher nicht herausfinden können:
Register E170 (Voltage) ,Register E172 (Current) beziehen sich auf die Batterie und resultieren in der Lade/Entladeleistung. Register E174 (Power) IST vorzeichenbehaftet. Allerdings bedeutet ein “-” die Entladung des Speichers.
Wenn Power negativ ist, sind Strom und Spannung positiv. Man könnte also sagen, dass Solaredge intern rechnet: U * I *(-1) = P
Für heute habe ich keinen PV-Ertrag mehr. Morgen forsche ich weiter…
Ich habe verschiedene Szenarien beobachtet und zumindest etwas Erkenntnis erlangt. Kurz zum Setup: Ein Grid-Meter (SE-MTR-3Y-400V-A) , Wechselrichter (SE10K-RWS48BEN4), Batterie (SolarEdge Home Battery 9.2kWh). Alle Geräte sind mit dem Wechselrichter verbunden und können auch nur über diesen per Modbus abgefragt werden. Channel_Zuordnung.xlsx (10.1 KB)
Ich habe mal etwas gespielt und den HybridESS mit implementiert. Die Lade/Entladeleistung musste negiert werden und an DC_DISCHARGE_POWER übergeben werden. Das funktioniert auch soweit.
Um den aktuellen PV-Ertrag zu ermitteln, müsste ich doch eigentlich ein Meter-Device implementieren, oder? Jedenfalls kommen keine Daten wenn ich SunSpecModel 203 einbinde.
Mein Experiment habe ich auf github committed. Es gab wohl ein Problem mit der Registrierung meines PCs. Schon wieder…
