76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Vor dem Hintergrund eines optimierten SOC Managements, aber auch in Hinblick auf eine immer wichtiger werden netzdienliche Steuerung/Regelung insb. auch von BAT-Lade/Endladevorgängen, möchte ich meine Anregungen von gestern etwas plastischer darlegen, da sie wirklich perfekt zu dem hier diskutierten Kontext passen.

Grundidee der Netzdienlichkeit ist, dass Einspeisungen in einem Netzsegment möglichst dann vorgenommen werden, wenn Sie im gleichen oder einem anderen nahe liegenden Segment  gebraucht werden und Verbräuche aus dem Netz möglichst dann getätigt werden, wenn im eigenen oder einem anderen nahe liegenden Segment aktuell eine Überproduktion existiert. Das ganze ist natürlich nur dann möglich, wenn auf Basis von BAT-Speichersystemen eine Pufferfunktionalität etabliert werden kann.

Das hier besprochene Modul bedient  - z.B. betreffend SOC-Optimierung - bis dato im wesentlichen die eigenen Wünsche und zwar ohne eine (gewünschte und langfristig auch erforderliche) Netzdienlichkeit zu berücksichtigen. Würde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten. Andersherum sollte - im Sinne der Netzdienlichkeit - kein Bezug von Energie aus dem Netz erfolgen, wenn dieses aufgrund geringer solarer Erträge im eigenen Netzsegment ohnehin  gefordert wird.

Das alles wäre eine rein perspektivische Optimierung auf Basis der Forecasts und würde – insbesondere, wenn's noch mehr Leute machen – im eigenen Netzsegment wahrscheinlich auch niemals zu VNB-seitigen Einspeise oder Bezugslimitierungen führen, was auch im eigenen Interesse sein dürfte. Das beste ist, dass das Modul bereits aktuell (fast) alles hierfür erforderliche bereitstellt.

[grappa24]

@stefanru

Man kann aber auch BatConfigReserve für einen MinSOC verwenden.

Ich kann zwar jetzt BatConfigReserve setzen, mein MinSOC (=Minimales Ladelimit) lässt sich aber "scheinbar" nicht beeindrucken 

Kann es sein, dass man den BYD nicht direkt (über Modbus) steuern kann sondern über den Fronius GEN24 gehen muss - um den MinSOC einzustellen?

P.S. Sorry, ich glaube das gehört besser in den Fronius Thread, aber ich glaube, wir haben es gleich

[DS_Starter]

Würde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten.

Das versuche ich mit der Routine zur Erstellung des Readings Battery_ChargeRecommended_XX zu unterstützen.
Der User wäre bei entsprechender Nutzung in der Lage seine Batterie(n) Prognose/Erzeugung-optimiert zu laden.
Wie gut das funktioniert müssen wir sehen wenn wieder mehr Sonnenenergie vorhanden ist. Werde ich auch noch im Wiki beschreiben wie man das für eine Victron-Anlage umsetzen kann.

[Parallix]

Würde man, basierend auf den Forecasts, BAT-Ladevorgänge hauptsächlich in die Zeiten positionieren, in denen besonders viel solare Energie lokal (und damit im wahrscheinlich auch im gesamten eigenen Netzsegment) zur Verfügung steht, dann würde man sich - ohne größere eigene Nachteile erleiden zu müssen - netzdienlich verhalten.

Das versuche ich mit der Routine zur Erstellung des Readings Battery_ChargeRecommended_XX zu unterstützen.
Der User wäre bei entsprechender Nutzung in der Lage seine Batterie(n) Prognose/Erzeugung-optimiert zu laden.
Wie gut das funktioniert müssen wir sehen wenn wieder mehr Sonnenenergie vorhanden ist. Werde ich auch noch im Wiki beschreiben wie man das für eine Victron-Anlage umsetzen kann.

Wird denn auch der umgekehrte Fall adressiert, bei dem die (noch nicht leeren) Speicher trotz solarer Energie zur Deckung des Eigenbedarfs genutzt werden (sollten), wenn später am Tag genug solare Energie zur Verfügung steht?

[DS_Starter]

Wird denn auch der umgekehrte Fall adressiert, bei dem die (noch nicht leeren) Speicher trotz solarer Energie zur Deckung des Eigenbedarfs genutzt werden (sollten), wenn später am Tag genug solare Energie zur Verfügung steht?

