SolarEdge Speichersteuerung mit Battery Index

[cr0i]

Umsetzung der Speichersteuerung von SolarEdge.
Für die Umsetzung des Battery Index aus #2236 wurde hier bereits der Battery Index für die Unterstützung von 2 Batterien als feste Variable eingefügt.
Nach Umsetzung des PR#2236 muss diese nur entfernt werden, damit ist die Unterstützung hierfür bereits gewährleistet.

Noch offen:
Erst ab Firmware Version 4.20.36 werden TimeOfUse Profile unterstützt.
Die Firmware kann als String aus dem WR ausgelesen werden.
Beim Beenden des Remote Modus muss bei kleinerer Version auf Maximaler Eigenverbrauch (1), statt TimeOfUse(2) zurückgestellt werden.

Um fremde Steuerungen durch z.B. SolarEdge ONE nicht zu beeinflussen, erfolgt im Modus "Immer" gar keine Steuerung.
Sonst wird beim Reboot der openWB der Remote Modus beendet, falls er durch Abstürze oder fehlerhafte Steuerungen aktiv sein sollte.
Dies ist wichtig, da sonst keine Zwangsladung bei Unterschreitung des Mindest-SoC gegen Tiefentladung mehr läuft.

[cr0i]

Ich habe jetzt den last_mode ausgebaut und durch Auslesen der Register ersetzt.
Den Sperrmodus, den ich ursprünglich genommen hatte, führte bei mehr PV-Überschuss als gerade zur Ladung nötig sind, zu nicht korrekter Ladung des Speichers, daher habe ich auch diesen nur noch über Setzen des DischargeLimit realisiert.
Ich schreibe das DischageLimit nur, wenn es um mehr als 10W vom aktuellen power_limit abweicht, das soll gegenseitige Beeinflussungen, wenn 2 Speicher vorhanden sind verhindern.
Nun habe ich leider festgestellt, dass wir noch einen Config-Wert (SoC-Reserve) benötigen, da wir diesen leider nicht zuverlässig auslesen können.
SolarEdge entlädt den Speicher immer nur bis zu einem bestimmten SoC, dieser ist aber leider je nach Batterietyp oder ggf. anderen Faktoren unterschiedlich.
Bei mir mit BYD Speicher sind es 10%, bei 2 LG Batterien wohl 5%.
Wenn dieser Wert unterschritten wird, erfolgt eine Zwangsladung des Speichers aus dem Netz. Dies funktioniert aber nicht, wenn wir gerade den RemoteMode aktiv haben und diese Funktion damit sperren.
Daher müssen wir bei Unterschreitung der SoC-Reserve die Steuerung beenden.
Ich habe die Variable soc_reserve erstmal fest mit 10 aufgenommen, da ich die Konfiguration inkl. UI vermutlich nicht hinbekomme.
Aktuell scheitere ich daran, dass ich bei älteren Firmware Versionen als 4.20.36 einen anderen Wert für den ControlMode beim zurückschalten aus dem RemoteMode benötige. Das Auslesen der Firmware bekomme ich aktuell nicht hin.
Die Register haben ein String(16) Format. Wenn ich das richtig sehe, müsste das dann auch in die common/modbus.py aufgenommen werden, da es das Format aktuell gar nicht gibt.
Vielleicht sollte man auch gleich String(32) mit aufnehmen, der kommt an anderen Stellen auch vor (Ich weiß aber nicht, ob den jemand braucht).

@LKuemmel oder @benderl :
Könnten wir für diese Steuerung einen eigenen Featurezweig bekommen?
Es gibt ja sehr viel verschiedene Konstellationen, mit 1 WR, kaskadierte WR, mit 1 oder 2 Speicher.
Damit wir damit gezielt Testen können, ohne dass alle SolarEdge Speicher auseinander fallen, wäre das bestimmt hilfreich. ;-)

[cr0i]

Ich lese nun den ControlMode vorher aus und schreibe ihn dann wieder zurück.
Für den Fall, dass dieser nicht bekannt ist, wird 1 (MaxEigenverbrauch) genutzt, so ist es mit jeder Firmware kompatibel.

