76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Musste selbst erstmal nachschauen ...

$pvre / $pvfc  , also  PV-real / PV-Forecast

Edit:

Ich messe seit 2007 mit einem geeichten Sensor die Einstrahlung in meine erste PV-Anlage und kann das also sehr gut vergleichen

Sind deine Messungen vergleichbar mit dem Rad1h des DWD?


LG

[Prof. Dr. Peter Henning]

Sind deine Messungen vergleichbar mit dem Rad1h des DWD?

Noch nicht, bisher nur perspektivisch. Der Sensor ist direktional, parallel zu den Modulen meiner alten PV-Anlage.
Rad1h ist die Globalstrahlung, also omnidirektional auf einer horizontalen Fläche.

Nötig ist also ein Modell - und da hoffe ich zu etwas zu kommen, das man für jeden Standort und jede Anlage anpassen kann, ohne auf den "Flächenfaktor" für München zurückgreifen zu müssen. Dann kann ich das eben mit den Messwerten sehr gut vergleichen.

LG

pah

[300P]

Guten Morgen,

ich habe gestern Abend mal meine 3 WR einzeln in einem gleichartigen SF-Test aufgebaut.
Bei der Kontrolle ist mir etwas aufgefallen:
Habe einen Punkt gefunden der evtl. nicht ganz sauber ist.(oder von mir etwas nicht eingerichtet worden ist)

Hier ein Auszug aus den attr:

Code Auswählen Erweitern

attr Forecast_Test setupBatteryDev BatteryDummy pin=-pout:kW pout=total_pac:kW intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=19600
attr Forecast_Test setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings:GarageSE
attr Forecast_Test setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings:GarageNW,HausNW
attr Forecast_Test setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings:HausSE1,HausSE2,HausSW
attr Forecast_Test setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast_Test setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast_Test setupOtherProducer01 icon=Heizung_FCU_green@red MB_USRW610_004 pcurr=Power_L1__W:W etotal=Energy_L1_import__kWh:kWh
attr Forecast_Test setupRadiationAPI DWD
attr Forecast_Test setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.1 HausSE2=2.1
attr Forecast_Test setupWeatherDev1 DWD
attr Forecast_Test stateFormat Current_PV
attr Forecast_Test verbose 2



Jetzt der evtl. Fehler den ich meine bei "get valInverter":
(oder mein Einrichtungsfehler ??)

 

Code Auswählen Erweitern

01 => ialias => SB25
      ietotal => 14483419
      ifeed => default
      igeneration => 1633
      ilimit => 100
      iname => SB25
      invertercap => 2500

02 => ialias => SB30
      ietotal => 6658965
      ifeed => default
      igeneration => 221
      ilimit => 100
      iname => SB30
      invertercap => 3000

03 => ialias => SB40
      ietotal => 6423395
      ifeed => default
      igeneration => 318
      ilimit => 100
      iname => SB40
      invertercap => 4000

Da fehlt der zugeordnete String zu den WRs  - oder liege ich falsch (siehe auch Screenshot)

Danke für eine Aufklärung 🤩

Gruß
300P

[DS_Starter]

Moin,

da ist ein Eigabefehler:

strings:GarageSE   ->   strings=GarageSE

Die andere setupInverterDev natürlich auch. 😉

Lg

[300P]

Ohne Worte 
      
🦯🦯🦯🦯🦯
🦮🦮🦮🦮🦮
👨�🦯👨�🦯👨�🦯👨�🦯👨�🦯

🤦🤦🤦🤦🤦

Danke !
Und schönen Sonntag

[fichtennadel]

Wäre es möglich setupWeatherDev1 und setupRadiationAPI auch beim Open-Meteo API zu trennen?

Meine nächste DWD Station (bin in Österreich) ist recht weit entfernt und OpenMeteoDWD-API liefert über das ICON-D2 Modell wesentlich bessere Vorrausagen für meinen Standort.
Andererseits habe ich die Werte aus der SolCast-API jetzt ein Jahr lang beobachtet und die liefert im Schnitt die besseren Werte für die Strahlung.

Konkret würde ich also gerne setupRadiationAPI=SolCast-API und setupWeatherDev1=OpenMeteoDWD-API einstellen können, damit das Wetter vom Open-Meteo kommt (für die Anzeige und die Korrekturfaktoren) und die Rohdaten für die Strahlungsprognosewert von SolCast.

[DS_Starter]

Das muss ich mir erstmal genauer anschauen wenn die Entwicklung weitergeht.
Problematisch dabei ist das Management beider verschiedener APIs gleichzeitig bezüglich ihrer jeweiligen Abrufbeschränkungen und der Berechnung der API Zyklen.

LG

[TheTrumpeter]

Als weitere Schritte habe ich vor, mich des Themas flexible Strompreise anzunehmen und eine Integrationsmöglichkeit zu schaffen.
Auch diese Sachverhalte sollen sich nahtlos in Logikentscheidungen einfügen.

Darauf bin ich schon gespannt. Mittlerweile helfe ich mir nur mit dem Abschalten einzelner unkritischer Verbraucher beim Überschreiten einer vordefinierten Schwelle sowie Push-Benachrichtigung beim Unterschreiten von 2 vordefinierten Schwellen ("Bezug günstiger als Einspeisevergütung" sowie "Bezugspreis negativ").

