FHEM Forum

Zitat von: sky64 am 17 Januar 2021, 19:40:06
Ja, Danke. Das ist sehr umfangreich.
Ich habe das schon mal versucht zu lesen, aber viele Sachen habe ich noch nicht verstanden.
Ich weiß das ich als nächstes mit DBlog anfangen muss.
Ohne zumindest etwas Verständnis was und wie das funktioniert geht es nicht wenn ich es für mich anpassen will.

Zitat von: sky64 am 18 Januar 2021, 17:33:07
Vielen Dank, werde mich mal daran versuchen

Zitat von: sky64 am 21 Januar 2021, 07:24:27
da z.B. für das dblog noch einige Sachen beachtet werden müssen und auch nicht 100%ig im Wiki beschrieben ist (z.B. das man ja auch dem MySql auch die Datenbank anlegen muss).
Da mussten erst mal die 15 Jahre alten und nicht mehr verwendeten MySQL-Grundlagen wieder ausgegraben werden ...
Aus diesem Grund heißt mein dblog auch "logdb" und nicht "LogDb" wie bei dir, aber das ist ja nur eine Kleinigkeit.
Außerdem muss man natürlich für alle anderen Devices das Log in die DB abdrehen.

Zitat
Auf jeden Fall habe ich jetzt :

* logdb
* LogDBRep_delete_PV_Forecast
* PV_Anlage_1_config
* DWD_Forecast
* die beiden Funktionen "Solar_forecast" und "Solar_plain" in der "99_myUtils.pm"
In den Readings vom DWD_Forecast  sind Werte drin.

Zitat
Ein erster Test liefert auch Zahlen:

Code Auswählen Erweitern

fhem> {Solar_plain(45,0,"2021-01-19 15:00:00")}
3.60852722543291
fhem> {Solar_plain(45,0,"2021-01-19 18:00:00")}
0.001


Zitat
Beim nächsten Test hänge ich allerdings, denn ich habe eigentlich kein "PV_Anlage_1 "
Also habe ich eine Dummy "PV_Anlage_1 " erstellt.       <<<<< Da gehen die setreading dann rein (s.o.)
Aber hier fehlt vermutlich noch etwas, den mit

Code Auswählen Erweitern

fhem> {Solar_forecast("logdb","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}

erhalte ich im Log :

Code Auswählen Erweitern


2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 07:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 08:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:


Zitat
Nur den Verweis im DbLogInclude.
Und das immer Value: 0 kommt ist sicher auch nicht richtig.

Zitat
Es werden aber keine Solar-Readings erstellt.
Muss ich die vorher noch anlegen? Im Wiki habe ich für die Kostal-Anlage PV_Anlage_1 aber auch nicht gefunden.

Zitat von: EinEinfach am 21 Januar 2021, 09:44:45
ich habe ein sehr großes Interesse an der Prognose zum Solarertrag. Ich habe einen SolarEdge Wechselrichter, aber wie ich es verstanden habe, das ist im Prinzip egal.

Meine Frage lautet, ich habe gesehen, dass du dich in einem anderen Thread mit dem Thema im Zusammenhang mit dem 76_Solarforecast-Modul auch auseinandersetzt. Vom Aufwand erscheint mir die andere Lösung einfacher umzusetzen, aber die Genauigkeit ist in deinem Ansatz besser. Da du deine Erfahrungen in den anderen Modul miteinbringen willst, soll langfristig diese Lösung hier entfallen?

Zitat von: Herjemine am 21 Januar 2021, 14:41:26
nur für den Solarforecast extra ein SQL Datenbank anzulegen, begeistert mich wenig

Zitat von: DS_Starter am 20 Januar 2021, 16:02:42
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 ?

Zitat von: DS_Starter am 20 Januar 2021, 15:22:33
@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 ...

Zitat von: DS_Starter am 20 Januar 2021, 09:40:59
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.  :)

Zitat von: DS_StarterWolken 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 ?

Zitat von: xerion am 19 Januar 2021, 19:51:02
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?

Zitat von: DS_Starter
@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.

Zitat von: DS_Starter am 19 Januar 2021, 17:13:41
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.

Zitat
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.

Zitat
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.

Zitat
Nein, das ist der Wirkungsgrad den der Hersteller für die Module angibt.

Zitat
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.

Zitat
Wird in der sub calcPVforecast ab Zeile  2144 gemacht.

Zitat
Dann liefert dein DWD Device diese Daten nicht. Schau mal ob du dort im Attribut forecastProperties    SunUp,SunRise,SunSet mit gesetzt hast.

Zitat
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.

Zitat
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.

Zitat von: DS_Starter am 18 Januar 2021, 20:27:42
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.

Zitat von: plin am 11 Januar 2021, 09:58:00
Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

ZitatMuss man etwas beachten um das Chache File zu nutzen?

Zitat von: DS_Starter am 22 Januar 2021, 20:09:28
Nein, das wird automatisch genutzt.

Schau mal ob du bei dir dieses File findest:

.../FHEM/FhemUtils/PVH_SolarForecast_<dein Devicename>

Dieses File wird bei einem stop/start geschrieben und wieder eingelesen. Wenn du das File nicht findest schau mal ins Log ob es beim Stop/start Fehlerausschriften gibt.

Zitat von: DS_Starter am 22 Januar 2021, 20:09:28
Nein, das wird automatisch genutzt.

Schau mal ob du bei dir dieses File findest:

.../FHEM/FhemUtils/PVH_SolarForecast_<dein Devicename>

Dieses File wird bei einem stop/start geschrieben und wieder eingelesen. Wenn du das File nicht findest schau mal ins Log ob es beim Stop/start Fehlerausschriften gibt.

ZitatWenn ich das Modul neu lade erscheint das im Log:

Zitat von: DS_Starter am 22 Januar 2021, 20:56:24
Bei einem reload sind diese Warnings normal.
Ich meinte aber shutdown (restart). Dann wird das File geschrieben / gelesen.

Aber mir fällt etwas ein. Könnte es sein dass ihr beide (dk3572) configDB benutzt ?

Zitat von: DS_Starter am 22 Januar 2021, 21:19:43
In meinem contrib liegt eine neue Version.

Mit verbose 5 sehr ihr eine solche Ausgabe:

Code Auswählen Erweitern


2021.01.22 21:14:39.544 5: SolCast - set PV History hour 21 -> real: 0, forecast: 0


Diese Ausgabe kommt bei jedem Datensammellauf unter der Voraussetzung dass die History mit Daten beschrieben wird.
Immer für die aktuelle Stunde.

Zitat von: DS_Starter am 22 Januar 2021, 21:36:16
passt. Und was zeigt get <> pvHistory ?

Zitat von: DS_Starter am 22 Januar 2021, 22:33:07
Da muß aber noch etwas davor stehen was den eigentlichen Grund anzeigt.

Zitat von: DS_Starter am 22 Januar 2021, 22:50:23
Nicht beim reload sondern beim shutdown restart. Aber glaube nicht an ein Modulfehler, ist nur eine Logausgabe dazu gekommen und läuft bei mir.

Nochmal downloaden.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern


"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"


Zitat von: DS_Starter am 22 Januar 2021, 23:17:04
erstmal prima.

Aber diese Diskrepanz:

Code Auswählen Erweitern


2021.01.22 23:09:26 5: SolarForecast - set PV History hour 23 -> real: 0, forecast: 0


und

Code Auswählen Erweitern


2021.01.22 23:11:24 5: SolarForecast - PV History content: undef


ist mir ein Rätsel. Das lösen wir heute auch nicht mehr.
Lass mal so laufen. Morgen schauen wir weiter. Vllt. kommt mir über Nacht eine Idee. Kann ich bei mir auch nicht nachvollziehen.

LG,
Heiko

Zitat von: DS_Starter am 23 Januar 2021, 09:30:03
Ich habe heute einen ruhigen Tag. Bei uns schneit es und die Zellen sind jetzt zu.  ;)

