Ich nehme mal nur die halbwegs konstruktiven Beiträge aus dem Feedback Thread auf, um das Thema getrennt zu diskutieren:
jbartels hat geschrieben: Di Apr 22, 2025 6:55 am
Sonnenbatterie !!
so wie es aussieht schaltet openWB bei der einstellung "Speicher-Entladung ins Fahrzeug steuern" = "immer"
wirklich immer von mode1 (Manuell) zurück auf mode 2 (eigenverbrauch) auch wenn das z.b. über sonnen dashboard oder ioBrocker auf manuell gestellt wird.
da fehlt dann die option aus !! auch wenn ich das so sehe das "immer" die sonnenBatterie einstellung nicht anfasst.
api änderung ist ja nur notlösung da dann zb der hausverbrauch wieder berechnet statt gemessen wird
seaspotter hat geschrieben: Di Apr 22, 2025 8:01 am
Grundsätzlich sind mehrere Regelung immer schlecht weil sie sich gegenseitig beeinflußen (openWB, ioBroker, Lokal), also sollte man sich für eine Regelung entscheiden. Bei der Sungrow und SMA Speichersteuerung haben wir den last_mode eingebaut der eben das verhindert das der Modus überschrieben wird. Vielleicht ist das eine Überlegung sowas generell zu nutzen?
LutzB hat geschrieben: Di Apr 22, 2025 11:00 am
Danke @seaspotter, da habe ich nicht viel zu ergänzen.
In dem Beispiel von jbartels sind es nicht nur zwei Regelungen, die sich ins Gehege kommen und die Modi umschalten. Das könnte man noch durch den "last mode" irgendwie abgreifen. Was aber ist, wenn beide Regelungen auf "manuell" umschalten und die Ent-/Ladeleistung der Batterie steuern? Ich sehe hier spontan keine sinnvolle Lösung. Das Thema kann sehr schnell sehr komplex werden, also bei Bedarf bitte einen eigenen Beitrag zur Diskussion eröffnen.
Ich stand bei der Speichersteuerung für SolarEdge vor dem gleichen Problem.
Bei SolarEdge kommt noch verschärfend hinzu, dass es 2 verschiedene Augangszustände (MaxEigenverbrauch und TimeOfUse) gibt.
Falls also jemand eine externe Steuerung oder eine Steuerung durch das SolarEdge Portal eingerichtet hat, sollte diese natürlich überhaupt nicht beeinflusst werden.
Ich hatte es auch erst mit dem last_mode umgesetzt, hierbei sollte aber im Fehlerfall die Steuerung einmalig zurückgesetzt werden.
Das könnte aber für eine externe Steuerung bereits zu viel sein, da sie ja gar nicht geändert werden sollte.
Daher hatte ich mir überlegt, dass jemand, der gar keine Beeinflussung haben möchte ja den Modus auf "Immer" stehen lässt.
Also sollte nach Möglichkeit in diesem Modus "gar nix" passieren.
Der Modus war aber erstmal nicht verfügbar.
Nachdem ich es geschafft habe, diesen einzubauen, habe ich den last_mode eigentlich gar nicht mehr gebraucht und wieder ausgebaut.
Bei SolarEdge gab es aufgrund einer Sonderbehandlung verschiedener Speicher und der o.g. Besonderheit einiges mehr zu klären, daher ist diese Speichersteuerung noch nicht verfügbar.
Evtl. kann aber der Ansatz, den Speichermodus abzufragen und bei "Immer" keine Steuerung vorzunehmen in den anderen Modulen auch genutzt werden.
Es ist folgendermaßen umgesetzt:
Code: Alles auswählen
from control import data
...
def set_power_limit(self, power_limit: Optional[int]) -> None:
unit = self.component_config.configuration.modbus_id
try:
PowerLimitMode = data.data.bat_all_data.data.config.power_limit_mode
except AttributeError:
log.warning("PowerLimitMode not found, assuming 'no_limit'")
PowerLimitMode = 'no_limit'
if PowerLimitMode == 'no_limit':
"""
Keine Speichersteuerung, andere Steuerungen zulassen (SolarEdge One, ioBroker, Node-Red etc.).
Falls andere Steuerungen vorhanden sind, sollten diese nicht beeinflusst werden,
daher erfolgt im Modus "Immer" der Speichersteuerung keine Steuerung.
"""
return
...
Danach geht dann erst die eigentliche Steuerung los.
Vielleicht hlft das ja Abseits der Kommunikationsprobleme...