Nehmen wir an die Batterie ist zu 60% voll, der User hat upSoC=40 eingestellt.
Am Vormittag ist genügend Sonne vohanden, das Maximumum der Energie über die Zeit wird aber noch erwartet. Das Reading Battery_ChargeRecommended_XX würde dann "0" gesetzt und bei entsprechender Steuerung der Anlage durch den User würde

1. die Batterie nicht geladen
2. die erzeugte Energie dem Haus zur Verfügung gestellt bzw. der Überschuß eingespeist.

Gleichermaßen würde die Batterie entladen von 60% bis runter auf min 40% (bzw. noch tiefer bis lowSoC wenn sehr viel erwartet wird) und diese Energie dem Haus zuführen. Dabei wird aber permanent bei jedem Zyklus neu berechnet ob die Differenz vom aktuellen SoC zum eingestellten maxSoC hinreichend klein ist um mit dem zu erwartenden Restüberschuß des Tages wahrscheinlich maxSoC bzw. dessen Nähe zu erreichen. Sollte der Grenzwert erreicht sein, wird Battery_ChargeRecommended_XX=1 gesetzt und der User sollte dann über geeignete Befehle seine Anlage auf Modus "Laden" umschalten.
Dieser Vorgang kann beliebig oft während des Tages alternieren.

Ich denke der Prozess insgesamt unterstützt so ein netzdienliches Verhalten des Haushalts.
Wie gesagt, müssen wir in der Praxis testen wie gut das funktioniert.
 

[DS_Starter]

Ich habe die Vorabversion von gestern Abend eingecheckt und wird dann morgen früh ausgeliefert.
Zur Erinnerung was geändert wurde:

- das Attr ctrlStatisticReadings wird automatisch in ctrlSpecialReadings umgesetzt
- die generierten Readings heißen nun special_<Reading> statt statistic_<Reading>
- es sind die KPI BatPowerIn_Sum und BatPowerOut_Sum auswählbar

Da sich die statistic_<Reading> in special_<Reading> ändern, kontrolliert und ändert ggf. nach dem Update eure eigenen Skripte wo ihr diese Readingnamen verwendet!
Kontrolliert auch das Attr graphicHeaderOwnspec oder ctrlUserExitFn falls ihr es verwendet.

LG,
Heiko

[grappa24]

BatConfigReserve kam glaub ich später zu den ModBus Registern hinzu.
Schau mal ob du die attribute für obj-h40360 hast.
Wenn nicht übernehme sie mal von mir. Also alle für obj-h40360.

mir fehlten 4 der 8 attribute, hab ich ergänzt, jetzt geht der set-Befehl für BatConfigReserve

Man kann aber auch BatConfigReserve für einen MinSOC verwenden.

Ich kann zwar jetzt BatConfigReserve setzen, mein MinSOC (=Minimales Ladelimit) lässt sich aber "scheinbar" nicht beeindrucken 

Da hatte ich wohl "zuviel" erwartet 
Die BatConfigReserve lässt sich WOHL setzen und wird auch vom GEN24/BYD eingehalten, lediglich in der API erscheint der über Modbus gesetze Wert nicht. Jetzt kann ich weitermachen und das "Batterie SOC und Max. Ladestrom Management" umsetzen 

[kask]

Das finde ich aber äusserst doof das du die statistic Werte mal eben alle umbenennst. Es gibt ja Leute die auch mit den Werten weiter arbeiten und nicht das ganze Zeug aus dem Modul nutzen. Es gibt Gründe warum man beim Programmieren erst einmal depricated und nicht sofort umbenennt.
Und jetzt muß man (ich) das alles nachziehen!
Schade, schade!
Und der Grund erschliesst sich mir auch ehrlich gesagt nicht. Weil ein Wert so nicht als statistic passt? Wieso erstellst du dafür nicht eine neue Readingsgruppe alla "miscellaneous_" oder "misc_" da kann man sowas auch rein machen für exoten und verschiedenes was nirgends passt. Und nicht die statistic_ welche ja auch so sind mal eben in "special_" umbennenen.
Ich kann nur noch einmal sagen. Ich kann das nicht für Gut heißen!

[DS_Starter]