Zitat
2021.01.23 12:41:48.446 2: SolCast - ERROR - the attribute "forecastProperties" of device "DWD.Solar.Forecast" must contain: Neff,R101

Zitat von: DS_Starter am 23 Januar 2021, 09:11:21
Guten Morgen,

[Modul 76_SolarForecast]

ich glaube ich habe das Problem gefunden/gefixt.
Die ungedatete V liegt in meinem contrib.

Außerdem ist in dieser V auch der Niederschlag berücksichtigt und es gibt den Setter:

  set <> reset pvHistory

ZitatDas File in FHEMUtils gibt es allerdings immernoch nicht...

Zitatgibt es keine möglichkeit, die wie die fhem.save auch so zu speichern?

ZitatWäre es möglich das Total der erwarteten PV Leistung am aktuellen Tag in ein Reading zu schreiben?

Zitat von: DS_Starter am 24 Januar 2021, 09:39:12
[Modul 76_SolarForecast]

@Mumpitz,

habe das Modul erweitert. Es gibt jetzt ein Reading Today_PV. Es wird über den Tag aktualisiert und kann sich im Wert ändern falls sich die gesammelte Einflußgrößen ändern. Hoffe es passt so.

Neue V ist im contrib.

LG,
Heiko

Zitatich vergleiche immer noch die Basis Werte, ohne die Autokorrektur und da gibt es massive Abweichungen.

Zitat von: DS_Starter am 24 Januar 2021, 10:09:43
Moin Christian,

Damit man die einzelnen Bestandteile vergleichen kann, schaltest du am Besten verbose 5 ein und schaust diese Logzeilen für die jeweile Stunde an:

Code Auswählen Erweitern


2021.01.24 09:59:14.046 5: SolCast - collect DWD forecast data: device=DWD.Solar.Forecast, rad=fc0_10_Rad1h, Val=100.00
2021.01.24 09:59:14.047 5: SolCast - calcPVforecast -> Hour: 10 ,moduleTiltAngle factor: 1.44, Cloudfactor: 0.4665, Rainfactor: 0.823, pvCorrectionFactor: 1.14


Val ist der vom DWD gemeldetete Rad1h. Die Zeile darunter zeigt die weiteren Einflußfaktoren. Ich werde die Logausgabe noch etwas erweitern.
Dessen ungeachtet liegen die Werte zw. real und forecast bei mir tendenziell beieinander. So massive Abweichungen wie bei dir gibt es bei mir nicht. Allerdings mit Autokorrektur und ich habe nur Südlage.
Die Sache mit dem Astro-Device und die davon abgeleitete Anpassung an die Ausrichtung kommt noch. In dem Fall kommen noch Setter für die Ausrichtung hinzu.