Den Wert für battery_index übernehme ich mit 1, solange er noch nicht umgesetzt ist.
Es könnte also nun bereits übernommen werden, bevor die Änderungen dort fertig sind.
Dann müsste nur diese bat.py übernommen werden.

Den Wert für soc_reserve übernehme ich mit 10, solange er noch nicht umgesetzt ist.
Die Speichersteuerung wird so bei erreichen von 10% beendet, ist also erstmal mit allen Speichern kompatibel.
Wenn im Portal eine Backup-Reserve eingerichtet ist, wird diese übernommen.
Die soc_reserve muss noch in der Config des Speichers umgesetzt werden, das kann ich aber nicht, müsste also jemand anderes übernehmen. Das kann nun auch später erfolgen.
Als Standardwert sollte dann 0 übernommen werden, mein Textvorschlag für die SoC-Reserve:

SolarEdge entlädt die Speicher nur bis zu einem Mindest-SoC (Soc-Reserve).
Dieser kann je nach Speicher mal 10%, 5% oder 0% betragen. Da sie nicht automatisch ermittelt werden kann, muss sie hier konfiguriert werden.
Bei Systemen mit Backup-Modulen gibt es zusätzlich die Backup-Reserve, diese muss hier nicht eingetragen werden, da sie automatisch berücksichtigt wird.

[cr0i]

Ich habe versucht die Änderungen im master einzupflegen und die Konflikte zu beheben.
Müsste so nach meiner Ansicht passen, die Konflikte verschwinden aber nicht.

[cr0i]

Es gibt noch einen Sonderfall, der ggf. zu Problemen führen könnte:
https://forum.openwb.de/viewtopic.php?p=126852#p126852
Muss daher nochmal überarbeitet werden.

[cr0i]

Es gibt noch einen Sonderfall, der ggf. zu Problemen führen könnte: https://forum.openwb.de/viewtopic.php?p=126852#p126852 Muss daher nochmal überarbeitet werden.

last_mode wieder eingebaut, Problem damit behoben.

[seaspotter]

Du musst dein Branch auch hochziehen, weil zwischenzeitlich Commits gemacht wurden an gleicher Stelle, deshalb rennt dein PR auch in Konflikte. Damit musst du die bereits gemachten Änderungen aus #2317 nicht mehr mitziehen.

[cr0i]

Du musst dein Branch auch hochziehen, weil zwischenzeitlich Commits gemacht wurden an gleicher Stelle, deshalb rennt dein PR auch in Konflikte. Damit musst du die bereits gemachten Änderungen aus #2317 nicht mehr mitziehen.

Kannst Du mir verraten, wie ich das machen kann ohne Probleme zu verursachen?
Das letzte mal, als ich sowas versucht hatte, hatte ich plötzlich 300 geänderte Files und der PR war unbrauchbar.
Hatte dann einen komplett neuen erstellt, da ich es auch nicht rückgängig machen konnte.
Ich nutze Github Desktop.

[seaspotter]

Kannst Du mir verraten, wie ich das machen kann ohne Probleme zu verursachen? Das letzte mal, als ich sowas versucht hatte, hatte ich plötzlich 300 geänderte Files und der PR war unbrauchbar. Hatte dann einen komplett neuen erstellt, da ich es auch nicht rückgängig machen konnte. Ich nutze Github Desktop.

Such mal nach "Resolve Merge conflicts Github" da müsste es sicher ne Menge Anleitungen und Videos zu geben, ich nutze Visual Studio Code.

[LKuemmel]

Probier mal mit der Ergänzuung folgender Methoden in der common/modbus.py Strings zu lesen:

    def __read_string(self, func: Callable, address: int, length: int = 1, byteorder: Endian = Endian.Big,
                      wordorder: Endian = Endian.Big, **kwargs) -> str:
        response = self.__read_registers(func,
                                         address,
                                         [ModbusDataType.INT_16]*length,
                                         byteorder,
                                         wordorder,
                                         **kwargs)
        string = ""
        for word in response:
            string += struct.pack(">h", word).decode("utf-8")
        return string

    def read_input_string(self, address: int, length: int = 1, byteorder: Endian = Endian.Big,
                          wordorder: Endian = Endian.Big, **kwargs) -> str:
        return self.__read_string(self._delegate.read_input_registers,
                                  address,
                                  length,
                                  byteorder,
                                  wordorder,

                                  **kwargs)

    def read_holding_string(self, address: int, length: int = 1, byteorder: Endian = Endian.Big,
                            wordorder: Endian = Endian.Big, **kwargs) -> str:
        return self.__read_registers(self._delegate.read_holding_registers,
                                     address,
                                     length,
                                     byteorder,
                                     wordorder,
                                     **kwargs)

