76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 17 April 2025, 16:37:40

ZitatDann freu dich schonmal wenn ich bald meine 10K Anlage auf dem Dache habe und nicht nur dieses Spielzeug. Dann hab ich bestimmt noch mehr.

Na dann hast du auch viel Spaß um alle Geräte möglichst synchron auszulesen bzw. die FHEM Devices anzuhalten zur gleichen Zeit aktuelle Werte zu liefern damit das Modul sie konsistent zusammenführen kann

... klappt nur bedingt gut. Bei mir klappt am Besten Die Werte per MQTT liefern zu lassen. SMA frage ich mit SMAInverter ab.

87insane · 17 April 2025, 16:46:37

Mir würde es tatsächlich nicht um ms gehen. Man muss bedenken, bei meinem Spielzeug sind das auch noch unterschiedliche Hersteller. Da ist mir klar das es nicht perfekt sein wird. Aber immer noch besser als das was die Hersteller auf den Markt werfen und deren Einstellmöglichkeiten. Die Frage der Genauigkeit der Daten sei auch mal dahingestellt. Könnte jetzt noch sagen, ich habe einen Shelly hinter dem WR, der zeigt nochmal leicht was anderes an. Aber das Thema lassen wir lieber.

Am Ende geht es mir nur darum es vernünftig steuern zu können. Und wenn das 20 Sekunden dauert, wäre das am Ende in der Grafik ggf. nicht mega schön aber an sich würde es seinen Dienst tun.

DS_Starter · 17 April 2025, 16:52:49

@seayak,

Code Auswählen

swoffcond=BYD_Akku:SOC:<100

ist für diesen Fall nicht zu gebrauchen, weil

1.) swoffcond den gesamten geplanten Schaltzyklus des Heizers beendet, aber du wilst ja nur unterbrechen
2.) <100 als Regex falsch ist. Um Werte kleiner 100 zu identifizieren könnte man schreiben: swoffcond=BYD_Akku:SOC:[0-9]{1,2}

Es würde sich tatsächlich interruptable anbieten, aber in der Form Device:Reading:Regex[:Hysterese]. Also könnte der Term so aussehen:

Code Auswählen

interruptable=<Bat-Device>:<SoC-Reading>:[0-9]{1,2}Dann würde der Heizer unterbrochen, wenn kein PV-Überschuß vorhanden ist oder der SOC der Batterie kleiner/gleich 99% beträgt.
Damit sollte deine Steuerung theoretisch

funktionieren.

LG,
Heiko

seayak · 17 April 2025, 17:19:08

Hallo Heiko,

vielen Dank, ein Teilerfolg wurde soeben mit der Regex Definition bei "interruptable" erreicht.

Mit 99% wird unterbrochen, aber sobald danach wieder 100% Bat SOC erreicht werden, werden wieder alle 6 Heizstäbe eingeschaltet, obwohl viel zu wenig PV vom Dach kommt und die Batterie wird wieder entladen.

Womit arbeitet denn die Steuerung? Current_Surplus? Das ist jetzt z.B. positiv und wird jetzt aber zum Beispiel zum Aufladen der Batterie und der Hausverbraucher genutzt. Eine Steuerung, nur basierend auf wirklichem Überschuss, der sonst ins Netz gehen würde, sehe ich als sinnvoller an.

Aktuell "schwingt und toggelt" dann das Szenario, wenn es zur abfallenden PV Leistung am Nachmittag kommt.

Viele Grüße!

Peter

DS_Starter · 17 April 2025, 17:37:17

Hallo Peter,

ja stimmt, das ist eine ODER Verknüpfung. D.h. kein Interrupt wenn PV-Überschuß oder Bat zu 100% voll.

Dein Hinweis bringt micht auf die Idee. Du könntest auch das Reading Current_GridFeedIn auswerten, also:

Code Auswählen

