76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 19 Juni 2025, 11:57:04

@all,

ich habe in der Zwischenzeit die (lineare) Skalierung der Balkengrafik überarbeitet und die Möglichkeit geschaffen, dass der User für jede vorhandene Ebene der Balkengrafik getrennt die Skalierung zwischen linear (default) und logarithmisch umschalten kann.
Ihr sehr die Darstellungsunterschiede in den Screenshots.

Die Umschaltung erfolgt über das Attr graphicControl->scaleMode:

scaleMode
Für jede Ebene der Balkengrafik kann der Skalierungsmodus linear oder logarithmisch festgelegt werden.
Die logarithmische Einstellung hebt kleine Werte stärker an und komprimiert größere Werte in der Darstellung.
Die Angabe für eine Ebene besteht aus der Ebenen-Nummer (1..X), einem ':' gefolgt von dem Modus 'lin' oder 'log'.
Die Strings für jede Ebene werden durch Komma getrennt (siehe Beispiel).
<Ebene>:lin - lineare Skalierung (default)
<Ebene>:log - logarithmische Skalierung

Beispiel: scaleMode=1:log,2:lin

Die V 1.52.14 liegt in meinem contrib.

LG,
Heiko

bismosa · 19 Juni 2025, 13:50:04

Hallo!

Vielen Dank für die ausführliche Antwort!
Das hat mich nun zumindest ein Stück weiter gebracht.

Code Auswählen

interruptable=Firmata_Aussensteckdose:SF_Int:1

Zitat von: DS_Starter am 19 Juni 2025, 11:43:31Das bedeutet, sobald der Regex "1" im Device:Reading Firmata_Aussensteckdose:SF_Int matcht, schaltet die Pumpe ab, egal ob noch Überschuß da ist oder nicht.

So steht es auch in der Commandref:

ZitatVerbraucher wird temporär unterbrochen, wenn der Wert des angegebenen Device:Readings auf den Regex matched

Code Auswählen

interruptable=1

ZitatVerbraucher wird temporär ausgeschaltet falls der PV Überschuß die benötigte Energie unterschreitet

Das sind demnach ja ganz unterschiedliche Funktionen.
Ich habe das nun gesetzt und die Pumpe lief sofort (wie eigentlich erwartet) los.

Dann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:

Code Auswählen

if ($mrest >= ($mneed - $msum)) {
          readingsSingleUpdate ($dhash, 'SF_Int', 1, 0);                        # Interrupt-Freigabe
      }
      else {
          readingsSingleUpdate ($dhash, 'SF_Int', 0, 0);                        # keine Interrupt-Freigabe
      }

Ich hatte gedacht, das dies dafür da ist, "interruptable=0" zu setzen, das die Pumpe nicht mehr ausgehen darf (damit diese lange genug am Tag läuft...auch bei Schlechtwetter). Aber nach der Beschreibung in der Commandref geht das nicht.?

Ich lasse jetzt mal die Werte $mrest $mneed $msum protokollieren. Vielleicht werde ich dann noch etwas schlauer.

Gruß
Bismosa

DS_Starter · 19 Juni 2025, 14:59:19

ZitatDann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:

Ja, das muß ich mir anschauen. Ich denke das passt nicht (mehr) und dort gehört ein anderer Befehl hinein.
Sage auf jeden Fall nochmal Bescheid wenn ich das reviewed habe.

Wzut · 19 Juni 2025, 17:36:44

Im battery_70 steckt ein Hochkomma zuviel, Wuppi wird es bestimmt noch tauschen

DS_Starter · 19 Juni 2025, 18:25:40

Ich habe die V im contrib upgedated -> die logarithmische Darstellung ist nachgebessert.

DS_Starter · 19 Juni 2025, 19:04:30

Ich habe das Fallbeispiel Pumpensteuerung im Wiki überarbeitet.

Das sollte nun passen.

LG,
Heiko

DS_Starter · 19 Juni 2025, 21:15:56

@Parallix,

ich möchte nochmal nachfragen bzgl. dieser Anforderung:

ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.