Heute schneits wieder, also nix gescheites weil Zellen zu.  ;)

Zitat von: DS_Starter am 24 Januar 2021, 10:32:44
Die dort enthaltenen Grundlagen sind schon eingebunden bis auf Solar_plain (Astro) was noch kommt wie bereits gesagt. ;)

Zitat von: DS_Starter am 24 Januar 2021, 11:19:56
Grundlegende Rechnung ist:

PV (Wh) = Rad  (kJ/m2) * <Umrechfaktor kJ in kWh> * <moduleArea> (m2) * <Faktor f. Modultilt> * <Modul Wirkungsgread> * <Inverter Wirkungsgrad> * <pvCorrectionFactor> (1 bei ausgeschaltet) * <Cloudfaktor>* <Rainfaktor> * 1000

ZitatWie am Telefon besprochen bin ich mir immer noch nicht ganz sicher bezüglich m² und Modul Nennleistung.

Zitat von: DS_Starter am 24 Januar 2021, 11:19:56
Keine Ahnung. Kann ich bei mir nicht bestätigen.
Hier mal dir Werte vom 19. als bei uns noch kein Schnee lag:

Code Auswählen Erweitern


      10 => pvreal: 189, pvforecast: 406
      11 => pvreal: 140, pvforecast: 344
      12 => pvreal: 124, pvforecast: 411
      13 => pvreal: 122, pvforecast: 373
      14 => pvreal: 175, pvforecast: 248
      15 => pvreal: 57, pvforecast: 126
      16 => pvreal: 0, pvforecast: 24


Zitat
Die Realität hangelt sich bei mir zwischen Faktor 0.8 und 1.2 an der Prognose entlang.

Zitat von: DS_Starter am 24 Januar 2021, 12:16:50
Ich auch nicht.  Du hast zwar in deiner PV_Anlage_1_config eine Angabe module_1_power drin. Die finde ich aber nirgends wieder verformelt, was meiner Ansicht nach aber auch richtig ist.

Zitat
Da hast Du ja auch einen Faktor von teilweise 2-3 dazwischen.

ZitatUnter Globalstrahlung versteht man die gesamte an der Erdoberfläche auf eine horizontale Empfangsfläche auftreffende Solarstrahlung. Sie setzt sich zusammen aus

- der auf direktem Weg eintreffenden Solarstrahlung, der Direktstrahlung, und
- der kurzwelligen Diffusstrahlung, welche die Erdoberfläche über Streuung an Wolken, Wasser- und Staubteilchen erreicht.

Zitat
Der DWD liefert Strahlungswerte in stündlicher Auflösung für ein 10-Tages Vorhersagefenster.
Der Wert ist Rad1h in [Kj/m²].
Rad1h wird als Globalstrahlung bezeichnet.
Nach Rückfrage beim DWD ist dies die auftreffende Globalstrahlung auf eine virtuelle horizontale Fläche von 1m².

ZitatIst es irgendwie möglich, dass ganze Modul zurück zu setzen.

ZitatSomit wäre die Streuung bereits mit drin, aber die Dämpfung durch Wolken und Regen, was wir ja noch eingebaut haben, nicht.

Zitat von: DS_Starter am 24 Januar 2021, 16:39:17
@Christian
Dann sollte das passen. Nebel wäre aber auch noch so ein Faktor. Dafür gibt es auch einen DWD Wert wenn ich mich nicht täusche.

Zitat von: ch.eick am 24 Januar 2021, 16:39:40
Hallo Mumpitz,
hast Du für mehr Vergleichswerte auch mal meine modifizierte Solar_forcast() übernommen?
Die bisherige Umgebung wäre kompatibel und Du könntest die Vergleichswerte direkt in Heikos Device schreiben.

Hier mal das Muster für den Eintrag ins PV_Schedule Device

Code Auswählen Erweitern


################################################################################################################
## 2 PV Prognose vom aktuellen Tag aktualisieren
##     zwischen 7 und 19 Uhr zur vollen Stunde
DOELSEIF
([07:00-20:00] and [:00])

   ({Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)})
   ({Solar_forecast("none","none","DWD_Forecast_Test","Solar_forecast_fc","DWD_Forecast",0)})

################################################################################################################
## 3 PV Prognose für den nächsten Tag aktualisieren
##
DOELSEIF
([06:55] or [19:11])

   ({Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)})
   ({Solar_forecast("none","none","DWD_Forecast_Test","Solar_forecast_fc","DWD_Forecast",1)})



ZitatSag bescheid, wenn Du Ihn gefunden hast.

Zitat von: DS_Starter am 24 Januar 2021, 15:29:33
Diesen Flächenfaktor werde ich bei mir erstmal mit einbauen. Ist ein bisschen Arbeit weil aus dem Flächendiagramm zunächst eine Matrix (Hash) zu erstellen ist.
Damit bekommt man dann einen Flächenfaktor mit dem man die Globalstrahlung korrigiert die dann wiederum als Gk in die genannten Formeln eingeht.

