76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Moin,

das Modul kann man durchaus schon laufen lassen. Bei solchen Gegebenheiten wie bei dir wird bei sonnigen Tagen eine größere Differenz zwischen Prognose und realer Erzeugung auftreten sofern die Erzeugung gedrosselt/vermieden wird damit keine Einspeisung erfolgt.
Bei meiner Anlage gibt es auch einen Teil der nicht einspeist. Durch gewisse Optimierung bei der Batterieladung kann ich bei mir den Fehler minimieren, ansonsten muß ich damit leben da ich im Vorfeld nicht weiß wann eine Abregelung erfolgt und wieviel. Vllt. fällt mir dazu noch etwas zündendes ein.
Bei dir würde ich raten mit

 

Code Auswählen Erweitern

set ... pvCorrectionFactor_Auto noLearning
den Lernmodus auszuschalten solange eine Abregelung möglich ist. Damit würden die (falschen) Erkenntnisse aus dem Lernprozess ausgeschlossen wenn du später den gewünschten Wert für pvCorrectionFactor_Auto  einstellst wenn alles normal läuft.
Die Prognose an sich wird dadurch nicht beeinflusst, sie richtet sich nach der gewählten API.

[kask]

@Mr.X

Erstmal "Hallo" und viel Spass mit der neuen Anlage und dem spannenden Vorhersagen.

Ob du limitiert einspeist ist dem Modul völlig egal.
Du brauchst mindestens 2 Messeinrichtungen um das Modul nutzen zu können. Ein Messmittel am Netzeingang und eines für deine PV-Leistung (meist Daten aus dem Wechselrichter).
Und dann kann es losgehen.

Ich denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden. Klar ist die Vorhersage nicht so gut wie ohne. Aber brauchbar anpassen sollte sich das schon lassen könnte ich mir Vorstellen.
Zudem kommt bei wechselnden Lasten über den Tag noch eine weitere Unsicherheit rein. Sofern du aber einen einigermassen geregelten Verbrauch hast sollte es auch so einigermassen funktionieren. Dauert halt etwas länger der Lernprozess.

@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.

[DS_Starter]

Ich denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden.

Doch, der Meinung von kask bin auch . Nur für den Anfang würde ich es so machen.

@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.

Das liest sich ganz gut. Allerdings fehlt da noch die Batterie(lade)komponente. Sie geht im Moment des Ladens nicht in der Verbrauch und damit Consumptionforecast ein, vermindert/verhindert aber ein Herunterregeln der Anlage.
Aber der Ansatz an sich sieht nicht so schlecht aus.
Wenn ich mit meinen Umstellungen durch bin können wir das ja nochmal genauer betrachten und testen.

[kask]

Ich habe eine andere Ladephilosophie wie du.
Was aber für beide Strategien funktionieren sollte wäre folgendes.

Wie wäre es mit einer weiteren Prognose? Die "BatteryUse" anhand der Vergangenheit (Laden.-Endladen).
Ähnlich wie der Consumptionforecast, die wäre allerdings positiv sowie negativ.
Damit könntest du den Limiter(PV-Capacity) auf Consumptionforecast + Gridlimit + BatterieUseforecast einpegeln. Nur so als Gedankengang.

[DS_Starter]

Behalten wir mal im Hinterkopf. Wenn ich den Kopf wieder frei habe, holen wir die ganzen Ansätze und Gedanken nochmal raus. Kannst bis dahin gerne noch etwas sinnieren.
Dauert noch ein bisschen bis ich die ganzen Changes durch habe. Muß mich dabei ziemlich konzentrieren um alles sauber umzusetzen.

[DS_Starter]

Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen ...

Gut das wir darüber gesprochen haben. Unter diesem Aspekt lasse ich nämlich die Setter modulePeakString, moduleAzimuth und moduleDeclination als Konfigurations-Readings bestehen. moduleAzimuth und moduleDeclination unter dem Gesichtspunkt dass es Nachführanlagen gibt die sich dem Sonnenstand entsprechend ausrichten.

[DS_Starter]

@all,
die Umsetzung von Konfigurations-Setter in Attribute ist weiter fortgeschritten.

Umgesetzt ist jetzt currentBatteryDev in attr setupBatteryDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.

WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.

Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.

LG,
Heiko

[Mr.X]

Danke für euren Input.