Habe ich das so richtig wiedergegeben?

LG,
Heiko

Max_Meyer · 19 Juni 2025, 22:10:07

Zitat von: DS_Starter am 19 Juni 2025, 21:15:56ch möchte nochmal nachfragen bzgl. dieser Anforderung:

ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.

Habe ich das so richtig wiedergegeben?

Hallo allerseits,
ich frage mich ob eine einseitige Fokussierung ausschließlich auf netzdienliche Batterieladung im letzten drittel des Tages so sinnvoll ist.
Da ist zum einen die 'Energie-Konkurrenz' zwischen Batterie(n) und 'Großverbrauchern z.B. WP, Heizstab, E-Car, WA, GSP, Poolheizung etc. besonders in der Übergangszeit(Herbst, Winter, Frühjahr) wo gerade genug Energie vom Dach zur Verfügung steht um den Bedarf weitestgehend zu decken. Und die Batterie ist ein 'gutmütiger' Consumer - d.h. die nimmt die PV-Energie ab wenigen Watt Überschuss und gewährleistet so eine max. Ausbeute während z.B. meine WP mind. 650 W braucht um anzulaufen und bei PV-Überschuss den Puffer wärmer zu machen als er lt. Heizkurve sein müsst - ein Heizstab braucht 1500W, E-Car alt ab 1500W neu (ISO 15118) 600W etc.
Auf der anderen Seite sollte jede Batterie (Theorie (Studie) durfte ich gerade lernen) nur möglichst kurz im Ladezustand 100% verharren. Ansonsten altert eine (LFP-) Batterie überdurchschnittlich schnell. Zumindest ist dies neben Umgebungstemperatur und (Ent-) Ladestrom ein sehr entscheidender Einfluss. Mit Ladezuständen um die 80% passiert das nicht (siehe Handy). BMS hält auch eine definierte Ladung vor um Überladung und Tiefenentladung zu vermeiden.
Die Frage aus meiner Sicht ist, auf was optimiert werden soll - max. Energieausbeute vs. max. Batteriegesundheit.
Vielleicht ist es sinnvoll die Bat (erstmal nur im Sommer) bis auf 80% laden? Verbraucher priorisieren? so dass sie hintereinander einschalten solange PV Überschuss vorhanden ist und dann auch wieder ausschalten wenn weg? Aber wie kann man das planen? Es ist sicher möglich für Verbraucher ein Profil zu ermitteln - beim Heizstab z.B. der braucht (bei mir 200l WW-Boiler) ca. 0,5 kWh pro 1K Temperaturerhöhung - die Krux ist wenn der Heizstab ausschaltet weil z.B. 75°C erreicht sind (lt. Sensor Heizstab) ist das im oberen Bereich des Boilers noch nicht der Fall - also geht das Ding mit bis zu 4500 W 'unkontrolliert' wieder an sobald die Konvektion gewirkt hat - schreib das nur um die kleinen Klippen zu skizzieren die da so umhergeistern - denn heute stört das nicht, jede Lücke wird von der Batterie genutzt - die saugt die Energie weg wenn verfügbar.
Ich möchte diesen Post bitte nur als Diskussionsanstoß verstanden wissen - bin mir nicht sicher was da richtig wäre - gerne antworten
Gruß Gerd

DS_Starter · 19 Juni 2025, 23:59:14

Hallo Gerd,

meine Anlage fahre ich zur Zeit so, dass sie nur ca 2/3 der möglichen Einspeiseleistung einspeisen soll (plantControl->feedinPowerLimit).
Dadurch wird die Batterie in den Zeiten ohne "Ladefreigabe" bzw. "nur Laden wenn Einspeiselimit überschritten" bereits mit wenig Leistung (der evtl. Überschußleistung) geladen und der SoC steigt so langsam an. Mit der Ladefreigabe, die sich nach dem SoC in Beziehung zum erwarteten Restüberschuß des Tages sowie Verbrauchsprognose richtet, wird die Batterie dann mit voller Überschußleistung voll geladen.

