Leistungsprognose für Wechselrichter

[dk3572]

Hallo Heiko,
die Vorhersagen werden immer besser und genauer. Großes Lob hierfür.
Nur was bringt mir das, wenn ich wegen der Rad1h Werte eine Station verwenden muss, die 30 km von meinem Standort entfernt ist?
Die Wetterdaten stimmen dann ja nicht wirklich und verfälschen die ganze Sache.
Gibt es hierfür tatsächlich keine andere Möglichkeit?
Evtl. nur den Rad1h Wert aus der entfernten Station, Rest vom aktuellen Standort?
Oder sehe ich das falsch? Wie machen das die anderen?
VG Dieter

[DS_Starter]

Moin Dieter,

wenn die Wetterstation soweit entfernt ist dann hilft nur eins ... umziehen. 

Spass beiseite, einen solchen Split habe ich bisher nicht bedacht. Allerdings wäre es natürlich eine Variante die Quellen Devices für Strahlung und Wetter zu trennen und den Setter dafür aufzubohren.
Es gab ja schon ein paar mehr Meldungen hier, dass User keine Rad1 Daten von Stationen in unmittelbarer Nähe fanden.

Gibts weitere Meinungen dazu ?

Grüße,
Heiko

[papa]

Macht es vielleicht Sinn, den Mittelwert mehrerer Stationen, die um den eigentlichen Ort liegen, zu verwenden ?

[ch.eick]

Macht es vielleicht Sinn, den Mittelwert mehrerer Stationen, die um den eigentlichen Ort liegen, zu verwenden ?

Ich habe das für Einstrahlungswerte für die Rollo Steuerung so gemacht. Abgefragt werden drei Stationen und der Wert wird einfach rechnerisch geglättet.
Das könntest Du beim DWD Device auch machen und einfach einen Dummy dazwischen schalten, der die geglätteten Werte dann für den Forecast bereit stellt.

VG
   Christian

[DS_Starter]

Bei den DWD Devices habe ich bisher keine Dummy Möglichkeit vorgesehen. Hier kann der User nur vorhandene DWD Devices auswählen. Ist halt eine Frage die Devices für Rad1 und die Bewölkung etc zu trennen oder zum Beispiel die Möglichkeit einzubauen zwei DWD Devices anzugeben und diese dann aber gleichberechtigt zu behandeln und Durchschnitte zu bilden.

[ioT4db]

Bei den DWD Devices habe ich bisher keine Dummy Möglichkeit vorgesehen. Hier kann der User nur vorhandene DWD Devices auswählen. Ist halt eine Frage die Devices für Rad1 und die Bewölkung etc zu trennen oder zum Beispiel die Möglichkeit einzubauen zwei DWD Devices anzugeben und diese dann aber gleichberechtigt zu behandeln und Durchschnitte zu bilden.

Moin,
ich hab auch das Problem, dass die nächste Rad1-Station ca. 50km entfernt ist und dementsprechend sich das "restliche" Wetter von meinem Standort oftmals stark unterscheidet. Ich würde dann lieber die Stationen trennen können, also eine für die Rad-Werte und eine für den Standort der Solaranlage.
DWD-Stationen gibts genug, nur die mit den Rad1h-Werten sind rar gesät.

VG...

[DS_Starter]

Eine Trennung finde ich persönlich auch besser, da die Strahlungswerte perspektivisch auch von dem Dienst SolCast kommen könnten.

[dk3572]

Uiiii, da hab ich aber was los getreten 

Ich fände die Trennung auch besser.

[DS_Starter]

ok. werde die Tage mal in Richtung Trennung Rad1 und restlicher Wetterdaten aufbohren.

[DS_Starter]

Moin zusammen,

eine neue V liegt im contrib. In Stichpunkten was neu ist:

* die Setuptexte sind in deutsch/englisch in Abhängigkeit von der Einstellung global language

* zur Trennung Wetter- und Strahlung DWD Device gibt es den neuen Setter currentRadiationDev. Der bisherige Setter
  currentForecastDev übernimmt nur noch die Wetterdaten. Bei wem Wetter und Strahlung aus dem gleichen Device kommen
  gibt bei beiden Settern das gleiche Device an.
Nach Aktivierung des neuen Moduls müsst ihr den neuen Setter ausführen.

* es wird eine Verbrauchsschätzung des Hauses für den folgenden Tag erstellt (Reading Tomorrow_Consumption). Dazu werden
  die historischen Verbrauchsdaten gleicher Wochentage herangezogen. d.h. für einen Sonntag wird der Durchschnitt
  vergangener Sonntage herangezogen, f. Dienstag der Wert vergangener Dienstage etc.
  Damit wird einem tagestypischen Verbrauchsverhalten (z.B. an Wochenenden) Rechnung getragen.
  Die Erstellung erfolgt aber erst nach Ablauf von mindestens einer Woche weil ein vergangener Wochentag in der pvHistory
  enthalten sein muß. (Schlüssel 99=>con).