interruptable=<SF-Device>:Current_GridFeedIn:0
Dann wird der Heizer unterbrochen wenn kein PV Überschuß ODER keine Netzeinspeisung vorliegt. Anderherum schaltet der Heizer ein, wenn Netzeinspeisung vorliegt, was ja automatisch einen PV Überschuß bedeuten würde sonst gäbe es keine Einspeisung.

Das Toggeln kann man mit mit der Angabe einer Hysterese bzw. dem locktime-Key verhindern.
Muß jetzt erstmal los ... aber ich denke du weißt wie der Lösungsweg aussehen könnte.

LG,
Heiko

87insane · 18 April 2025, 10:47:42

Ich habe tatsächlich noch was.
Das Balkendiagramm zeigt für morgen 800W für mehrere Stunden an. Aber das ist nicht korrekt.

Es geht von:

Code Auswählen

setupInverterDev01 - noah_mqtt pv=solar_w:W etotal=generation_total_kwh:kWh capacity=800 feed=batcapacity aus.

Nun kann ich aber solange der Akku nicht voll ist, durchaus bis zu 1800W in den Akku jagen. Sobald dieser voll wäre, kann ich nur noch 800W nutzen. Ich kann aber auch Akku laden und gleichzeitig einspeisen.
Die 1800 bekomme ich natürlich wegen der Limitierung meiner Module nicht. Aber das wäre max Akku.
Wenn ich capacity nun auf 1800 stelle, wäre es aber auch wieder falsch. Meine Module schaffen ja maximal 1300. Wenn ich es nun auf 1300 stelle wäre das natürlich niemals erreichbar, denn ich lebe ja nicht im Labor. Also stelle ich es mal auf 1100. Das ist real erreichbar.

Das Modul an sich weiß, wann der Akku voll ist bzw. nicht mehr lädt. Sollte ja in der Theorie möglich sein, das ggf. noch irgendwie anzupassen. Sollte das noch nicht gehen, wäre meine Vorhersage bei dieser Anlage, mit gutem Wetter quasi immer falsch und somit unnütz.

Ich hoffe man hat verstanden was ich meine. Es fällt mir etwas schwer das zu erklären.

300P · 18 April 2025, 11:17:51

Guten Morgen!

du must deine Batterie evtl. genauer einstellen.

Schau Dir mal meine Batterie an:

Code Auswählen

SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@white asynchron=0
SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@blue asynchron=0

Meine WR könnten auch maximal 9500 Watt in die BWR schicken
Meine Batterien (2) können aber nur:
SBS25 2500 Watt max rein oder raus
SBS37 3680 Watt max rein oder raus

(Alle WR sind mit ihren Nennwerten eingerichtet)

Gruß + bin jetzt weg zum Fischessen.....

300P

DS_Starter · 18 April 2025, 11:23:09

Moin,

ZitatNun kann ich aber solange der Akku nicht voll ist, durchaus bis zu 1800W in den Akku jagen.

Ja, deshalb schrieb ich ja weiter vorn dass capacity=1800 hier richtig wäre damit kein Beschneiden bei 800 Wh vorgenommen wird.

ZitatWenn ich capacity nun auf 1800 stelle, wäre es aber auch wieder falsch. Meine Module schaffen ja maximal 1300.

Die max. Leistung der Module stellst du ja im Attr setupStringPeak ein. Damit ist für das Modul alles klar. Mehr musst du nicht tun, der Rest passiert intern.

@300P, guten Appetit!

LG,
Heiko

Shadow3561 · 18 April 2025, 11:29:02

Moin,
Habe heute die neueste Version eingespielt.
Leider erschliesst sich mir die

Code Auswählen

graphicBeam3Content
batsocforecast_01

nicht so ganz.

Code Auswählen

ctrlNextHoursSoCForecastReadings
00,01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22,23

Wenn der SocForecast über der ersten Balkengrafik ist, stimmt alles

Es endet immer mit der aktuellen Stunde. Anbei ein Bild.

Schönes Osterwochenende allen Mitlesenden

DS_Starter · 18 April 2025, 11:34:11