Zitat von: jual am 24 Januar 2021, 16:51:47
Zu deinem Ansatz, eine Flächenkorrektur mit einzubauen, hätte ich noch eine Frage/Anregung. Wenn ich es richtig verstanden habe, dann wird der Korrekturwert auf Basis der Ausrichtung und der Dachneigung ermittelt. Wenn man jetzt mehrere Dachausrichtungen hat, müsste man ja theoretisch für diese Flächen unterschiedliche Faktoren berechnen. Eventuell kann man diese dann auch wieder zu einem Korrekturwert zusammen fassen.

Dies würde dann aber bedeuten, dass man Angaben zu seinen diversen Flächen machen müsste. Also ein recht komplexes Thema. Alternativ müsste man - ähnlich, wie ich das bei Solcast auch machen müsste - eine kalkulierte Ausrichtung für seine Dachflächen finden. Ich habe beispielsweise eine Ost/Westausrichtung mit 10 Modulen auf der Ost- und 19 Modulen auf der Westseite.

Zitat von: DS_Starter am 24 Januar 2021, 16:48:16
wwM

Zitat von: DS_Starter am 24 Januar 2021, 19:12:44
[Modul 76_SolarForecast]

Hallo zusammen,

eine neue V 0.4.0 liegt im contrib.
Wenn ihr das Modul heruntergeladen und restartet ! habt, verlangt das Device die Eingabe der Modulausrichtung mit:
   
      set <> moduleDirection

Ihr wählt eure Richtung einfach aus der Drop-Down Liste aus. Dadurch wird nun der vorn erwähnte Flächenfaktor implementiert.

Zitat von: DS_Starter am 24 Januar 2021, 20:51:37
Der Hausverbrauch, also der Consumption Wert CO, ist eine reine Anzeigefunktion und hat insofern keinen Einfluß.
Bezüglich Tagesertrag ist das eine gute Frage. Darüber war ich noch garnicht gestolpert weil ich nur einen String mit Südlage habe.
Ich glaube da muß ich mir bald etwas einfallen lassen um dieses Problem zu lösen. In dieser Konstellation würde die Autokorrektur die Korrekturwerte unnötig hochziehen weil die Devices nichts voneinander wissen.
D.h. erstmal ohne Autokorrektur fahren. Ich denke darüber nach wie ich das lösen werde...

Zitat von: DS_Starter am 24 Januar 2021, 20:51:37
In dieser Konstellation würde die Autokorrektur die Korrekturwerte unnötig hochziehen weil die Devices nichts voneinander wissen.
D.h. erstmal ohne Autokorrektur fahren. Ich denke darüber nach wie ich das lösen werde...

Zitat von: xerion am 24 Januar 2021, 21:05:53
Vielleicht wäre es ein besserer Ansatz, dass man einfach mehrere Strings mit unterschiedlichen Winkel und Ausrichtungen in einem Device erstellen könnte. Somit bräuchte ich anstelle von 5 Devices nur noch zwei. Da ich zwei Wechselrichter habe und man dann die Devices pro WR anlegen würden und nicht nach Ausrichtung oder Anzahl der Strings.

ZitatVielleicht wäre es ein besserer Ansatz, dass man einfach mehrere Strings mit unterschiedlichen Winkel und Ausrichtungen in einem Device erstellen könnte.

Zitat von: DS_Starter am 24 Januar 2021, 21:11:10
Ja das ist ja auch das Endziel. Aber gut Ding will Weile haben und ich gehe Stück für Stück voran um die Struktur im Modul nicht zu verlieren und den Überblick zu behalten damit am Ende etwas gutes herauskommt. Momentan ist nur ein String integriert.

Zitat von: DS_Starter am 24 Januar 2021, 15:29:33
so jetzt habe ich nochmal nach Berechnungsgrundlagen im Netz gesucht und bin auf diese Seite gestoßen ing-büro-junge (http://www.xn--ing-bro-junge-0ob.de/html/photovoltaik.html).

Demnach gibt es zwei prinzipielle Formeln nach denen man vorgehen kann. Ist etwa ich der Mitte unter "Prinzip der Ertragsrechnung" beschrieben.
Ich benutze bei mir die Formel 1 -> Mittels der Einzelwirkungsgrade. Dort geht die Modulleistung nicht ein. Dafür die Einzelwirkungsgrade.

Du verwendest m.M. nach die Formel 2 -> Mittels der Perfomance Ratio. Dort geht die Modullleistung ein. Allerdings auch eine Performance Ratio. Ich weiß nicht ob du das irgendwo in deinen Subs verformelt hast.

Aber wichtig ist m.M. nach noch der mittlere Teil (Berücksichtigung der Modul-Ausrichtung). Dort passiert eine Bestimmung des Flächenfaktors der die Globalstrahlung korrigiert. Diesen Flächenfaktor werde ich bei mir erstmal mit einbauen. Ist ein bisschen Arbeit weil aus dem Flächendiagramm zunächst eine Matrix (Hash) zu erstellen ist.
Damit bekommt man dann einen Flächenfaktor mit dem man die Globalstrahlung korrigiert die dann wiederum als Gk in die genannten Formeln eingeht.

Die Wirkung des Flächenfaktors findet man auch hier -> Planung von Ertrag (https://www.energie-experten.org/erneuerbare-energien/photovoltaik/planung/ertrag)

Zitatich werfe mal kürzere readings Namen in den Ring:

ZitatMüsste ich für den Wert etoday nicht auch eine Trennung auf die beiden Seiten also die beiden Strings vornehmen?

Zitat von: DS_Starter am 25 Januar 2021, 16:17:10
Was soll das bringen außer Stunden meiner Lebenszeit zu verbrennen ?  ;)
Sehe keinen Vorteil. Die Namen sind nicht sprechender und nicht lesbarer. Außerdem wegen der Grundlage für die durchlaufende Grafik nur aufwändig änderbar.

ZitatSie würden besser in den DWD Forecast passen

Zitatund ließen sich in der Datenbank auch besser Maskieren.

Zitat von: DS_Starter am 25 Januar 2021, 18:02:16
Rechtfertigt den Aufwand in keinster Weise.
Datenbank ist hier ausnahmsweise mal out of scope.  ;)
Aber da wäre ein konkretes Beispiel mal angebracht.

