Sonnen: deactivate bat control once

[ndrsnhs]

• Speichersteuerung für Sonnen nur einmalig und nicht in jedem Zyklus deaktivieren

[LKuemmel]

Wenn es nur zwei Zustände gibt, passt ein bool-Wert besser. Oder wenn die Zustände in allen Modulen gleich sein soll, ein gemeinsames Enum.

[cr0i]

Bei Solaredge deaktiviere ich den Remote Modus nur noch nach einer aktiven Steuerung durch openWB.
Einmal kann für eine externe Steuerung ja auch schon zu viel sein, damit sie durcheinander kommt.
Wenn man den last_mode im Broker speichern würde wäre es perfekt, das übersteigt aber meine Kenntnisse.
Dann könnte man auch den Fall eines Absturzes oder unerwarteten Neustarts während der aktiven Steuerung abfangen.

[ndrsnhs]

Danke für den Input @cr0i
Du hast recht. Der aktuelle Modus wird nicht persistent nachgehalten. Bedeutet nach Neustart kann man ggfs. Probleme bekommen falls eine Steuerung durch openWB gar nicht gewünscht ist.
Das betrifft aber nicht nur Sonnenbatterie alleine.
Der Einwand ist gut - wir finden eine Lösung dafür.

[seaspotter]

Die Idee damals dahinter - und heute noch immer - ist ja aber, dass es einen undefinierten Zustand geben kann, weil eine externe Steuerung gerade eingreift oder aber es z.B. einen Absturz/Update von openWB gab. Woher weiß man dann in welchem Steuermodus der Speicher gerade ist? Ein Abfragen ist auch nicht immer möglich je nach Speicherhersteller. In meinen Augen ist das einmalige Setzen in einen definierten Zustand (so wie es aktuell ja auch passiert) der einzige richtige Weg. Das muss man eben akzeptieren, dass ich auch bei einer gewählten Speichersteuerung durch openWB einmalig beim Neustart einen definierten Zustand setze.
Wenn ich einer Speichersteuerung nicht zugestimmt habe, dann wäre es folgerichtig natürlich auch richtig zu sagen: ich setze das power_limit gar nicht, auch nicht einmalig.

[ndrsnhs]

@seaspotter ich sehe den undefinierten Zustand eher als Trick um einen Neustart der openWB zu erkennen. Im laufenden Betrieb tritt er ja nicht mehr auf.
Als Beispiel: wenn eine externe Steuerung eingreift gibt es wie du ja schreibst keine Möglichkeit den aktuellen Steuermodus festzustellen. Da greift der undefinierte Zustand also nicht, die openWB bleibt einfach im aktuellen Modus. Bei aktiver Speichersteuerung überschreibt die openWB den extern gesetzten Zustand aber auch direkt wieder (bei Eigenregelung nicht direkt).
Die simple Lösung des Problems wäre den Neustart zu erkennen (undefinierter Zustand) und dann falls die Steuerung deaktiviert ist nichts an den Speicher zu senden.
Falls die Steuerung aktiv ist wird den Einstellungen gemäß geregelt. Also genau wie du sagt in einen definierten Zustand überführt.
Problem ist ja nicht die Regelung der openWB, sondern wenn man diese nicht möchte.
Wie siehst du das?

[benderl]

Ich hatte damals absichtlich nicht diese "last_mode" Implementation der anderen Module verwendet, da das Problem einen Schritt vorher gelöst werden muss. Wenn openWB den Speicher nicht regeln soll, dann darf weder bei einem Neustart noch irgendwann zwischendurch der Modus des Speichers gesetzt werden. Das sollte vor dem Aufruf des jeweiligen Speichermoduls bereits geprüft werden und so waren wir damals eigentlich auch verblieben. Wundert mich jetzt etwas, dass es doch anders umgesetzt werden soll.

[ndrsnhs]

@benderl du bekommst den last_mode leider nicht komplett aus den Modulen raus (zumindest was den Mode None angeht). Es gibt Speicher bei denen zyklisch geschrieben werden muss, damit sich der Status nicht eigenständig zurücksetzt, es gibt aber ebenso Komponenten bei denen nur einmal auf Eigenregelung gesetzt wird.
Sobald aktiv geregelt werden soll ergibt es mMn Sinn das an die Module zu übergeben und die sorgen dann für die modulspezifische Umsetzung.
Ist die Speichersteuerung aus dann sollte gar nichts ans Modul gehen, richtig. Das kann man übergeordnet machen.
Wird von aktiver Regelung auf "Aus" gestellt muss der Speicher aber auch in den Zustand Eigenregelung überführt werden. Einige Speicher setzen sich eigenständig auf Eigenregelung zurück, da würde es wirklich genügen nichts mehr zu tun, bei anderen muss das explizit einmal gesetzt werden.
Wird das übergeordnet umgesetzt, weiß man nicht welche Art Ansteuerung der Speicher erwartet, das ist auf der Ebene nicht bekannt. Es muss also mindestens einmal an den Speicher übergeben werden. Das macht erforderlich, dass in der bat_all.py erkannt wird, dass die aktive Steuerung ausgestellt wurde, danach wird der Wechsel des Modus einmal angestoßen/ an das Modul übergeben.
Für Module die den Modus eigenständig wechseln muss dann nochmal im Modul geprüft werden ob das wirklich gemacht werden soll, das geht vermutlich auch nur indem man dort den Status nachhält.

