Ertragsprognosedaten in Solaranzeige einbinden

[Bogeyof]

Die beiden Werte Prognose und PrognoseL werden aber beide von meiner hier vorgestellten Prognose generiert, also fehlt eigentlich nichts...
Klar habe ich noch 2 weitere Prognosen integriert, das ist aber eine andere Baustelle

[jupiter4h]

Ich komme momentan leider noch nicht weiter.
Grafana meckert jetzt erst mal wegen $ProgFakt. Das muss ich anscheinend noch irgendwo definieren. Ich dachte, die Faktoren wären alle im Script hinterlegt. Setze ich den Faktor einfach auf 1, dann kommen leider auch keine Daten (nur die Fehlermeldung ist dann weg).

Daten sind vorhanden, ich habe sie in der DB gesehen. Was ist den der Unterschied zwischen "eigenePrognose" und "eigenePrognoseL"?

Dann noch ein Hinweis. In /var/www/log/php.log sehe ich folgende Hinweise:
[13-Aug-2020 11:30:01 Europe/Berlin] PHP Warning: Use of undefined constant E756 - assumed 'E756' (this will throw an Error in a future version of PHP) in /var/www/html/prognose.php on line 78
[13-Aug-2020 11:30:42 Europe/Berlin] PHP Notice: Undefined index: Seriennummer in /var/www/html/prognose.php on line 100

Der 1. mir klar zu sein, die Station muss in "" eingeschlossen werden. Dann ist der Hinweis weg.
Der 2. Hinweis könnte mit der Anlage zusammenhängen. Ich verwende ein S10E von E3DC.

[Bogeyof]

Prognose.png

Ich nutze den Durchschnitt aus Prognose und PrognoseL (um eine Stunde versetzt und um die stündlichen Faktoren korrigiert in der prognose.php), dieser wird noch einmal mit einem Faktor im Dashboard (als Dashboard-Variable definiert) korrigiert, dieser ist aktuell bei mir 0.97.

Ok, habe ich vielleicht nicht deutlich geschrieben, diese Variable muss als Dashboard-Variable definiert werden, ist im hier erhältlichen Dashboard nicht enthalten. Damit kann ich etwas leichter nachsteuern, muss nicht gleich alle Stundenfaktoren einzeln ändern...
Ich denke zu 1. liegt wohl an den Hochkommata
zu 2. auch hier sollte die Vermutung stimmen, ich habe einen Kostal und dort wird die Seriennummer mit ausgelesen. Diese war in dem zugrunde liegenden Skript von Ulrich mit drin, wird aber für diese Prognose nicht benötigt. Hierzu ca. ab Zeile 95 die Zeile wie folgt ändern (also auskommentieren):

Code: Alles auswählen

  #$aktuelleDaten["Produkt"]  = $aktuelleDaten["Seriennummer"];

EigenePrognose ist eine einfache Umrechnung der Strahlungswerte vom DWD mit den angegebenen Anlagenfaktoren. Diese wird um 2 Stunden verschoben, da die Werte sonst keinen Sinn machen (vermutlich Zeitzone UTC statt UTC+2).
EigenePrognoseL wird um eine Stunde weniger verschoben, zusätzlich um Stundenfaktoren, die in der prognose.php hinterlegt werden können, angepasst. Damit lässt sich dann besser ein Durchschnitt aus EigenePrognose und EigenePrognoseL berechnen, denn es sind nur stündliche Werte und die zeigen immer den Wert zur vollen Stunde. Jedoch habe ich ja innerhalb einer Stunde eher den durchschnittlichen Ertrag zwischen Anfang und Ende dieser Stunde...

[jupiter4h]

Danke für deine Geduld mit mir.

Einen kleinen Schritt bin ich weiter. Meine Definition entspricht jetzt eigentlich deiner, wobei ich ProgFakt erst einmal einfach auf "1" gesetzt habe.
Mit "select * from WetterPrognose limit 20" kann ich sehen, dass in der DB Daten liegen. So weit so gut. Leider bekomme ich in Grafana immer noch keine Daten angezeigt.

Die Definition bei mir: (bekomme die Hardcopy nicht eingefügt, habe sie als Anhang hinterlegt).
Ich verstehe auch noch nicht den Hinweis auf "CvT" im "select". Hängt mein Problem evtl. damit zusammen?

[Bogeyof]

OK, auch wieder zum Teil meine Schuld. CvT ist mein Namenskürzel und ich habe meine Daten nicht unter dem Measurement "WetterPrognose" abgelegt, sondern unter meinem eigenen Measurement "CvT". Bei mir sind schon wieder mehr Daten vom DWD drin und ich habe die Prognose auch inzwischen mit einem Wärmefaktor versehen, da ich feststellen musste, dass die Leistung bei den aktuellen warmen Temperaturen deutlich nachlässt. Also berechne ich aus den angesagten Temperaturen pro Stunde einen Korrekturfaktor. Damit das nicht die Standardinstallation stört, mache ich mein eigenes Ding unter "CvT". Ich dachte das wäre nur ein Beispiel, wie die Berechnung aussehen könnte.

Bei Dir müsste die Formel wie folgt lauten:

Code: Alles auswählen

SELECT (sum("eigenePrognose") + sum("eigenePrognoseL")) / 2  FROM "WetterPrognose" WHERE $timeFilter  GROUP BY time(1d,-2h) fill(null)

In der angehängten prognose.php wären die Änderungen bzgl. Temperatur drin, sind nur 2 Zeilen. Beim Kopieren daran denken, dass die Stundenfaktoren evtl. bereits selbst angepasst wurden...