Zitat
--vorher------------------------------------------------
Next04Hours_PV 0 Wh
ThisHour_PVforecast 0 Wh
ThisHour_Time 25.01.2021 18:00:00
Today_PV 2993 Wh
Tomorrow_PV 3185 Wh
--nachher-----------------------------------------------
fc0_4h 0 Wh
fc0_1h 0 Wh
fc0_1h_time 25.01.2021 18:00:00
fc0_PV 2993 Wh
fc1_PV 3185 Wh

Zitat# hier macht current für mich keinen Sinn

ZitatBei einer Abfrage des Forecast für die aktuelle Stunde und die nächsten 4 Stunden wäre folgende Maske denkbar

ZitatGerade im Code merkt man, wie das Namenskonzept aufgebaut sein sollte.

Zitat von: DS_Starter am 25 Januar 2021, 19:22:27
Ich sehe weiterhin keinen Vorteil noch nachher zu vorher. Trenne dich gedanklich vom DWD Device. Es ist nur eine Datenquelle. Demnächst ist es ein anderes Device oder die SolCast API. Die hat keinerlei Readings.
fc0 und fc1 als Trennung des heutigen Tages zum nächsten Tag gibt es im Modul nicht. Es werden immer die x nächsten Stunden ab der aktuellen Stunde betrachtet. Das sieht man an den aktuellen Readings.
Aber für mich. Damit diese einzugebenden Daten in der Drop-Down gleich oben stehen. Ich habe mir dabei etwas gedacht ...
Wie gesagt, wenn jemand sowas braucht zum Logging -> userReading
Danke für den Hinweis.

Zitat von: DS_Starter am 26 Januar 2021, 22:25:21
Ich habe beobachtet, dass wenn der Himmel mal aufreißt sofort ein viel höherer Ertrag zu beobachten ist gegenüber dem Forecast, wohingegen es ziemlich gut passt wenn sich die Bewölkung so entwickelt wie vom DWD vorhergesagt.

ZitatEs ist sicher in dem anderen Thread schon gefragt worden, nach welchem Algorithmus versuchst Du die Autokorrektur zu implementieren?

ZitatDa Du jetzt nach meiner Beobachtung alles von Solar_forecast() übernommen hast sollten die Werte ja fast identisch sein

ZitatFür die Ausrichtung hast Du E,SE,S,... verwendet. Hier fände ich die Winkel besser, ohne jetzt überprüft zu haben, wie groß die Abweichung ist.
  Bei der Winkel Korrektur wirst Du doch sicher von den Buchstaben in Winkel umsetzen müssen.

ZitatBei mehreren Ausrichtungen sind oft auch mehrere Inverter im Spiel

Zitat<<<< ist das so richtig, oder habe ich da ein Problem bei der Konfiguration?

ZitatMüsste dann für die Autokorrektur auch jeder String separat definiert werden?

ZitatVermutlich werde ich auch noch den Sonnenstand über ein Astro Device mit integrieren

Zitat von: EinEinfach am 27 Januar 2021, 11:38:30
Das wird mir vermutlich helfen, denn aktuell habe ich im Forecast Device ab 17:00 eine Ertragsprognose und Real tut sich nichts, weil die Sonne schon untergegangen ist

Code Auswählen Erweitern

17 => pvreal: 0, pvforecast: 127

Zitat von: DS_Starter am 27 Januar 2021, 11:26:56
Die Hauptcrux ist noch eine evtl. Umstellung von Formel 1 auf Formel 2 und die Integration des Astro Devices.
Die Formel 2 gefällt mir ehrlich gesagt besser weil man die Wirkungsgrade nicht kennen muß. Dort geht zwar noch eine Performance Ratio (PR) ein, aber die hast du überhaupt nicht benutzt. Geht wahrscheinlich irgendwo mit unter.  ;)

Zitat von: DS_Starter am 27 Januar 2021, 18:33:36
Hallo zusammen,

ich habe das Modul nun auf eine andere Berechnung umgestellt die sich auf die installierte Leistung der Strings bezieht,
nicht wie bisher auf die Wirkungsgrade.

Zitat von: EinEinfach am 29 Januar 2021, 11:59:27
Hat jemand eine Idee, wie ich die Vorhersage am besten:

Code Auswählen Erweitern

NextHour01_PVforecast
NextHour02_PVforecast
...