Hallo Shadow3561,

das liegt einfach daran dass die beiden Ebenen zeitlich nicht synchronisiert sind.
Die Ebene 1 zeigt keine Nachtstunden, die Ebene 2 zeigt sie an.

Die Synchronisation kann man mit Attr graphicShowNight=01 herstellen.

LG

Shadow3561 · 18 April 2025, 11:35:57

Danke,
darauf muss man erst mal kommen.

Schönes langes WE

DS_Starter · 18 April 2025, 12:06:45

@87insane,

ich habe nochmal nachgedacht. Eigentlich hast du eine variable, vom Ladezustand abhängige WR-Kapazität.
Bei den Batterien habe ich diese Variable cap-Möglichkeit bereits ein gebaut. Bei deinem WR bräuchtest su das auch um die capa dynamisch (über ein Reading) gemäß des Bat-Ladezustandes einzustellen.

Siehst du das auch so?

LG

87insane · 18 April 2025, 12:44:28

Zitat von: 300P am 18 April 2025, 11:17:51Guten Morgen!

du must deine Batterie evtl. genauer einstellen.

Schau Dir mal meine Batterie an:

Code Auswählen Erweitern
SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@white asynchron=0 SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap show=3:top icon=@yellow:@green:@red:@blue asynchron=0
Meine WR könnten auch maximal 9500 Watt in die BWR schicken
Meine Batterien (2) können aber nur:
SBS25 2500 Watt max rein oder raus
SBS37 3680 Watt max rein oder raus

(Alle WR sind mit ihren Nennwerten eingerichtet)

Gruß + bin jetzt weg zum Fischessen.....
300P

Das verstehe ich nicht ganz. Denn in meinen Augen ist das schon genauso eingestellt wie es sein muss. Du hast eigentlich auch nur eine Sache anders. Das wäre Laden - Entladen in pin. Aber das ist bei mir nicht richtig.
Der Speicher kann 1800W aufnehmen. Die Module würden im Labor 1300W liefern können. Der Speicher kann laden und entladen gleichzeitig. Maximaler Ausgang ist 800W Richtung WR. Ggf. verstehe ich das auch nicht, wie du das genau meinst.

Zitat@87insane,

ich habe nochmal nachgedacht. Eigentlich hast du eine variable, vom Ladezustand abhängige WR-Kapazität.
Bei den Batterien habe ich diese Variable cap-Möglichkeit bereits ein gebaut. Bei deinem WR bräuchtest su das auch um die capa dynamisch (über ein Reading) gemäß des Bat-Ladezustandes einzustellen.

Siehst du das auch so?

Und das verstehe ich leider garnicht.
Ich habe den Shelly Pro3em noch nicht im Stromkasten. Daher habe ich in die Richtung keine genaue Steuerung. Mein Grundrauschen sind ca. 400W. Das stelle ich also so im Speicher ein. Nun schiebt er 400W rauß und lädt zusätzlich was an Überschuss kommt.
Die Maximal 800W, die ich rauß geben kann, stehen ja in poutmax der Battery. Also dachte ich, wären eigentlich alle Werte da.
Laut Beschreibung passt capacity nur nicht zu dem was bei mir eigentlich passiert. Die Beschreibung verweist bei diesem Wert auf Ausgangsleistung.

Ggf. sollte ich auch erstmal ein wenig Wochenende machen. Ich danke aber erst nochmal für das Modul. Das ist ein sehr mächtiges Teil und es macht Spaß hier ein wenig zu fachsimpeln.

DS_Starter · 18 April 2025, 14:34:04

@87insane,

wir denken vermutlich auf verschiedenen Ebenen und Zusammenhängen, ist nicht so einfach.
Deswegen nur nochmal kurz zur Erläuterung.
Die Angabe capacity im Attr setupInverterDev01 hat in erster Linie die Aufgabe die max. mögliche PV-Leistung für die Prognose zu begrenzen. Oft sind die Peak-Leistungen der PV-Module höher als die angeschlossene WR-Leistung bzw. kommt es vor, dass die KI / korrigierte API-Prognose über der max. WR-Leistung liegt. In diesen Fällen wird die Prognose auf die angegebene capacity gekappt.