Das Modul lief heute schon mal, und da es zunächst doch ziemlich bewölkt war, ist die Batterie erst jetzt gerade kurz vor voll, d.h. bisher keine Abregelung (für morgen ist die Prognose nicht besser, aber die Batterie wird morgen Früh nicht leer sein, d.h. denke da läuft es in die Abregelung, Dienstag dann spätestens laut Wetterbericht). Die größte Unsicherheit scheinen da tatsächlich die Wetterdaten (Bewölkung) zu sein, während ich am Vormittag der Prognose deutlich hinterher war, hab ich am frühen Nachmittag als die Sonne raus kam deutlich aufgeholt- über den Tag sieht es im Moment gar nicht so schlecht aus. Allerdings sind natürlich die Korrekturfaktoren die er da jetzt für morgen annimmt auch nicht realistisch, wenn da nicht wieder genau die Sonne rauskommt, aber ich denke verstanden zu haben, dass sich das dann mit der Zeit alles nivelliert und dass das System eben lernt...

@kask: Die notwendigen Messdaten hab ich alle die das Modul haben will, auch die optionalen, habe ich alles angelegt und sollte passen.

Ich mag die graphische Darstellung des Moduls - toll gemacht.

Bin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht... Mit einem "Reset" könnte ich aber nach dem Wegfall der Einspeisebeschränkung ja ohne Probleme wieder von vorne anfangen das System zu trainieren. ISt vermutlich dann der bessere Weg, als alles was er bis dahin gelernt hat dann nach und nach in Richtung der realistischeren Werte zu bewegen. Beim Nachbarn hat es 3 Monate gedauert bis die Stadtwerke den neuen Zähler eingebaut haben, d.h. da muss man vermutlich lange neue Daten füttern, bis es dann passt (daher wäre im Moment meine Tendenz im Moment laufen lassen und dann einen Reset zu machen...)

Nächstes WE kümmer ich mich dann mal um die "Consumer".

Vielen Dank für das Modul

[kask]

Bin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht.

Welche API nimmst du? Je nach API kannst du dir einfach die Rawdefinition des vorhandenen SolarForecast device kopieren und das device umbenennen.
Dazu die korrespondierenden files in /opt/fhem/FHEM/FhemUtils/ mit dem abgeänderten neuen devicenamen kopieren.
Und dann beide Instancen parallel laufen lassen. Einmal ohne einmal mit autocorrection.
Dann kannst du entscheiden was besser passt bei dir.

[Mr.X]

Das mit der API ist noch ein guter Punkt wo man (ich zumindest) als Anfänger nicht so recht weiß, hab ich keine Empfehlung gefunden. Sind die alle gleichwertig? Ich hab einfach mal OpenMeteoDWD genommen- weil es hier bei mir in der Nähe eine Messstation gibt die die Rad1h Werte zur Verfügung stellt...

[kask]

Nunja, alle gleich!? Kann man sehen wie man will. Die einen funktionieren die anderen auch, nur nicht immer und bei jedem.
Das mußt du für dich rausfinden was am besten bei dir funktioniert, sofern du die API überhaupt nutzen kannst.
Die einen sind frei die anderen brauchen einen Account.
Eine brauch auch bestimmte Hardware damit diese geht (VictronVRM).

Ich denke OpenMeteoDWD ist schon ein guter start. Da auch mal die OpenMeteoEnsemble testen.
Für die SolCastAPI  brauchst du bekanntlich einen Acccount da bekommst du max 10 Abfrage am Tag jetzt nur noch. Bei mehrerern Strings reduziert sich das ganze naürlich dann.
Die VictronVRM läuft wohl auch mit der SolCastAPI bzw. nutzt diese Angaben. Ich habe da denoch manchmal große Unterschiede.
Die DWD kann auch ganz brauchbar sein. Vermutlich liefert die dir auch Rad1H Werte da OpenMeteoDWD auch darauf abfeuert.
Bei mir bringen diese auch unterschiedliche Vorhersagen. Die Differenz beider zueinander ist nicht so groß. Aber vorhanden.
Die OpenMeteoWorld liefert bei mir 99% das gleiche Wie die OpenMeteoDWD. Vieleicht ist es bei dir anders.
Mit der ForecastSolarAPI bin ich so garnicht zufrieden. Musst du mal testen ob es bei dir vieleicht brauchbar ist.