in die Datenbank (DBLog Device) wegschreiben kann, um die Zukunft quasi vorab zu plotten. Ich abreite mit Grafana und da ist mein X-Vektor TIMESTAMP, jetzt muss ich irgendwie beim wegschreiben dem Forecast Reading den richtigen TIMESTAMP zuordnen.

Für einen Denkastoß wäre ich dankbar.

ZitatHat jemand eine Idee, wie ich die Vorhersage am besten .... wegschreiben kann

ZitatDas ist relativ einfach mit dem Attribut DbLogValueFn machbar.

ZitatFehlen hier nicht die Runden Klammern (split " ",$ts)?

Zitat von: EinEinfach am 29 Januar 2021, 14:20:53
Ich sehe immer noch nicht, an welcher Stelle der TIMESTAMP manipuliert wird. Es muss doch irgendwo +1Std oder oder auftauchen?

Zitat von: DS_Starter am 29 Januar 2021, 14:26:21
Der fertige Timestamp für DbLog wäre dann z.B..  2021-01-29 14:22:00
Er muß stimmen sonst wird er von DbLog nicht übernommen.

Zitat von: EinEinfach am 02 Februar 2021, 13:27:52
könnstest du mir evtl. noch ein Tipp geben, wie ich in Bezug auf gleiche Einträge mit dem gleichen Timestamp reagieren kann. Die Readings, je nach Prognose, ändern Ihre Werte, der Timestamp bleibt für die jeweilige Stunde immer gleich. Jetzt interessiert mich nur der letzte Wert aus der Prognose und die davor können bereinigt werden. Ich habe es mit dem DbRep-Device probiert und da mit

Code Auswählen Erweitern

set DbRep-Dvice delDoublets delete

Allerdings werden nur die Log-Einträge gelöscht, wo alle Attribute gleich sind (DEVICE, TIMESTAMP, VALUE usw.). Ich möchte die Doublets mit dem gleichen TIMESTAMP löschen und den letzten behalten.

Zitat von: EinEinfach am 02 Februar 2021, 13:43:19
Die doppelten einträge müssen auf den letzten Wert reduziert werden.

Zitat von: Herjemine am 16 Februar 2021, 16:00:11
Ich finde bei mir waren die DWD Rad Prognosen von meiner Station immer ganz gut gelegen,
wollte das mal überprüfen.

Für mich schaut es so aus als würde die Progonose zu stark gedämpft. Obwohl meine 3kw am Carport noch die meiste Zeit Schneebedeckt sind ..

Zitatkann ich rel. einfach Deine korrektur per "Heizungskurve" deaktivieren?

Zitat von: Herjemine am 16 Februar 2021, 19:30:02
ich hatte gemeint, du hast mal ne zusätzliche Dämpfung für Regen und Bewölkung mit rein genommen,
das wollte ich mal raus nehmen.

ok Grafik kann ich mal schauen, hab aber glaub ich für das SolarForecast bisher nix gelogt, mal schauen ob ich das vielleicht in nem Dummy hab ..

Zitat von: ch.eick am 17 Februar 2021, 09:45:38
Regen und Bewölkung hat er mit eingebaut, ich habe jedoch keine Konfigurationsmöglichkeit wahrgenommen.

Machst Du den Vergleich mit dem Solar_forecast() auch parallel? Da kannst Du kannst Du das deaktivieren, oder auch die Stärke der Dämpfung einstellen.

Zitat von: ch.eick am 16 Februar 2021, 17:28:33
könntest Du mal eine Grafik als Snapshot erstellen, das finde ich immer übersichtlicher.

Zitat von: Herjemine am 17 Februar 2021, 17:47:20
ich habe heute z.b. wieder

Today 14.518 kWh, TodayFor. 6483 Wh, Tomorrow 14813 Wh

Today ist der heutige Ertrag, TodayFor. ist der Forcast kurz vor Mitternacht, da lass ich den in ein Reading schreiben.
Aber ich hab ne Grafik von den DWD Rad Werten, ich finde da werden schon die Bewölkungswerte berücksichtigt,
von daher denk ich ist das bei meiner Station dann doppelt gemoppelt und ich würde es gerne mal wieder ohne die Korrektur versuchen,
da hatten bei mir die Werte besser gepasst  ;)

Zitat von: friesenjung am 19 Februar 2021, 22:24:23
steure mal meine Werte bei. Hab auch den "Correction Faktor" (Wolken, Regen) im Modulcode auf 1 gesetzt:

Today 24.456 kWh, TodayFor. 21593 Wh, Tomorrow 23497 Wh

Zitat von: ch.eick am 19 Februar 2021, 23:05:06
Hallo Daniel,
es ist natürlich immer der Vergleich mit der Realität interessant, ...
...

Zitat von: friesenjung am 20 Februar 2021, 11:02:12
Mir stellt sich aber noch eine andere Frage. Ich benötige ja eine Station vom DWD, die auch "Rad1h" liefert. Nun ist meine nächste dieser Stationen ca. 50km Luftlinie entfernt!
Für die Globalstrahlung mag das ja funktionieren, aber wenn dann dieser Standort auch für die anderen Wetterdaten (allg. Wetterlage, Regen, Wolken,...) herangezogen wird, ist das doch eher suboptimal, oder? Man müsste dann vielleicht 2 Wetterdevices verwenden?