Über den aktuellen last_mode lässt sich die herstellerspezifische Ansteuerung recht gut umsetzen. Für mich klang es in erster Instanz einfacher dort noch den aktuellen Status der Speichersteuerung (An/ Aus) zu prüfen und entsprechend zu agieren.
Das übergeordnet zu haben wäre definitiv eleganter nur sehe ich gerade nicht wie sich das praktikabel umsetzen lässt.

[seaspotter]

Der last_mode hatte ja ursprünglich im ersten Schritt eine ganz andere Bedeutung: Nämlich das ich nicht permanent in die Modbus Register des Speichers schreiben muss, selbst wenn sich gar nichts ändert. Ansonsten wäre im Regelzyklus "none" oder "stop" oder eben ein Wert für Entladung bzw. Ladung regelmäßig geschrieben worden. Das wollte ich damals mit dem last_mode eben vermeiden. Bei Übergabe eines Werts ändert der sich ja erwartungsgemäß auch regelmäig bzw. ist selten identisch über lange Zeit, aber eben bei einer "0" oder dem "none".
@ndrsnhs Ja ich bin absolut bei dir, wenn die Speichersteuerung aus ist, dann sollte gar kein power_limit übergeben werden, damit die Kontrolle komplett beim Kunden liegt bzw. seiner externen Steuerung und erst wenn die aktive Steuerung gewollt ist, dann eben im Regelzyklus ein Wert übergeben werden.
Ich denke ohne den last_mode gehts es auch sinnvoll eben nicht, weil ja doch ein paar Hersteller ein timeout haben, wo dann ggf. auf Eigenregelung zurückgestellt wird.

Zusammengefasst:

• Speichersteuerung aus : Kein power_limit wird gesetzt
• Wechsel An/Aus und Aus/An der Speichersteuerung : Es muss einmalig ein power_limit=none übergeben werden für einen definierten Zustand
• Speichersteuerung an: Regelung über power_limit

Wobei bei letzterem: braucht es dann noch ein "last_mode=undefined"? Ansonsten weiß man ja auch nicht wie der last_mode gerade steht?

[benderl]

Ist die Speichersteuerung aus dann sollte gar nichts ans Modul gehen, richtig. Das kann man übergeordnet machen.

Das war eigentlich der Fall, den ich benötige und gemeint habe. Aktuell wird trotz komplett deaktivierter Steuerung mindestens 1x nach einem Neustart der Speicher auf Eigenregelung gesetzt. Eine eventuell extern laufende Steuerung wird dadurch ausgehebelt. Das sollte dringend übergeordnet in der Regelung behoben werden. Wenn die openWB denn aktiv steuern soll, ist es ja legitim vorauszusetzen, dass es keine externe Steuerung gibt, welche gestört werden kann.

[cr0i]

Wenn power_limit = None nur einmalig gesendet wird, um die Steuerung durch openWB zu beenden wäre es ideal.
Dann müsste noch power_limit=0 auch nur gesendet werden, wenn es nötig ist (Wenn Power <> 0), damit nicht ständig die 0 oder der Sperrmodus geschrieben werden muss.
Bei power_limit < 0 wird sowieso bei jedem Durchgang ein anderer Wert geschrieben, da muss nichts geändert werden.
Für die Speicherladung power_limit > 0 wird ja vermutlich nur der Max-Wert oder ein anderer fester Wunsch-Wert übergeben, der ist dann vermutlich immer gleich und sollte auch nicht ständig geschrieben werden.
Dann bräuchte man den last_mode gar nicht mehr.
Es müsste dafür immer ausgelesen werden, ob der richtige Modus gesetzt ist, aber lesen ist ja nicht so schlimm wie schreiben?
Das ist besonders bei direktem Wechsel von Entladen auf Laden wichtig, damit dort der Modus wirklich wechselt.

Was ich auch noch für sehr wichtig halte:
Es sollte pro Speicher gewählt werden können, ob dieser gesteuert werden soll oder nicht.
Es kann ja sein, dass man mehrere Speicher hat, die nicht alle gesteuert werden sollen.
Wie teilt sich der Hausverbrauch eigentlich bei mehreren Speichern auf? Entlädt dann jeder mit dem Hausverbrauch?

[seaspotter]

Wenn power_limit = None nur einmalig gesendet wird, um die Steuerung durch openWB zu beenden wäre es ideal. Dann müsste noch power_limit=0 auch nur gesendet werden, wenn es nötig ist (Wenn Power <> 0), damit nicht ständig die 0 oder der Sperrmodus geschrieben werden muss. Bei power_limit < 0 wird sowieso bei jedem Durchgang ein anderer Wert geschrieben, da muss nichts geändert werden. Für die Speicherladung power_limit > 0 wird ja vermutlich nur der Max-Wert oder ein anderer fester Wunsch-Wert übergeben, der ist dann vermutlich immer gleich und sollte auch nicht ständig geschrieben werden. Dann bräuchte man den last_mode gar nicht mehr. Es müsste dafür immer ausgelesen werden, ob der richtige Modus gesetzt ist, aber lesen ist ja nicht so schlimm wie schreiben? Das ist besonders bei direktem Wechsel von Entladen auf Laden wichtig, damit dort der Modus wirklich wechselt.