So werden die 100% zur Zeit erst recht spät am Tag erreicht und gehen nach kurzer Zeit wieder in den Entladungsmodus.
Im Herbst/Winter wird die "Ladefreigabe" früher oder ohnehin für den ganzen Tag erteilt. Dadurch ist die Batterie eher voll (wenn möglich), aber die Energieausbeute und Einspeisung ohnhin gering(er).

Die Verbraucher kann man priorisiert im Modul planen lassen, indem man über die Schlüssel notbefore in Verbindung mit mintime und den weiteren Möglichkeiten eine Abfolge aufbaut. Man kann auch eine automatische Chain aufbauen, indem über eine kleine Logik in ctrlUserExitFn der Status planningstate='finished' eines Consumers ausgewertet wird um danach den nächsten zu starten. Es gibt viele Möglichkeiten.

LG,
Heiko

Parallix · 20 Juni 2025, 07:47:28

Zitat von: DS_Starter am 19 Juni 2025, 21:15:56@Parallix,

ich möchte nochmal nachfragen bzgl. dieser Anforderung:

ZitatEins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.
Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.

Habe ich das so richtig wiedergegeben?

LG,
Heiko

Hallo Heiko!

Ja, Du hast mich richtig verstanden. Was die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.

Hintergründe:

Das Laden eines Akkus mit möglichst gleichbleibender und geringer Leistung wirkt sich positiv auf dessen Gesundheit aus, was u.a. auch daran liegt, dass der Temperaturstress im Akku bei langsamer Energiezuführung nur gering ist.
Ein geringer Ladestrom führt zu einem geringen Absacken der Akkuspannung beim (ggf, temporären) Abschalten des Ladestroms, was sich positiv auf die SOC-Schätzung auswirkt.
Ein geringer Ladestrom führt, insb. bei Nutzung passiver Balancer (sind in den Akku-Systemen üblicherweise verbaut), zu einer geringen Differenz zwischen den einzelnen Zellspannungen und damit zu einer besseren Kapazitätsausnutzung eins Akkus.
Ein geringer Ladestrom kann zu zu einem zeitlich punktgenauen Zielfüllstand (im Winter 100%, ansonsten natürlich weniger) am Ende des Tages führen.
Eine geringer Ladestrom führt auch zu geringen Leitungsverlusten, da der Strom quadratisch zu den Leitungsverlusten beiträgt.

Übrigens:
Die häufig zu findende Empfehlung, Akkus nicht zu lange bei einem SOC von 100% verweilen zu lassen, liegt weniger an dem SOC als solchem, sondern daran, dass SOC=100% üblicherweise dadurch ermittelt wird, dass eine Zelle im Akku einen Spannungsschwellwert überschreitet, der – würde dieser Schwellwert zeitlich länger überschritten sein – zu einer Schädigung des Akkus führen würde. Schädlich sind also insb. häufige Nachladevorgänge bei Werten um die 100%, da Zellen dann ja häufiger und damit - integral gesehen - auch länger den o.g. Schwellwert überschreiten.

Einige Akku-Hersteller, z.B. BYD, haben auf o.g, Grund in der (neueren) Firmware Ihrer Systeme einen SOC-Threshold (bei BYD liegt dieser bei 95%) eingebaut, der nach einem SOC von 100% unterschritten werden muss, bevor überhaupt eine weitere Ladung erfolgen kann. Insb. in der dunklen Jahreszeit kann es daher sinnvoll sein, den Akku unter Verwendung von PV-Leistung so zu füllen, dass dieser möglichst nur einmal vor Einbruch der Dunkelheit SOC=100% erreicht. Hierbei sollte darauf geachtet werden, dass der Ladeschlussstrom des jeweiligen Systems nicht unterschritten wird.

Nun hoffe ich, dass meine Erläuterungen nicht zu sehr Off-Topic waren, meinen Feature-Request aber hinreichend motiviert haben und auch einige von Gerd aufgeworfene Aspekte beleuchtet haben.

Wolle02 · 20 Juni 2025, 07:49:25