Für #2236 habe ich auch das Review gemacht. Wenn er rebased wurde, merge ich ihn und dann kannst Du auch einen Rebase machen und die Änderungen in Deinen PR holen.

[LKuemmel]

Suggested change

	PowerLimitMode = data.data.bat_all_data.data.config.power_limit_mode
	power_limit_mode = data.data.bat_all_data.data.config.power_limit_mode

Bitte auf die Python naming convention achten. CamelCase zeigt einen Klassen-Namen an.

[LKuemmel]

Hast Du probiert, ob die Werte auch ohne vorheriges Encodieren geschrieben werden? Eigentlich macht pymodbus das.

[cr0i]

Hast Du probiert, ob die Werte auch ohne vorheriges Encodieren geschrieben werden? Eigentlich macht pymodbus das.

Ich habe das aus der SMA Speichersteuerung abgekupfert, ich brauche bei SolarEdge aber wordorder Endian.Little, das konnte ich nur an der Stelle einbauen.

[LKuemmel]

Ok, das stimmt. Kannst Du den Code bitte in die common/mdobus.py verschieben? Der ist ja nicht SolarEdge-spezifisch und kann auch von anderen Modulen genutzt werden.

[cr0i]

Ich habe ja die wordorder Little fest hinterlegt, die müsste man dann vermutlich besser per übergebenem Parameter einrichten oder nur für die Kombination eine eigene def (byteorder Big, wordorder Little) anlegen?
Das übersteigt meine Copy&Paste Fähigkeiten, ich könnte nochmal im Forum fragen, ob jemand helfen kann.

[cr0i]

Hallo @LKuemmel ,

mir ist bei einem Austausch mit openwb noch ein neuer Weg eingefallen, die soc_reserve dynamisch zu ermitteln.
Daher gibt es nun 3 Ansätze:

1. soc_reserve als Config Option in die Bat aufnehmen, als Standardwert wird 10 übergeben, dieser muss vom Anwender entsprechend angepasst werden. Dafür kann ich dann auch gerne einen Wiki-Eintrag schreiben.
2. Wenn wir Infos sammeln, welche Speicher es alles gibt und deren soc_reserve fest hinterlegen, dann müssten wir den Hersteller-String des Speichers auslesen und dann den Wert hinterlegen. Die Idee habe ich eigentlich verworfen, da zu viel Pflegeaufwand im Modul.
3. Wenn ich die soc_reserve initial mit 10 definiere, und dann bei jedem auslesen des SoC den niedrigsten Wert in einer Variable (z.B. min_soc) speichere, dann haben wir nach einem Entladezyklus die soc_reserve dynamisch ermittelt. Ich würde den Wert extra nicht in den MQTT-Broker schreiben. Falls SolarEdge mal eine Änderung einbaut und den Wert ändert (ist in der Vergangenheit schonmal passiert), dann hätten wir wenigstens nach jedem Neustart wieder den korrekten Wert. Die Lösung gefällt mir eigentlich am Besten, müsste das aber erst noch bauen. Voraussetzung hierfür ist, dass "def initialize" nur einmalig nach einem Neustart ausgeführt wird. (Sollte aber m.E. so sein?)

Welche der Lösungen soll ich umsetzen?

VG
Christoph

[LKuemmel]

Option 2 halte ich auch für zu aufwendig.
Bei Option 3 sehe ich zwei Nachteile: - Wenn der Speicher mal den Reserve-SoC überschreitet, hat man dann einen zu niedrigen Wert als Reserve.