Wie oben schon geschrieben von Andreas, es gibt Speicher die nach Zeit X (timeout) automatisch in den Eigenregelmodbus zurückgesetzt werden wenn keine erneute Anforderung für eine externe Steuerung kommt. Dafür braucht es eben im Regelzyklus ein permanentes power_limit und nicht nur ein einmaliges. Manch andere brauchen das nicht, da kann man es mit dem last_mode abfangen.

Die Eigenheit mehrere Speicher an einem WR mit unterschiedlicher Ansteuerung gibt es m.W.n. nur bei Solaredge, alle anderen Hersteller sagen ein Speicher pro WR oder alle angeschlossenen Speicher fungieren nach Aussen als ein Speicher.

[cr0i]

Wie oben schon geschrieben von Andreas, es gibt Speicher die nach Zeit X (timeout) automatisch in den Eigenregelmodbus zurückgesetzt werden wenn keine erneute Anforderung für eine externe Steuerung kommt. Dafür braucht es eben im Regelzyklus ein permanentes power_limit und nicht nur ein einmaliges. Manch andere brauchen das nicht, da kann man es mit dem last_mode abfangen.

Die openWB "merkt" ja, wenn sich der Speicher nicht wunschgemäß verhält, dann soll der Wert natürlich wieder übergeben werden, bis er "artig" ist. Das meinte ich oben mit (Power <> 0).
Wenn das natürlich alle paar Sekunden passiert, wäre das unschön.
Der Timeout liegt bei SolarEdge z.B. bei 3600 sec, da kann man aber auch den Fallback-Modus angeben, daher stört es da nicht.
Wie lang sind denn bei anderen Herstellern die Timeouts?

Die Eigenheit mehrere Speicher an einem WR mit unterschiedlicher Ansteuerung gibt es m.W.n. nur bei Solaredge, alle anderen Hersteller sagen ein Speicher pro WR oder alle angeschlossenen Speicher fungieren nach Aussen als ein Speicher.

2 Speicher an einem WR, wie bei SolarEdge ist unkritisch, da ist immer nur einer gleichzeitig aktiv, bzw. es steuert m.E. der Main-WR den Wert.
Es haben aber viele 2 oder mehr Speicher, ggf. auch von verschiedenen Herstellern.

[seaspotter]

Die openWB "merkt" ja, wenn sich der Speicher nicht wunschgemäß verhält, dann soll der Wert natürlich wieder übergeben werden, bis er "artig" ist. Das meinte ich oben mit (Power <> 0). Wenn das natürlich alle paar Sekunden passiert, wäre das unschön. Der Timeout liegt bei SolarEdge z.B. bei 3600 sec, da kann man aber auch den Fallback-Modus angeben, daher stört es da nicht. Wie lang sind denn bei anderen Herstellern die Timeouts?

Es gibt aktuell keine Kontrolle ob die übergebenen Werte seitens openWB auch so umgesetzt wird in der Speichersteuerung. Es wird auch kein Fehler ausgegeben und gegengesteuert. Insofern "merkt" da niemand etwas, ausser der User der ggf. davor sitzt und das gegenprüft.
Kostal hat m.E. einen max Timeout von 60sec glaube ich.

2 Speicher an einem WR, wie bei SolarEdge ist unkritisch, da ist immer nur einer gleichzeitig aktiv, bzw. es steuert m.E. der Main-WR den Wert. Es haben aber viele 2 oder mehr Speicher, ggf. auch von verschiedenen Herstellern.

Das ist technisch aktuell gar nicht möglich, da sich 2 Speicher unterschiedlicher Hersteller permanent den Überschuss wegnehmen würden, es würde eine unendliche Regelschleife geben. Weil die beiden Speicher gar nichts voneinander wissen, war auch schon oft Thema im Forum. Das geht nur wenn es ein externen EMS gibt welches die Steuerung beider (oder mehrerer) Speicher komplett übernimmt und steuert welcher Speicher nun lädt und welcher entlädt. Zukunftsmusik für openWB z.B.
Anders wenn man einen Hersteller hat wo es Master/Slave gibt, aber auch da steuert eben der eine Master was welche Batterie macht und für openWB gibt es nur einen "Ansprechpartner", eben so wie bei Solaredge dann vermutlich auch.

[cr0i]

Dann macht es vermutlich keinen Sinn, bei power_limit = 0 oder beim Laden Schreibzugriffe zu reduzieren, das werden die Systeme schon überleben, ist ja nur während der Steuerung.

Dass es die Überwachung (noch) nicht gibt, ist klar, könnte übergeordnet aber abgefragt werden, da die Werte des Speichers dort ja vorliegen. Aber wenn man alle 60 Sekunden eingreifen muss, braucht man darauf keine Energie zu verschwenden.