D.h. der Schlüssel müsste bei dir m.M. nach capacity=1800 lauten. Nehmen wir an die Batterie ist nicht voll und es ist volle Sonne prognostiziert. Dann würden deine Module die volle Leistung von 1300W leisten können, die sich auch in der Balken-Vorhersage niederschlägt. Die Leistung wird nicht begrenzt, da kleiner capacity=1800.

Und nehmen wir an, es ist volle Sonne und der Backofen ist an. Dann würde der WR nach meinem Verständnis max. 800W an das Hausnetz liefern und die restlich erzeugte PV-Leistung von 500W (1300W - 800W) in die Batterie schieben. -> keine Begrenzung wäre nötig

Anders ist es aber wenn volle Sonne scheint, die Batterie aber schon voll ist!
Dann würde der WR 800W an das Hausnetz liefern, aber die theoretisch verbleibenden 500W PV nicht mehr als Batterieladung nutzen könen, d.h. die PV-Anlage würde abregeln.
In diesem Fall, wenn es einen längeren Zeitraum betrifft, muß auch die Prognose PV-Leistung auf 800Wh begrenzt werden weil der WR ja seine eigentlichen 1800W nicht mehr ausspielen kann.

Das meinte ich mit dynamischer Anpassung der WR-capacity. Es beeinflusst in erster Linie die PV-Prognose für ein stimmiges Bild.

Deine Einstellung in der Batterie

Code Auswählen

setupBatteryDev01 - pinmax=1800 poutmax=800
haben insbesondere auf die SoC-Prognose Einfluß.

Ich hoffe ich habe keinen Denkfehler, aber so müßte sich deine Anlage m.M. nach verhalten nach allem was ich gelesen habe.

schöne Ostern!
LG

Hackstall · 18 April 2025, 17:19:42

Sorry aber ich habe immer noch das Problem mit:

Code Auswählen

2025.04.18 17:15:50.259 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '

conForecastTillNextSunrise' has no Parameter or default value set. Set the attribute again or inform Maintainer.

Der Parameter ist in attr gesetzt:

Code Auswählen

ctrlSpecialReadings includes
	

BatPowerIn_Sum,BatPowerOut_Sum,SunHours_Remain,SunMinutes_Remain,allStringsFullfilled,
conForecastTillNextSunrise,currentAPIinterval,currentRunMtsConsumer_01,currentRunMtsConsumer_02,currentRunMtsConsumer_03,
currentRunMtsConsumer_04,currentRunMtsConsumer_05,currentRunMtsConsumer_06,currentRunMtsConsumer_07,dayAfterTomorrowPVforecast,
daysUntilBatteryCare_01,daysUntilBatteryCare_02,lastretrieval_time,lastretrieval_timestamp,response_message,
runTimeAvgDayConsumer_01,runTimeAvgDayConsumer_02,runTimeAvgDayConsumer_03,runTimeAvgDayConsumer_04,
runTimeAvgDayConsumer_05,runTimeAvgDayConsumer_06,runTimeAvgDayConsumer_07,runTimeCentralTask,runTimeLastAPIAnswer,
runTimeLastAPIProc,runTimeTrainAI,todayBatIn_01,todayBatIn_02,todayBatOut_01,todayBatOut_02,todayConForecastTillSunset,
todayConsumptionForecast,todayDoneAPIcalls,todayDoneAPIrequests,todayGridConsumption,todayGridFeedIn,todayMaxAPIcalls,
todayRemainingAPIcalls,todayRemainingAPIrequests,conForecastTillNextSunrise

Was kann ich tun damit der FEhler nicht mehr erscheint.
Das Forecast Modul scheint sonst einwandfrei zu funktionieren.