• Es müsste zumindest auf <= geprüft werden, sodass der aktuelle SoC auch der niedrigste bekannte SoC sein kann. Viele Anwender machen erstmal einen Reboot, wenn etwas nicht wie erwartet funktioniert und wenn dann nach jedem Reboot der Speicher erstmal komplett entladen werden muss, damit die Speichersteuerung funktioniert, ist das eine unschöne Abhängigkeit.

[cr0i]

Option 2 halte ich auch für zu aufwendig. Bei Option 3 sehe ich zwei Nachteile: - Wenn der Speicher mal den Reserve-SoC überschreitet, hat man dann einen zu niedrigen Wert als Reserve.

• Es müsste zumindest auf <= geprüft werden, sodass der aktuelle SoC auch der niedrigste bekannte SoC sein kann. Viele Anwender machen erstmal einen Reboot, wenn etwas nicht wie erwartet funktioniert und wenn dann nach jedem Reboot der Speicher erstmal komplett entladen werden muss, damit die Speichersteuerung funktioniert, ist das eine unschöne Abhängigkeit.

Die Speichersteuerung darf bei SoC = Reserve noch nicht beendet werden, da sonst bei 2 Speichern die Steuerung immer an- und ausgeschaltet wird, habe es nochmal korrigiert und den Grund kommentiert.

Ich habe es mal eingebaut, wie ich mir das denke:
Ich brauche 2 Variablen, da der aktuelle SoC 1-2 % unter dem Reserve-SoC Wert liegen kann (bei -2% erfolgt die Zwangsladung aus dem Netz).
Ich habe sie self.min_soc und soc_reserve genannt. (Hast Du für min_soc eine bessere Idee oder kann das so bleiben?)
Bei Auslesen des SoC vom Speicher wird immer der niedrigste Wert (soc, self.min_soc) in self.min_soc gespeichert.
Bei der Speichersteuerung nutze ich den höheren Wert aus self.min_soc+2 oder der Backup-Reserve(Falls konfiguriert) als Reserve-SoC.

self.min_soc habe ich aktuell Initial nur zum Test auf 100 bzw. 35 festgelegt, später soll es auf 8 definiert werden.
Das führt dazu, dass die Speichersteuerung nach einem Neustart auf jeden Fall funktioniert, wenn der SoC über 10% liegt.
Unter 10% wird die Speichersteuerung beendet.
Sollte es sich um einen Speicher handeln, der bis 5% oder 0% entladen werden kann, dann führt dies dazu, dass er wegen der beendeten Speichersteuerung bis zu seiner Grenze entladen wird.

Nach ein Neustart geht es also einmalig max. um 4% bzw. 9% ungewollte Entladung, bis der Wert einmal gelernt wurde.
Dafür haben wir dann aber eine Automatik, die keiner konfigurieren muss...
Bei Speichern mit 0% wird die Speichersteuerung bereits bei 1% beendet, das ist aber (s.o.) wegen dem Verhalten mit 2 Speichern nicht zu ändern.

Passt das so oder sollen wir die Config Option nehmen?

[LKuemmel]

Das kann so rein. Wenn die automatische Erkennung sich nicht als praktikabel erweist, kann ja immer noch die Konfig-Option eingebaut werden.

[cr0i]

Hallo @LKuemmel ,

nach den Hinweisen von seaspotter ist die Übergabe der konstanten Entladeleistung an den Speicher zwingend nötig.

Ich habe die Steuerung durch den Modus "Maximaler Eigenverbrauch" bei der SolarEdge Speichersteuerung über die "Maximale Entladeleistung" genutzt.
Hierdurch wird eine evtl. ungewollte Einspeisung aus dem Speicher, falls mal falsche Werte übergeben oder andere Probleme auftreten verhindert, daher habe ich mich für diese Umsetzung entschieden.
Hierbei wird aber die Entladung nicht erzwungen, wenn der Wechselrichter "anderer Meinung ist", es also zu einer Einspeisung führen würde.

Bitte gib mir Bescheid, wenn dies nochmal geändert werden soll.

VG
Christoph

[LKuemmel]

Hallo @cr0i,
solange der Speicher sich entlädt, wenn Netzbezug entstehen würde und bei aktiver Speichersteuerung nicht mehr entlädt, als die openWB vorgibt, passt Deine Implementierung.