[fichtennadel]

Das muss ich mir erstmal genauer anschauen wenn die Entwicklung weitergeht.

Heute habe ich wieder den Fall, dass die Prognose von DWD den ganzen Tag für mich komplett daneben liegt, aber für die Wetterstation korrekt wäre: bei mir Sonne, aber vorhergesagt und korrekt an der Station Hochnebel.
Damit sind complex(_ai) Korrekturen leider sinnlos.

Problematisch dabei ist das Management beider verschiedener APIs gleichzeitig bezüglich ihrer jeweiligen Abrufbeschränkungen und der Berechnung der API Zyklen.

Wär's nicht ohnehin schöner, die OpenMeteo Wetterprognose in ein eigenes Devices auszulagern, so wie beim DWD? Dann kann dort der API Zyklus gemanaged werden, unabhängig von der Radiation Quelle.

[kask]

Wär's nicht ohnehin schöner, die OpenMeteo Wetterprognose in ein eigenes Devices auszulagern

Mit Modularisierung brauchst du DS_Starter nicht kommen, das ist "bah"

[DS_Starter]

Nö ist nicht bäh.
Nur wer soll einzelne Module erstellen und ständig einzeln und im Zusammenspiel pflegen?
Ich? Das würde meinen Zeitfond übersteigen. Es ist im Hinblick auf die sonstigen Module die ich betreue bereits jetzt schon grenzwertig.
Aber wenn jemand mitmacht, warum nicht.


LG

[Prof. Dr. Peter Henning]

Ich habe volles Verständnis dafür, dass man nicht beliebig viel Zeit in FHEM investieren kann. Aus genau dem Grund habe ich das Shelly-Modul abgegeben, alle anderen von mir betreuten sind weitgehend stabil.

Allerdings bin ich auch für eine Trennung der Funktionalitäten:
- Vorhersage
- Management
- Visualisierung

Vor allem sind kleinere Module leichter zu pflegen, und es finden sich deshalb auch eher weitere Mitstreiter.

Wichtig wäre deshalb, Standards zu definieren. So dass eben nicht das "Zusammenspiel" ebenfalls leidet, wenn man an einem der Module etwas ändert.

LG

pah

P.S.: Und ja: Es ist ein wenig schmerzhaft, wenn die eigene Arbeit von anderen übernommen wird - und vielleicht ganz anders weiter entwickelt wird, als man es selbst getan hätte. Sehe ich gerade nicht nur in FHEM, sondern auch in meiner Forschung. Aber so ist der Lauf der Dinge, und das muss man akzeptieren.

[DS_Starter]

Nun, das SF-Modul kann die Daten an eine eigene/externe Visualisierung liefern sofern jemand eine externe Visualisierungslösung erstellen möchte, oder einen anderen Datenkonsumenten.
Sollte jemand ein OpenMeteo Modul entwickeln, kann ich es ebenso wie das DWD einbinden. Wenn sich der Entwickler an die Struktur des OpenDwd hält, wäre der Standard schon geschaffen. Aber man sieht ja schon beim DWD Modul ... die Weiterentwicklung mit der jeder happy ist liegt mittlerweile schon 9 Monate im contrib und findet keinen Weg ins Repo. Hmm...

Also wennn jemand diesbezüglich Ambitionen hat ein OpenMeteo Modul zu bauen, kann er sich ja gern melden. Da ist doch nichts dagegen zu sagen und ich bin der letzte der sich weigern würde ein solchen Datenlieferanten einzubinden.

Bisher hatte ich allerdings nur den Eindruck _ich_ soll doch die Archtektur umbauen und _ich_ soll alles auseinanderpflücken und weitere Module bauen.
Genau das werde _ich_ nicht tun, zuviel Lebenszeit wird dadurch geopfert ohne einen sachlichen Zwang der dies jetzt unbedingt benötigt.

BTW... für das gewünschte Anliegen ist mir vermutlich bereits ein gangbarer Weg im Kopf.
Falls das noch gewünscht sein sollte.
 

LG

[fichtennadel]

Also wennn jemand diesbezüglich Ambitionen hat ein OpenMeteo Modul zu bauen, kann er sich ja gern melden.

Ich kann mich ja mal daran versuchen, aber ich bin eher der perl-Bastler/Fixer denn Experte.
Ich bräuchte dazu dann noch etwas Input, was die Schnittstelle bzw. die erwarteten Readings für SF sind.
Gibt's bei Dir zum Thema OpemMeteo noch weitere Quellen als das SF Modul, die ich mir ansehen kann?
Gerne dann PM, damit wir hier den Thread nicht damit kapern (oder vielleicht ein eigener Thread für ein OM Modul?).

BTW... für das gewünschte Anliegen ist mir vermutlich bereits ein gangbarer Weg im Kopf.
Falls das noch gewünscht sein sollte.

Ja, bitte

LG

[DS_Starter]

Hallo fichtennadel,

habe dir eine PM geschrieben.
Die Umsetzung meines Ansatzes gehe ich an wenn ich wieder "im Dienst" bin.

LG,
Heiko