Mit folgendem wget in der Fhem Kommandozeile bekommt man Heikos aktuellste Version
"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
Meine Implementierung steht mit Beschreibung im Wiki
Wetter- / Leistungs-Prognose==========================================================================================
Ich habe übrigens bei mir noch eine Verschiebung der Werte vom DWD um 1 Stunde eingebaut, dadurch passten die Werte besser mit der Realität überein.
Da fällt mir gerade ein, dass ich das auch noch in die *_config reinbauen wollte, gut dass wir drüber gesprochen haben.
==========================================================================================
nur für den Solarforecast extra ein SQL Datenbank anzulegen, begeistert mich wenig
das Modul arbeitet ohne DbLog.
Nur meine Implementierung verwendet DbLog, um bereits heute die Kurve für morgen einzutragen.
Ich überlege jedoch, ob ich auch die readings für fc[0|1] einfach mit ins Device schreibe, damit man es ohne DbLog verwenden kann, dann ist es halt nicht mehr so schön ;-)
EDIT: Das sähe dann so aus
Solar_Calculation_fc0_10 662 2021-01-21 17:32:43
Solar_Calculation_fc0_11 692 2021-01-21 17:32:43
Solar_Calculation_fc0_12 639 2021-01-21 17:32:43
Solar_Calculation_fc0_13 837 2021-01-21 17:32:43
Solar_Calculation_fc0_14 615 2021-01-21 17:32:43
Solar_Calculation_fc0_15 476 2021-01-21 17:32:43
alle anderen sind auf 0 und hier weg gelassen
Wenn das wirklch gebraucht würde, dann bitte bei mir melden, ich mache es dann mit einem Parameter konfigurierbar, damit die Datenbank dann wegfallen kann.
Somit würde dann aber auch Grafana nicht mehr diese Werte aus der Datenbank bekommen.
Ich habe halt auch festgestellt, dass es schon besser ist die Vielzahl der PV Werte in einer Datenbank zu haben. Mit FileLog war ich da sehr schnell am Ende, insbesondere
wenn es um Aggregierund der Daten geht, aber jeder wie er mag.
Grafana ist ja auch sehr schön mit einer Datenbank zu nutzen. Das gibt es alles auch schon vorgefertigt in Docker Containern.
============================================================================================
Meinst du mit "Heizungskurve" tatsächlich die im Heizungsbau üblichen Kurven zur Einstellung der Vorlauftemp. abhängig von Außentemp und Steilheit ? Oder ist es ein Synonym für eine andere Kurve ?
Genau die :-) , ich bin da ziemlich pragmatisch, die Code Zeilen hatte ich ja schon hier rein gestellt.
Es hatte auch einen verblüffend einfachen und guten Effect ;-)
============================================================================================
@papaFinde ich einen guten und vermutlich hinreichenden Ansatz. Zumal wir diese Grunddaten bereits im Modul haben über die ww-Id's. Das werde ich mal einbauen. Frage nur wie hoch ich die Korrekturen ansetze, mal schauen ...
Aus meiner Erfahrung reicht ein Faktor aus Regen und einer aus Wolken, wie gesagt die Stärke der Dämpfung beeinflusse ich über die "Heizungskurve".
Den Ansatz mit den Wetter IDs hatte ich bereits verworfen, da es einfach viel zu viel ist und es dann noch Dämpfungsfaktoren geben müsste.
============================================================================================
Im reading steht jeweils die Einheit dabei, somit auch als VALUE in der Datenbank, was sich in Grafana mit meinem Kenntnisstand nicht anzeigen lässt.
Es wäre schön, wenn dort nur der Wert und nicht die Einheit mit drin stände. Oder gibt es da einen Trick?
time Today_Hour_PVforecast
2021-01-20 14:56:39 269 Wh
2021-01-20 14:56:39 264 Wh
Unschön ist auch, das die readings eine Stundennummerierung haben und somit in der Datenbank als einzelne readings erscheinen und nicht der Wert mit dem korrekten TIMESTAMP.
============================================================================================
Edit:
Jetzt wo du mich darauf aufmerksam gemacht hast, habe ich mir nochmal die rad1h Daten des DWD angeschaut. Die Werte folgen über den Tag einer relativ gleichförmigen Kurve - mal höher mal tiefer - wie das sehe. Da können eigentlich keine Bedingungen wie Regen, Wolken etc. enthalten sein.
Das muss noch mit rein. Mal gucken ob ich die Stelle bei dir finden zum Spicken. 
Ich habe einfach auf die Prozentuale Wahrscheinlichkeit für Wolken und Regen die "Heizungskurve" angewendet. Die hat jeweils einen Basiswert und einen Wert für die Steilheit.
Der Basiswert legt fest, bei welchem Eingangswert quasi der Faktor 1 zurück kommt und die Steigung legt die Aggressivität fest, wie stark auf eine Änderung des Eingangswertes reagiert werden soll.
Die Defaults findest Du im Wiki beim Device PV_Anlage_1_config
$cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ; <<< die -0.01 brauchte ich, weil es beim DUMMY keinen Picker für solche Werte gibt.
if ($cloudk ne 0) {
$cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
};
============================================================================================
Das wäre mein momentanes DWD Device, wenn Du auch beide Forecasts parallel testen möchtest.
defmod DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast comment Version 2020.10.19 18:28
attr DWD_Forecast event-on-change-reading Rad1h,TTT,Neff,R600
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,Neff,R600,RRS1c,SunUp,SunRise,SunSet
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P0178
attr DWD_Forecast group PV Eigenverbrauch
attr DWD_Forecast icon weather_rain_fog
attr DWD_Forecast room Informationen->Wetter,Strom->Photovoltaik
attr DWD_Forecast sortby 06
attr DWD_Forecast verbose 0
============================================================================================
@Heiko im Photovoltaikforum wird für die Prognose auch irgend eine pvlib verwendet. Kilian ist da unterwegs. Was ich so gesehen habe werden in der pvlib direkt verschiedene Hersteller Module unterstützt, was wohl mit dem Wirkungsgrad und den Einbußen bei steigenden Temperaturen zu tun hat. Da war ich vor einem Jahr auch aktiv, jedoch hatte ich mich dann für den etwas simpleren Weg entschieden und mit plin auch das damals verwendete Python eliminiert. Nochmals vielen Dank an plin :-)
============================================================================================
Wolken und Regen sind momentan noch nicht mit drin.
War der Auffassung dass der DWD es bereits in den Strahlungsdaten für den Standort berücksichtigt.
Liege ich da falsch ? Wenn ja, wie beziehst du diese Werte mit ein ?
Edit:
Jetzt wo du mich darauf aufmerksam gemacht hast, habe ich mir nochmal die rad1h Daten des DWD angeschaut. Die Werte folgen über den Tag einer relativ gleichförmigen Kurve - mal höher mal tiefer - wie das sehe. Da können eigentlich keine Bedingungen wie Regen, Wolken etc. enthalten sein.
Das muss noch mit rein. Mal gucken ob ich die Stelle bei dir finden zum Spicken.
Ansonsten braucht das Modul im AutoMode eine gewisse Einschwingphase von ein paar Tagen. Dann sollten die Werte plausibel sein. Und ich feile ja weiter ...
[/quote]
============================================================================================
Ich habe zwei Anlagen. Also zwei Wechselrichter und 5 Strings. Dann unterschiedliche Ausrichten (Ost oder West) und unterschiedliche Dachneigungen (45 oder 20) Wenn ich dich richtig verstanden habe sind das nun 5 Devices. Womit ich ja noch klar kommen würde. Aber wenn ich die Wetterprognose pro String errechne muss ich ja bestimmt auch pro String die Erzeugung als Device angeben. Das kann ich soweit aber dann werden noch "Energieerzeugung pro Tag" und "aktueller Netzbezug" benötigt. Diese beiden Werte sind aber ja immer auf die ganze Anlage summiert. Wie funktioniert dann die Berechnung bzw. was muss ich da tun damit es richtig berechet wird?
Das wäre eine super Vergleichsanlage für
Wetter / Leistungs-PrognoseAuf Wunsch könnte ich recht schnell noch mehr als 3 Ausrichtungen ermöglichen.
EDIT: Der Wunsch ist schon umgesetzt, die Schleife läuft einfach jetzt bis kleiner gleich 5 .
Ich habe jedoch keine Autokorrektur vorgesehen, weil das bei Kostal im WR nicht so richtig funktioniert. Dort wird es zur "inteligenten Ladesteuerung" des Speichers eingesetzt.
============================================================================================
@Christian,
Zitat
Wo bekommst Du denn die Nennleistung des Moduls her, die variiert schon ziemlich?
Die Globalstrahlung kJ/m2 wird in kWh umgerechnet und mit der Anlagengröße in m² multipliziert. Dieser Wert wird mit dem Wirkungsgrad der gesamten Anlage (Wirkungsgrad Module & Wirkungsgrad WR) und einem Faktor der Neigung multipliziert.
Multipliziert wird der Rohwert mit einem Korrekturfaktor der die sonstigen physikalischen Merkmale der Anlage wie Ausrichtung der Module für jede einzelne Stunde anpasst. Das kann man manuell machen (fix) oder die Autokorrektur einschalten welche die Soll/Ist-Werte ständig miteinander vergleicht und anpasst. Die max. Anpassung kann man über Attribut maxVariancePerDay einstellen.
An der Automatik baue ich gerade weiter.
============================================================================================
Der Standort ist ja bereits in der Definition/Konfiguration des DWD_OpenData hinterlegt.
Welchen Einfluß bzw. Faktoren sollte man denn zusätzlich einbeziehen die eine erneute Angabe des Standortes im Modul notwendig machen ?
Ja, solche individuellen Anlagenfaktoren werden durch die manuelle/automatische Angabe eines Korrekturfaktors neutralisiert.
Beim DWD liefert nicht jede Station den rad1h Wert, wodurch man unter Umständen einige viele Kilometer weg ist.
Ich wohne im Rhein Tal und da wäre der Höhenunterschied zum Odenwald doch schon über 550 Meter und die nächste DWD Station wäre Bensheim für beides :-)
Unsere Mitstreiter in der Schweiz haben da auf 5 Km Entfernung noch krassere Höhenunterschiede. Das ist also doch ziemlich wichtig.
So etwas gibt es nicht. Man legt sich z.B. mehrere Devices an wenn man z.B. mehrere unterschiedlich ausgerichtete Anlagen/Strings hat.
Für das jeweilige Device kann man wieder manuell/automatisch eine Ergebniskorrektur ableiten (lassen) die sich aus den vorhergesagten Strahlungswerten und den tatsächlich erreichten Ergebnissen ergibt.
Puh, dann würde ich für meine Anlage schon drei Devices haben. Ein anderer Anwender in Norddeutschland hat 3 Ausrichtungen und 2 weitere Gebäude mit ziemlich starken Unterschieden, das sind dann 5 Devices :-(
Später soll noch die SolCast API als mögliche Quelle eingebunden werden. Dort muss man sich bezüglich Lage ebenfalls festlegen. Im kostenfreien Abruf geht m.W. nur eine.
Bei drei Ausrichtungen mit drei Devices häufen sich dann auch noch die Abfragen, ich glaube 20 sind frei.
Nein, das ist der Wirkungsgrad den der Hersteller für die Module angibt.
Da schau ich mal ins Datenblatt.
Hast du eine Temperaturabhängigkeit mit eingebaut ? Wen ja, gib mir mal einen Tipp für das mathmatische Schema dafür. Dann würde ich es mit integrieren.
Ja, ist drin, mit einer Temperaturkurve von den Heizungsbauern :-)
Klappt gut, sogar mit einer geschätzten Temperatur. Ich nehme die TTT vom DWD +10° als Schätzwert. Am besten wäre jeweils ein Sensor pro Ausrichtung direkt unter den Modulen, aber ich stehe auf less Hardware.
Für den fc_0_aktuell wäre auch der Messfühler der Wärmepumpe am Lufteinlass gut. Die LWP steht bei mir im Süden in der prallen Sonne, da habe ich die +10° abgeleitet ;-)
Wird in der sub calcPVforecast ab Zeile 2144 gemacht.
Wo bekommst Du denn die Nennleistung des Moduls her, die variiert schon ziemlich?
Dann liefert dein DWD Device diese Daten nicht. Schau mal ob du dort im Attribut forecastProperties SunUp,SunRise,SunSet mit gesetzt hast.
Okay, ich hatte da auf die nötigsten readings minimiert, das sollte dann ins Wiki rein.
Man trägt ja nichts ein. Die Informationen laufen Stunde um Stunde vorwärts. Das sieht man auch an der Grafik. Sie zeigt immer einen Slot von 24h ab aktueller Zeit. Man kann es per Attr verringern wenn man mag.
Müsste ich mal überdenken. Ich frage am aktuellen Tag bereits die Forecast Werte vom nächsten Tag ab, um meine Entscheidungen noch am aktuellen Tag mit einfließen zu lassen. Wäre der nächste Tag schlecht, und heute noch Top, dann könnte ich die LWP im PV Modus überheizen lassen und hätte schon WW für den nächsten Tag. Auch der Pool ließe sich anders heizen. Beim BEV könnte man dann auch schon heute voll aufladen und bräuchte nicht morgen zu tanken.
Wird alles automatisch bestimmt aus den DWD Daten.
Aber guter Hinweis dass der DWD im Tag fc0_* nochmal korrigiert. Das muss ich noch mit berücksichtigen denke ich.
Ich glaube der DWD liefert alle drei Stunden neue Daten, dann lösche ich in der DbLog den Forecast für heute und für morgen und schreibe die aktualisierten Werte wieder rein. Das war mit ein Grund die DbLog zu verwenden. Die Kurve von morgen kann dann auch schon angeschaut werden. Wenn der heutige Tag dann zu nächsten tag wechselt, bleibt die Kurve in der Datenbank stehen und man sieht direkt den Vergleich, was der DWD am Vortag prognostiziert hat und wie jetzt der aktuelle Tag aussieht. ... das war ganz schön wirr jetzt :-)
Ich habe nochmal ein Grafana Diagramm eines Top Prognose Tages angehängt.Die rote Linie ist bereits am Vortag in die Datenbank geschrieben worden. An der hell-grünen Solar_Calculation_fc0 Linie sieht man, dass der DWD die Prognose nach oben korrigiert hat.
============================================================================================
Ja, hab ich und habe mir Anregungen geholt. Ich entnehme auch einiges aus dem Wiki des Projekts.
Unser Modul ist nicht auf eine Datenbank angewiesen und es ist ja jetzt schon durch die generische Wahl des Inverterdevices (z.B.) unabhängig vom Hersteller. Muß ja kein SMA-Inverter sein.
Das bringt mich auf die Idee dass ein User des Projektes bzw. ch.eick auch dieses Modul parallel installieren könnte und aus den Differenzen zwischen beiden evtl. Verbesserungen ableiten lassen.
Hallo zusammen,
wie gewünscht habe ich es jetzt parallel konfiguriert und mal ein List gemacht.
Das sieht schon mal echt monströs aus. Tolle Aufbereitung und die Konfigurationsführung gefällt mir echt gut.
My5cent:
1. Ich war erschlagen von dem vielen Code :-) , da sollte das Ergebnis ja auch besser werden :-)
2. HTMP Darstellung sieht schon mal gut aus, wobei ich normalerweise nur auf die Kurve schau
3. Noch habe ich nicht verstanden:
- Warum der Standort nicht benötigt wird
- Mit dem Standort ist auch eine Höhe über NN verbunden
- Die Gebäudehöhe hat einen kleinen Einfluss auf die Winkel
- Wo finde ich die Ausrichtung der Module, eventuell Gebäudenamen Ost, Süd, West, Garage, Scheune
So könnte man sehen, welche Ausrichtung für die Leistung sorgt
- moduleEfficiency ist das die Veränderung mit der Temperatur?
- Wie wird die Leistung pro qm berücksichtigt?
- SunRise und SunSet ist bisher auf 00:00 <<< Das lag an den fehlenden readings im DWD Device
4. Es wird keine DbLog benötigt, wie kann ich dann die Kurve für morgen eintragen?
5. Beim DWD wird fc0_10_* verwendet, das fände ich besser als NextHour
6. Wo kann ich den Forecast für morgen einstellen? Der DWD hat oft Abweichungen zwischen dem fc1_* und korrigiert das dann nochmal am entsprechenden Tag im fc0_*