Das Ranking bei mir/für mich ist:
sehr gut: SolCastAPI (mehrere Strings, Aber 2x50 Abfragen weil alte accounts. Wichtig ist die rooftops bei Solcast selbst richtig zu parametrieren!)
gut: OpenMeteoEnsemble
gut aber etwas schlechter: VictronVRM,DWD & restlichen OpenMeteo's
Reinfall: ForecastSolarAPI

Jetzt ist es auch so das bei unbeständigem Wetter bei mir die DWD-basierten besser treffen.
Das ist alles nicht so einfach

Ich habe alle API's parallel laufen und bastel mir einen Wert aus allen API's dividiert durch die Anzahl.
Dadurch habe ich im ganzen eine genauere Prognose.
Man darf nicht vergessen das diese Prognose auch DWD lastig ist, da 3 (DWD, OpenMeteoDWD, OpenMeteoWorld) der 6 (eigentlich 7 aber die ForecastSolarAPI verwurste ich da nicht mit) API's ziemlich identische Werte liefern. Was bei mir anscheinend sehr gut am Ende passt.

[DS_Starter]

@all,
ein weiterer Schritt ist vorgenommen.

Umgesetzt ist jetzt currentInverterDev in attr setupInverterDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.

WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Außerdem wird nach dem Update der Start der Autokorrektur technisch bedingt um 2h verzögert in der Grafik angezeigt. Das ist in dem Fall normal und kein Grund zur Beunruhigung. Nach 2h wird der Prozeß normal fortgesetzt.

Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.

[texel]

Hallo zusammen,

brauche eure Hilfe, aus irgendeinem Grund wird bei mir der Consumer01 nicht mehr eingeplant:

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Die Uhr bleibt grau - wenn ich draufklicke, wird der Verbraucher sofort eingeplant - aber das sollte doch automatisch passieren?

Hier meine Config:

Code Auswählen Erweitern

defmod solarforecast SolarForecast
attr solarforecast consumer01 MQTT2_poolpump interruptable=1 auto=automatic icon=sani_garden_pump@blue  mintime=SunPath type=other power=600 locktime=60:600 on=on off=off pcurr=ENERGY_Power_1:W etotal=ENERGY_Total:kWh
attr solarforecast consumer02 modbus_pool_heatpump interruptable=1 auto=automatic icon=sani_heating_heatpump@blue type=other mintime=SunPath power=1200 locktime=0:600 on="c000-power 1" off="c000-power 0" swstate=c000-power:1:0 pcurr=ENERGY_Power:W
attr solarforecast ctrlWeatherDev1 OpenMeteoDWD-API
attr solarforecast ctrlWeatherDev2 DWD


Code Auswählen Erweitern