[jupiter4h]

Super, jetzt habe ich auch Daten.
Ich sehe schon, dass ich mich deutlich mehr mit Grafana auseinandersetzen muss.
Jetzt muss ich nur noch die Daten auf Stundenbasis aufbereiten aber das wird schon.

Vor allem kann ich jetzt vergleichen. Bisher habe ich von Proplanta Tages-Rad-Werte und die Sonnenscheindauer (Tageswert) bekommen, die ich mit einer ganz einfachen Formel umrechne.
Vom Rad-Wert ziehe ich max. 1,5 ab in Abhängigkeit von der Sonnenscheindauer (0 bei 100%, 1,5 bei 0%). Den Wert multipliziere ich mit meiner Anlagenfläche und Wirkungsgrad der Module.
Seit Ende April habe ich das im Einsatz und habe - selbst bei der einfachen Formel - eine durchschnittliche Abweichung von 3%. Von E3DC gibt es auch eine Prognose. Die weicht aber durchschnittlich um 83% von meinen Ertragswerten ab (die sind oft zu pessimistisch ).

Wenn die Werte aus der stundenweisen Berechnung vergleichbar sind, kann ich die Steuerung der Batterieladung noch besser optimieren.

LG
Holger

[Bogeyof]

Hier ein Beispiel (natürlich wieder mit CvT, aber das sollte jetzt kein Problem mehr sein) für eine stündliche 3-Tagesprognose. Dazu muss rechts bei den Eigenschaften der Grafik natürlich auch noch ein wenig angepasst werden, aber hier hilft Probieren sehr gut zum schnellen Erlernen...

[jupiter4h]

Ja, hilft mir schon sehr. Danke noch mal. Es wird langsam rund .

[jupiter4h]

Jetzt komme ich mit den nächsten Anmerkungen / Fragen (unsortiert)...

a) Die Prognosedaten in der Tabelle WetterPrognose sind ja bereits manipuliert (im positiven Sinne). Ich fände es aber gut, wenn auch der unveränderte Rad1h-Wert mit abgelegt wird. Zumindest für mich wäre es dann einfacher, Vergleiche zu ziehen und ein eigenes Modell zu entwickeln.

b) Die Daten werden in der InfluxDB in UTC gespeichert, daher hast du ja im select die Angabe "...GROUP BY time(1d,-2h) fill(null)". Muss dass dann bei Rückkehr zur Normalzeit auf "1d,-1h" angepasst werden?

c) Finde ich die Zeitproblematik auch in prognose.php - Zeile 203 bzw. 214 ($Timestamp1h = intval($Einzelwerte[$i+1]) + 7200; || if ($aktuelleDaten["Timestamp"] > 7200) { ) ?

d) prognose.php, Zeile 192 - 200. Werden da die Rad1h-Werte noch einmal modifiziert aufgrund ihres Wertes?

e) eigenePrognoseL liegt eine Stunde vor dem Wert eigenePrognose. Da meine Anlage auf 205° ausgerichtet ist (mein Peak daher eher eine Std. später liegt), wäre es für mich günstiger, den Wert eigenePrognoseL um 1 Std. nach (und nicht vor) dem Wert eigenePrognose zu legen (unabhängig von der Möglichkeit, den Wert noch stundenweise durch $STDFAKT zu verändern). Wo müsste ich da im Script Hand anlegen?
Vielleicht macht es ja Sinn, für eigenePrognoseL eine Versatzzeit in min. (pos. und negativ) angeben zu können (da wo auch Standort, Wirkungsgrad, ... hinterlegt sind). Dann kann jeder individuell nachsteuern aufgrund der Ausrichtung seiner Anlage.

[Bogeyof]

Du schaust Dir die Dinge aber schon genau an, gut so...
Zu a) ich habe eine prognose.php angehängt, welche die unveränderten Rad1h Werte unter "Radiation" in WetterPrognose ablegt.
zu c) e) ich habe oben bei den zu ändernden Variablen in der prognose.php 2 neue Variablen $Zeitversatz und $ZeitversatzL hinterlegt, dort kann der Versatz für die reguläre Prognose ($Zeitversatz, aktuell 2 Stunden) und die manipulierte Prognose ($ZeitversatzL, aktuell 1 Stunde) angegeben werden. Theoretisch könnte dort auch mit 1.5 Stunden o.ä. gearbeitet werden.
Zu a) und c) das mit dem Zeitversatz basierte auf Tests, vermutlich ist es die Differenz UTC zu unserer Sommerzeit UTC+2. Wie es sich verhält, wenn Winterzeit (Normalzeit) ist kann ich gerade nicht sicher vorhersagen, aber wahrscheinlich sind Deine Annahmen richtig.
Zu d) Ebenfalls richtig, bei sehr hoher Einstrahlung in der Mittagszeit nimmt der Wirkungsgrad meiner Module etwas ab, daher wurden sehr hohe Radiation-Werte mit einem Faktor korrigiert. Dies basiert ebenfalls auf Tests und ist vermutlich bei jedem unterschiedlich. Diese sehr hohen Werte kommen nur an rein sonnigen Tagen vor und sicherlich hast Du auch schon bemerkt, dass die Spitzen da nicht so hoch sind wie an leicht wolkigen Tagen, wenn die Sonne wieder hinter den Wolken hervorkommt.
Diese Zeilen können auch gerne auskommentiert werden (einfach ein "#"-Zeichen vor die jeweiligen Zeilen setzen)...