Hallo kask,

Das habe ich mir nicht einfach gemacht. Aber ich habe mir gesagt, einmal den Schmerz muss ich ertragen und dann ist das Thema durch.

Warum nicht extra eine neue Gruppe? Damit es programmtechnisch pflegbar bleibt nicht auseianderläuft.

Abwr warum kommt das erst jetzt? Seit gestern reden wir darüber und du bist ja auch einer der Aktiven Mitstreiter. Ausserdem schreibe ich hier alles haarklein im VORFELD. Niemand wird plötzlich überrumpelt.

Ich mach dir einen Vorschlag ... schau dir in Ruhe an wo du diese Readings benutzt, dann erst mach das Update und pass die Stellen dann
an. Das Präfix special_ passt zukünftig für jeden Sonderfall und ich und jeder Andere hat Ruhe damit.

LG

[kask]

Ja, ich bin schon oft hier. Aber 24h mal nicht gucken kann schon passieren
Ist alles gut. Ich habe daraus ja auch gelernt. Ich loge nichts direkt mehr aus Modulen in Zukunft.
Somit spare ich mir beim ändern der Variabelen der Module das anpassen der Logs.
Die variabelen kann ich mir ja dann umschreiben. Muß ich ja sowieso dann auch.
Denoch großes Danke schön für die Erleuchtung.
Finde es trotzdem Doof. Die statistic Werte waren/sind prädestiniert zumn direkten loggen und jetzt müßen Alle ihre logs umschreiben um wieder einen zusammenhang zu bekommen.
Das ist aber auch alleine meine Meinung.

[DS_Starter]

Die variabelen kann ich mir ja dann umschreiben. Muß ich ja sowieso dann auch.

Der Sinn erschliest sich jetzt mir aber auch nicht. 
Mach dir nicht so viel Arbeit. Eine Änderung von Readingnamen passiert äusserst äusserst selten und auch nur im Rahmen der Entwicklungsarbeit bis alles passt.

[DS_Starter]

Hallo mein lieber kask, ich denke ich kann dir/euch die statistic_ Readings parallel ,sagen wir noch bis Ende des Monats?, erstellen.
Würde das helfen?
Du hattest ja geschrieben dass bei dir momentan viel los ist.

LG

[kask]

Danke für das Angebot. Aber für mich musst du das nicht machen. Ich muss es ja sowieso anpassen über kurz oder lang.
Sondiere gerade für mich wie ich das möglichst schnell bzw. komfortabel anstelle. Wie gesagt, alles gut.

[alf.ele]

Wie jedes Jahr im Januar habe ich ein FHEM Update durchgeführt.
Leider meldet sich SolarForercast als wäre es erstmalig konfiguriert:
Warm welcome!

The next queries will guide you through the basic installation.
If all entries are made, please check the configuration finally with "set SolarModell plantConfiguration check" or by pressing the offered icon.
Please correct any errors and take note of possible hints.
(The display language can be changed with attribute "ctrlLanguage".)

Im Logfile vom Update steht
2025.01.03 18:02:10 3: SolarModell - cached data "pvHistory" restored
2025.01.03 18:02:10 3: SolarModell - cached data "pvCircular" restored
2025.01.03 18:02:10 3: SolarModell - cached data "consumerMaster" restored
2025.01.03 18:02:10 3: SolarModell - cached data "radiationApiData" restored
2025.01.03 18:02:10 3: SolarModell - cached data "aiRawData" restored

Aber es fehlt irgendwie
PVCfg_SolarForecast_

Wenn ich mit "set plantConfiguration restore" versuche die Daten zu laden kommt diese Fehlermeldung:

File is not a perl storable at /usr/lib/arm-linux-gnueabihf/perl/5.28/Storable.pm line 412, at ./FHEM/76_SolarForecast.pm line 19729.

Was kann ich tun, um die Plant wiederherzustellen?

[DS_Starter]

@alf.ele,
dann kommst du aber von einer sehr alten Version.
Im einfachsten Fall die abgefragten Parameter in den Attributen eingeben.
Ansonsten kannst das File PVCfg_SolarForecast_ mit einem Editor öffnen und die Werte übertragen. Das alte File ist normal lesbar. JSON.
Wenn du Unterstüttung brauchst meldest dich bitte wieder.

LG