Zitat
PS: bzgl. der Solar_forecast() muss ich mal schauen...

Zitat
wäre es nicht möglich  Today_HourX_PVforecast und Today_HourX_PVreal einfach mal als Array (oder zwei) irgendwo im hash unter helper oder sonstwo abzulegen ?

Zitat von: DS_Starter am 20 Februar 2021, 16:44:33
@WzutSicher, kann ich machen. Sage Bescheid wenn ich getan habe.

Zitat von: friesenjung am 20 Februar 2021, 11:02:12
Hallo Christian,

Die Realität steht bei "Today" also 24,456kWh. Dachte das hat Herjemine genauso gemeint, oder bedeutet das bei Ihm doch etwas anderes?
Egal, also bei mir lag es gestern ca. 3kWh über der Prognose. So wie Du auch schreibst, ist mir das lieber als umgekehrt ;)

Zitat
1.) beim Klicken auf ,,Device specific Help" wird bei mir nichts angezeigt, die Webseite ist aber im Modul enthalten...

Zitat
2.) Ich habe alle Daten die als ,,fehlend" angezeigt wurden ausgefüllt, aber ich bekommen keine Prognose. Dauert das einen Tag oder müsste die sofort da sein?

Zitat
3.) Ich habe zwei Wechselrichter mit je einem String mit identischer Ausrichtung, kann ich die Daten trotzdem in einer Prognose angezeigt bekommen oder muss ich zwei unabhängige Prognosen erstellen?

Zitat
4.) die gesamte Einspeisung ins Netz hole ich aus dem HomeManager2. Die wurde in der Prognose mal kurz angezeigt, ist jetzt aber wieder weg...

Zitat von: DS_Starter am 20 Februar 2021, 19:58:06
Es gibt ja auch die Direkt-Hilfe die für Kommandos und Attribute eingeblendet wird ... zumindest wenn man "DE" eingestellt hat.

ZitatAber by the way : warum ist TiltAngle in einem festen Raster ?

Zitat von: DS_Starter am 21 Februar 2021, 17:56:33

Die englische Hilfe gibt es noch nicht, nur die deutsche. Im global device language = DE stellt dein System auf deutsch um.
Wäre generell empfehlenswert.

Zitat von: DS_Starter am 21 Februar 2021, 17:56:33
Nein die Daten werden nach kurzer Zeit eingelesen, verarbeitet und angezeigt.
EIn list von dem SolarForecast Device hilft meistens als ersten Schritt.

Zitat von: DS_Starter am 21 Februar 2021, 17:56:33
Die Daten kommen aus einem SMAEM-Device in dem Fall. Auch hier hilft das List sicherlich weiter.

Zitat von: DS_Starter am 21 Februar 2021, 17:56:33
Zwei Dinge wären auch hilfreich, die Ausgabe von "get <> stringConfig" und die Ausgabe von "get <> pvHistory".

Zitat von: Wzut am 22 Februar 2021, 07:47:09
@Heiko, wenn es eine Matrix ist und keine Formel dann ist das eben so, nur kein Stress :)
Thema HTML Grafik : Bisher war bei allen Typen die Zeitachse : jetzt bis X (4-24) Stunden in die Zukunft.
Nun geht es aber in die Vergangenheit, soll ich für die ersten Tests diese einfach spiegeln, d.h. beginnen mit (4-24) Stunden in die Vergangenheit und Ende jetzt oder wollen wir das eleganter machen das jetzt immer genau die Mitte ist und wir x Stunden in die Vergangheit schauen und genau soviel Stunden in die Zukunft ?  Bzw. als Könisgklasse und einem zusätzlichen Attribut könnte der User auch das jetzt frei verschieben :)

Zitat von: sn0000py am 22 Februar 2021, 20:31:40
Hallo ich wollte mal das Solar_plain testen allerdings verstehe ich die werte nicht so recht.

Hier ist die Ausgabe für den heutigen Tag.
Die Dachneigung ist 28° und die Ausrichtung ist 150° - also laut der Definition -30° (sie ist Süd Ost)

Um 7 ist der Faktor 0.001 das wäre noch ok, aber dann springt er um 8 uhr auf 3.4 das ist viel zu viel

Zitatich denke er kann es besser erklären

Zitat von: KölnSolar am 22 Februar 2021, 21:47:10
Nicht wirklich.  ;)
Es liegt halt eine Funktion zugrunde, die nur für 90-270° definiert ist. Um diese Grenzen herum, liefert die Funktion irreale Werte(gegen unendlich). Typisch bei Winkelfunktionen.

Muss man leider mit leben und sich für eine Korrektur entscheiden.

Zitat von: sn0000py am 23 Februar 2021, 09:22:38
hmmm ich dachte ja auch das wenn ich mit den daten reingehe ich auch so eine kurve bekommen müsste zumindest so ähnlich

nur bei bei mir fängt die kurve mit dem Spitzenwert bei 7:52 an, davor ist die 0.01 und dann geht die kurve runter

[edit]ok ich glaube ich hatte da falsche vorstellungen, der faktor gibt nicht die kurve wieder sondern die kurve wird von DWD Wert SolarRadiation geholt - ist das korrekt?
Ich dachte die ganze zeit dieser Faktor wäre die IDealkurve wenn alles perfekt wäre