Zitat von: DS_Starter am 14 Juni 2025, 23:04:37Der User kann mit dem Schlüssel pinmax die maximal mögliche Ladeleistung in Watt festlegen. mit welcher die Batterie geladen werden kann. Dieser Wert wird durch die SoC-Prognose auch beachtet.
Der User kann diesen Schlüssel dynamisch setzen mit:

Code Auswählen Erweitern
set ... attrKeyVal setupBatteryDevXX pinmax=<Wert>

Ich habe hier ein kleines Skript, das mir die Ladeleistung der Batterie dynamisch anpasst. Hierzu wird mittels set .... attrKeyVal den pinmax Wert dynamisch angepasst. Aktuell steht er z.B. auf 505 Watt.

Code Auswählen

PV_Batterie
cap=10240
charge=BatteryChargePercent
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pinmax=505
pout=BatteryDischargeWatt:W
show=2

Trotzdem wird die Batterie munter weiter mit der maximal möglichen Ladeleistung befüllt.
Wo hab ich hier den Fehler?

Parallix · 20 Juni 2025, 07:58:19

Zitat von: Wolle02 am 20 Juni 2025, 07:49:25...
Ich habe hier ein kleines Skript, das mir die Ladeleistung der Batterie dynamisch anpasst. Hierzu wird mittels set .... attrKeyVal den pinmax Wert dynamisch angepasst. Aktuell steht er z.B. auf 505 Watt.
...
Trotzdem wird die Batterie munter weiter mit der maximal möglichen Ladeleistung befüllt.
Wo hab ich hier den Fehler?

In SF ist pinmax "nur" ein Wert, der zur Kalkulation verwendet wird.

Setzt Du pinmax denn auch in Deinem WR?

Max_Meyer · 20 Juni 2025, 08:04:18

Zitat von: DS_Starter am 19 Juni 2025, 23:59:14meine Anlage fahre ich zur Zeit so, dass sie nur ca 2/3 der möglichen Einspeiseleistung einspeisen soll (plantControl->feedinPowerLimit).
Dadurch wird die Batterie in den Zeiten ohne "Ladefreigabe" bzw. "nur Laden wenn Einspeiselimit überschritten" bereits mit wenig Leistung (der evtl. Überschußleistung) geladen und der SoC steigt so langsam an. Mit der Ladefreigabe, die sich nach dem SoC in Beziehung zum erwarteten Restüberschuß des Tages sowie Verbrauchsprognose richtet, wird die Batterie dann mit voller Überschußleistung voll geladen.

Hallo Heiko, Hallo Parallix
Danke für die schnelle Antwort - die Idee ist gut umsetzbar - werde ich mal versuchen das zu skalieren.
Bei mir ist es derzeit so, dass die Batterien hintereinander geladen werden aber eben bis angezeigte 100% - wenn die alle voll sind, reicht die gespeicherte Leistung in der Heizperiode um über die Nacht zu kommen (PV vorausgesetzt) - dabei verwendet die WP schon tagsüber mittels PV-Direktverbrauch das Haus als Puffer um nicht unnötig Energie zu wandeln.
Gruß Gerd

DS_Starter · 20 Juni 2025, 08:33:14

Moin zusammen,

@Parallix,
Motivation ist schon da.

Die Umsetzung braucht ein bisschen Vorbereitung.

ZitatWas die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.

Mein Aussage war so zu verstehen, dass ich um einen Vergleich mit der Anzahl der PV-Überschußstunden rechnen zu können, die Minimalleistung auf eine Stunde normieren muß um ebenfalls Wh zu bekommen. Anders gesagt, wenn die Bat mit der Minimalleistung von 50W eine Stunde lang geladen wird, sind das 50Wh.
Wenn wir z.B. an einem Tag 10 Stunden ermitteln, in denen jeweils ein Überschüß >= 50Wh prognostiziert wird, hätten wir im Sinne der Anforderung einen Wert für Battery_ChargingHoursRemain_XX=10.

Das wäre m.M. nach die umzusetzende Logik zur Erstellung des Readings.

DS_Starter · 20 Juni 2025, 09:02:02

@Wolle02 / @all,

ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.

Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.

LG,
Heiko