* es gibt einen neuen Getter forecastQualities. Er zeigt die zu erwartenden Qualitäten der PV Vorhersage und die effektiv
  verwendeten Korrekturfaktoren für jede Stunde an.


Frage ... spricht aus eurer Sicht etwas dagegen das currentMeterDev auch im Guided Setup verpflichtend zu machen ?
Die Funktionen werden immer mehr abhängig von einem vorhandenen Meter und die meisten User dürften ja irgendein Meterdevice haben.
Wer keines hat, könnte dort ja ein Dummy mit Dummy-Readings und "0" angeben.

Ich würde es gern tun.
Wie steht ihr dazu ?

Grüße,
Heiko

[Chris46]

Danke für dein unermessliches Engagement.

Zur Verbrauchsabschätzung: Für Wärmepumpen wäre eine Betrachtung der Außentemperatur noch hilfreich. Die Wetterdaten wären in dem DWD Device ja schon vorhanden. Klar um das gut abschätzen zu können braucht eine gewisse Datenbasis.
Was in dem Zusammenhang natürlich auch noch interessant ist: Laden von E-Fahrzeugen erhöhen auch den Hausverbrauch. Diese werden wahrscheinlich nicht immer am gleichen Wochentag geladen und verfälschen die Vorhersage erheblich. Allerdings weiß ich noch nicht wie man das berücksichtigen könnte. Ggf. über die Einbindung der Wallbox?

[DS_Starter]

Danke für dein unermessliches Engagement.

Gerne, bräuchte nur mehr Zeit.    Und gebe den Dank auch gleich weiter an Wzut der sich immer um die Grafik kümmert. 

Zur Verbrauchsabschätzung: Für Wärmepumpen wäre eine Betrachtung der Außentemperatur noch hilfreich. Die Wetterdaten wären in dem DWD Device ja schon vorhanden. Klar um das gut abschätzen zu können braucht eine gewisse Datenbasis.

Die Temperatur mit einzubeziehen hatte ich vor. Dazu soll das DWD Device TTT in den forecastProperties enthalten, was ich auch jetzt schon prüfe.
Alledings hatte ich bisher noch keine sinnvolle Anwendung dafür gesehen. Ich werde jetzt die Datenerhebung dafür mit integrieren.
Wie würde man diese Temperaturdaten dann in Bezug auf Wärmepumpen  verwenden ? Das ist mir gerade nicht klar.

Was in dem Zusammenhang natürlich auch noch interessant ist: Laden von E-Fahrzeugen erhöhen auch den Hausverbrauch. Diese werden wahrscheinlich nicht immer am gleichen Wochentag geladen und verfälschen die Vorhersage erheblich. Allerdings weiß ich noch nicht wie man das berücksichtigen könnte. Ggf. über die Einbindung der Wallbox?

Das ist natürlich ein guter Einwand.
Wir hatten "früher" die Möglichkeit zu monitorende Verbraucher über ein Attribut einzubinden und deren geplante Zeiten in der Grafik per Icon zu signalisieren.
Ich könnte mir vorstellen solche Großverbraucher per Attr hineinzunehmen und deren Verbrauch separat auszuweisen und aus dem Hausverbrauch auszuklammern.
Dazu müßte diese Wallbox in FHEM irgendeine Device Instanz haben die brauchbare Werte für diesen Zweck liefert.
Wie sieht es denn damit aus ?

[DS_Starter]

Hallo,

übernehmt bitte die weiterentwickelte v0.38.0 aus meinem contrib.
Intern sind weitere Details für den zukünftigen Consumption Forecast hinzugekommen.
Das kann schonmal im Hintergrund mitlaufen und den Store füllen.
Das gilt ebenso für die Temperaturwerte pro Stunde (NextHours).

[papa]

Haben jetzt folgenden Fehler

Code Auswählen Erweitern

reload: Error:Modul 76_SolarForecast deactivated:
"addCHANGED" is not exported by the FHEM::SynoModules::SMUtils module
Can't continue after import errors at ./FHEM/76_SolarForecast.pm line 43.
BEGIN failed--compilation aborted at ./FHEM/76_SolarForecast.pm line 43, <$fh> line 3075.

2021.04.18 20:47:29 0: "addCHANGED" is not exported by the FHEM::SynoModules::SMUtils module
Can't continue after import errors at ./FHEM/76_SolarForecast.pm line 43.
BEGIN failed--compilation aborted at ./FHEM/76_SolarForecast.pm line 43, <$fh> line 3075.


[DS_Starter]

Dann hast du kein aktuelles FHEM, insbesondere nicht die Biblio FHEM::SynoModules::SMUtils.
Aber ich brauche momentan addCHANGED nicht mehr und habe es gerade wieder rausgenommen.
Zieh die V nochmal bitte.