Current_AutarkyRate    100 %
Current_Consumption    259 W
Current_GridConsumption    0 W
Current_GridFeedIn    773 W
Current_PV    1032 W
Current_SelfConsumption    259 W
Current_SelfConsumptionRate    25 %
Current_Surplus    773 W
LastHourGridconsumptionReal    119 Wh
LastHourPVforecast    348 Wh
LastHourPVreal    310 Wh
NextHours_Sum01_PVforecast    2225 Wh
NextHours_Sum02_PVforecast    5759 Wh
NextHours_Sum03_PVforecast    10192 Wh
NextHours_Sum04_ConsumptionForecast    4906 Wh
NextHours_Sum04_PVforecast    15076 Wh
RestOfDayConsumptionForecast    223341 Wh
RestOfDayPVforecast    43484 Wh
Today_Hour01_GridConsumption    563 Wh
Today_Hour01_GridFeedIn    0 Wh
Today_Hour01_PVreal    0 Wh
Today_Hour02_GridConsumption    337 Wh
Today_Hour02_GridFeedIn    0 Wh
Today_Hour02_PVreal    0 Wh
Today_Hour03_GridConsumption    275 Wh
Today_Hour03_GridFeedIn    0 Wh
Today_Hour03_PVreal    10 Wh
Today_Hour04_GridConsumption    345 Wh
Today_Hour04_GridFeedIn    0 Wh
Today_Hour04_PVreal    0 Wh
Today_Hour05_GridConsumption    317 Wh
Today_Hour05_GridFeedIn    0 Wh
Today_Hour05_PVreal    10 Wh
Today_Hour06_GridConsumption    289 Wh
Today_Hour06_GridFeedIn    0 Wh
Today_Hour06_PVforecast    60 Wh
Today_Hour06_PVreal    50 Wh
Today_Hour07_GridConsumption    119 Wh
Today_Hour07_GridFeedIn    80 Wh
Today_Hour07_PVforecast    348 Wh
Today_Hour07_PVreal    310 Wh
Today_Hour08_GridConsumption    0 Wh
Today_Hour08_GridFeedIn    421 Wh
Today_Hour08_PVforecast    1125 Wh
Today_Hour08_PVreal    660 Wh
Today_Hour09_PVforecast    2530 Wh
Today_Hour10_PVforecast    3811 Wh
Today_Hour11_PVforecast    4605 Wh
Today_Hour12_PVforecast    4962 Wh
Today_Hour13_PVforecast    4806 Wh
Today_Hour14_PVforecast    5265 Wh
Today_Hour15_PVforecast    5125 Wh
Today_Hour16_PVforecast    4128 Wh
Today_Hour17_PVforecast    3689 Wh
Today_Hour18_PVforecast    2402 Wh
Today_Hour19_PVforecast    1355 Wh
Today_Hour20_PVforecast    456 Wh
Today_Hour21_PVforecast    107 Wh
Today_MaxPVforecast    5265 Wh
Today_MaxPVforecastTime    2024-06-05 13:00:00
Today_PVforecast    44774 Wh
Today_PVreal    1040 Wh
Today_SunRise    05:15
Today_SunSet    21:09
Tomorrow_ConsumptionForecast    214946 Wh
Tomorrow_PVforecast    42830 Wh
Tomorrow_SunRise    05:14
Tomorrow_SunSet    21:10
consumer01    name='MQTT2_poolpump' state='unknown' mode='can' planningstate='stopping'
consumer01_currentPower    0 W
consumer01_planned_start    04.06.2024 14:04:35
consumer01_planned_stop    04.06.2024 21:08:00
consumer02    name='modbus_pool_heatpump' state='off' mode='can' planningstate='planned'
consumer02_currentPower    7 W
consumer02_planned_start    05.06.2024 07:45:05
consumer02_planned_stop    05.06.2024 23:39:05
currentInverterDev    modbus_solarcounter pv=Power_Total:W etotal=kWh_Total:kWh capacity=7960
currentMeterDev    MQTT2_esp8266_0811E8 gcon=Aktuelle_Momentanwirkleistung:W contotal=Zaehlwerk_positive_Wirkenergie:Wh gfeedin=-gcon feedtotal=1-0_2-8-0_255_value:Wh conprice=0.225:€ feedprice=0.082:€
currentRadiationAPI    OpenMeteoDWD-API
inverterStrings    main
moduleAzimuth    main=-30
moduleDeclination    main=15
modulePeakString    main=8
nextCycletime    07:47:25
nextRadiationAPICall    nach 05.06.2024 08:01:16
state    wrote cachefile solcastapi successfully
Bin für jeden Tipp dankbar.

LG Texel

[DS_Starter]

Moin texel,

der Status des Consumer01 ist "unknown":

Code Auswählen Erweitern

consumer01    name='MQTT2_poolpump' state='unknown'

Bedeutet, das Modul erkennt den state von MQTT2_poolpump nicht. Da der Key swstate nicht gesetzt ist, zieht der default state=on oder state=off zur Erkennung. Das matched nicht mit dem tatsächlichen Inhalt des Readings "state" von MQTT2_poolpump.
Das müsstest überprüfen und ggf. anpassen bzw. den Fehler im state von MQTT2_poolpump beseitigen.

[texel]

Moin, danke für die schnelle Antwort. Das ist seltsam, weil das MQTT device als readiung "state" enthält und auch on/off entsrpechend einträgt .. aber ich habs trotzdem beim Consumer01 ergänzt:

Code Auswählen Erweitern

MQTT2_poolpump interruptable=1 auto=automatic icon=sani_garden_pump@blue mintime=SunPath type=other power=600 locktime=60:600 on=on off=off swstate=state:on:off pcurr=ENERGY_Power_1:W etotal=ENERGY_Total:kWh
Die Uhr war nach dem speichern immer noch "grau". Gibt es eine Möglichkeit einen "refresh" zu machen, so dass alles neu berechnet wird für den Tag und dann hoffentlich auch die Uhr auf gelb geht?

Lieben Dank! Texel