Zitat von: sn0000py am 23 Februar 2021, 10:02:35
Ok, das heisst ich brauche nun einen Wetterdienst der mir diese Daten liefert :/

alternativ die nächste mögliche Adresse in Deutschland? Wäre dann ca 30km Luftlinie
Allerdings wen ich mir so einen Bodenbeobachtungspunkt aussuchen muss dann wäre das dann ja 10895 Fürstenzell mit 43km Luftlinie.

Gibt es sonst noch Dienste die sowas liefern?

Zitat von: sn0000py am 23 Februar 2021, 11:20:28
So mit den Werten von Fürstenzell schauen die Ergebnisse mal so aus wie ich es ca erwartet habe.

Zitat von: sn0000py am 24 Februar 2021, 18:30:03
so mein erster Tag mit der Prognose lief mal durch
Ich bin noch zu hoch und auch etwas versetzt, was ist da der beste weg das zu korrigieren?

Zitat von: sn0000py am 24 Februar 2021, 20:03:48
Hab nun mal die Kurve runtergestellt, mit dme Faktor 0.75 und die Daten von Passau genommen die sind etwas näher

Wobei mir sich da die Frage stellt, wäre es nicht klüger eine Station zu wählen die zwar weiter weg ist, aber dafür am gleichen Breitengrad - oder was wären die wichtigesten daten die übereinstimmen sollten?

Zitat
Längengrad, Breitengrad, Höhe?

Zitat von: sn0000py am 25 Februar 2021, 09:05:49
Die frage mit Längengrad, Breitengrad und Höhe bezog sich auf die Wetterstation die theoretisch für mich besser wäre, also sollte ich am selben Längengrad oder am selben Breitengrad suchen. Oder ist die Höhe über dem Meer  wichtiger das die zu meinen Daten passt?

Zitat
ich muss mit dem elevation auf 0.16 gehen, damit er mir den wert auf 0 runterschaltet bei 8 uhr.
Ich glaube ich werde da dann korrekturwerte für die einzelnen Stunden hinterlegen.

Zitat
Ich habe mal die 2 Wetterdienste angehalten, damit sich die Werte nicht änderen, (beim DWD verschwinden ja dann irgendwann mal die vergangenen Rad1h werte)
dann werde ich heute abend wenn die PV ISt Kurve fertig ist, mal mit Korrekturwerten spielen.

Zitat von: sn0000py am 25 Februar 2021, 11:38:46
Ah okay die funktion hat sich geändert :D

Wäre es möglich irgendwie eine Möglichkeit zu schaffen (oder gibt es eh schon was wie man das am besten machen kann) das ich meine Werte für Cloud/rain/temperatur einspeisen kann?

Ich verwende ja die DWD DAten für die rad1h werte und den openweathermap für die restlichen Daten (Da die für meinen Standort existieren)
im moment mache ich das ganz primitv so
(Beim openweaterhmap fangen die stündlichen Daten immer bei 1 an für die aktuelle stunde)

Zitat von: sn0000py am 25 Februar 2021, 11:38:46
Ich verwende ja die DWD DAten für die rad1h werte und den openweathermap für die restlichen Daten (Da die für meinen Standort existieren)

Zitat
im moment mache ich das ganz primitv so
(Beim openweaterhmap fangen die stündlichen Daten immer bei 1 an für die aktuelle stunde)

Zitat von: sn0000py am 25 Februar 2021, 12:33:47
ok danke für die Tipps, ich werde es aber dann vermutlich doch eher mit ienem Dummy "DWD_Forecast" device machen.

Da mir die zuordnung der stündlichen werte zu umständlich wird per userreadings

DWD hat ja fix fc0_7_TTT ist immer FIX Temperatur um 7 Uhr am aktuellen Tag
beim openweatermap ist hourly_06_temp um 1 Uhr die Temperatur von 7 Uhr
und um 7Uhr dann heisst die varaible dann hourly_01_temp

Zitat von: sn0000py am 25 Februar 2021, 17:33:50
Hallo habe nun mal den aktuellen Vergleich der zwei kurven

Kann ich bei diesem zeitlichen versatz noch was optimieren?
Oder soll ich es mal so lassen?

Zitat von: DS_Starter am 01 März 2021, 16:40:06
set <> currentInverterDev ...  ?

Zitat von: DS_Starter am 01 März 2021, 16:45:52
Zusätzlich noch

set <> reset pvHistory
set <> reset pvCorrection

um historische Werte / Korrekturen zu löschen wenn nötig.

Zitat von: papa am 01 März 2021, 19:18:34
for( my $i=1; $i < 24; ++$i ) {

Zitat von: Wzut am 01 März 2021, 19:37:16
WOW , wievel machst du so im Schnitt bei völliger Dunkelheit ? :)
Ich habe etwas ähnliches, allerdings "nur" 5..22

Zitat von: Wzut am 01 März 2021, 19:37:16
WOW , wievel machst du so im Schnitt bei völliger Dunkelheit ? :)
Ich habe etwas ähnliches, allerdings "nur" 5..22

Zitat von: ch.eick am 01 März 2021, 20:19:05
Wer ist jetzt der Ketzer :-) :-)