76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[klaus.schauer]

In der letzten Woche war meine Wärmepumpe auf "Abwesend" geschaltet. Erwartungsgemäß lagen die KI-Verbrauchsprognosen trotz presence=0
heftig daneben. Die Prognosen verbesserten sich erst zum Ende der Woche. Inzwischen haben sie sich wieder normalisiert.

Wäre es nicht gut, wenn man statt des festen Parameters comforttemp=<temp> eine setupEnvironment-Variable mit der aktuellen Raumsolltemperatur verwenden würde? Damit könnte man im Normalbetrieb die Nachtabsenkung signalisieren. Eine "Abwesenheit" würde für die Wärmepumpe dann auch über die Absenktemperatur angezeigt. Die presence-Variable muss nicht immer kausal mit einer Absenkung der Raumsolltemperatur zusammenhängen. U. U. lernt der KI-Algorithmus so schon durch die tägliche Nachtabsenkung auch das Verbrauchsverhalten bei einer längeren Abwesenheit.

[DS_Starter]

Hallo Klaus,

In der letzten Woche war meine Wärmepumpe auf "Abwesend" geschaltet. Erwartungsgemäß lagen die KI-Verbrauchsprognosen trotz presence=0 heftig daneben.

Das erscheint logisch da presence erst seit kurzer Zeit aufgezeichnet wird und die historischen Trainingsdaten bei presence=undef als presence=1 gemappt werden (müssen).
D.h. es gibt keine/wenige Trainingsdatensätze mit presence=0 zumal die Daten in Training und Validation geteilt werden. Etwas Abhilfe könnte ein Shuffle-Mode ohne chronologisches Splitting (aiConShuffleMode=2 der default) bringen. Der hat aber wiederum den Nachteil dass zeitliche Strukturen verloren gehen.

Wäre es nicht gut, wenn man statt des festen Parameters comforttemp=<temp> eine setupEnvironment-Variable mit der aktuellen Raumsolltemperatur verwenden würde?

comforttemp ist ja die Solltemperatur (Komforttemperatur) in den Wohnräumen.

Mit:

Code Auswählen Erweitern

set <name> attrKeyVal ConsumerXX comforttemp=<temp>

jederzeit über ein at/norify whatever dynamisch setzen.

LG,
Heiko

[DS_Starter]

@Peter,

im contrib liegt die V2.1.1.
Ich habe einen Lunker gefunden und beseitigt. Bitte teste auch diese Version.
Natürlich kann jeder andere die V ebenfalls nutzen.

LG,
Heiko

[peterboeckmann]

Moin Heiko!

im contrib liegt die V2.1.1.

ich hab die Version gezogen, teste mal und werde berichten.
Es geht um die RestOfDayPVForecast, oder?

Viele Grüße,
Peter

[DS_Starter]

Moin,

ja, darum geht es. In dem Zusammenhang habe ich die gesamte Summierungsfunktion, in der noch weitere Werte generiert werden, refakturiert.

LG,
Heiko

[Parallix]

Na dann nutze mal die V2.1.0 aus dem contrib. Genau an dieser Stelle habe ich etwas nachgearbeitet wie du aus den letzten Beiträgen erkennen kannst.
...

Hinsichtlich der "PV Abweichung" gibt es mit o.g. Version (bei mir) jetzt keine Auffälligkeiten mehr. Danke!

[Parallix]

...

Die letzten zwei sonnigen Tage haben ausgereicht, um mein EV bis zur eingestellten Grenze zu laden. Da es in SF leider noch kein Feature gibt, einen Verbraucher (hier ein an der Wallbox hängendes EV, was über ein Reading erkennbar ist) bei der Ladeplanung dynamisch zu berücksichtigen oder unberücksichtigt zu lassen, wird dieser Verbraucher täglich von SF geplant. Da so ein EV alles andere als einen verschwindenden Verbrauch hat, wird in einem solchen Fall der Hausspeicher viel zu schnell geladen.

@Heiko: Hast Du Dir meine Rückmeldung (#5092) zu Deiner bereits in #5073 andiskutierten Lösungsidee näher angesehen?

[DS_Starter]

@Heiko: Hast Du Dir meine Rückmeldung (#5092) zu Deiner bereits in #5073 andiskutierten Lösungsidee näher angesehen?

Habe ich noch nicht. Wurde wegen der anderen Dinge abgelenkt.
Danke dass du mich daran erinnerst.

[peterboeckmann]

Hallo Heiko,

In dem Zusammenhang habe ich die gesamte Summierungsfunktion, in der noch weitere Werte generiert werden, refakturiert.

ich glaube, das Thema kannst Du jetzt ad acta legen. Das sieht echt gut aus jetzt:
Du darfst diesen Dateianhang nicht ansehen.
Die braune Linie (Prognose bis jetzt) geht schon super nah an die grüne Linie (Erzeugung bis jetzt). Ich kann Dich nur zur Qualität dieser Prognose beglückwünschen!


Die letzte Feinheit, die man evtl. nochmal untersuchen könnte, sind die im Screenshot markierten kleinen Sprünge in der bisherigen Prognose.

Ich habe dazu folgende Vermutung: Die Prognose der jeweils aktuellen Stunde wird mit jedem Prognoselauf angepasst.
Dadurch ändert sich auch der zum Rest der aktuellen Stunde gehörende Anteil der Prognose am Rest des Tages. Klar.
Aber - und hier wird meine Vermutung schwammig - die Prognose für die aktuelle Stunde dürfte sich eigentlich nur noch um einen gewissen Anteil der Stundenprognose ändern, der dem zeitlichen Rest der Stunde entspricht.

Kleine Zahlenbeispiel:
Die Prognose für die Stunde zwischen 11 und 12 Uhr sei um 11 Uhr mit 940 Wh berechnet.
Um 11:50 Uhr läuft die Prognose erneut und passt den Wert für die Stunde zwischen 11 und 12 Uhr auf 1060 Wh an.
Da aber 50/60 der Stunde schon rum sind, sollte die Prognose für die Stunde zwischen 11 und 12 Uhr nur um 10/60*(1060-940)=20 Wh, also auf 970 Wh steigen.

Das zu ändern ist bestimmt nicht mit geringem Aufwand machbar. Und die Auswirkung wäre dafür sehr klein.
Daher kann das wahrscheinlich vernachlässigt werden.

Viele Grüße,
Peter

[DS_Starter]

Hallo Peter,

Aber - und hier wird meine Vermutung schwammig - die Prognose für die aktuelle Stunde dürfte sich eigentlich nur noch um einen gewissen Anteil der Stundenprognose ändern, der dem zeitlichen Rest der Stunde entspricht.

Kleine Zahlenbeispiel:
Die Prognose für die Stunde zwischen 11 und 12 Uhr sei um 11 Uhr mit 940 Wh berechnet.
Um 11:50 Uhr läuft die Prognose erneut und passt den Wert für die Stunde zwischen 11 und 12 Uhr auf 1060 Wh an.
Da aber 50/60 der Stunde schon rum sind, sollte die Prognose für die Stunde zwischen 11 und 12 Uhr nur um 10/60*(1060-940)=20 Wh, also auf 970 Wh steigen.

Es gibt im Modul die unterschiedlichsten Methoden, Prognosen für die jeweiligen Werte zu berechnen oder zu ermitteln. PV, Consumption, Ladezustand der Batterien und diverse Werte die sich in den special-Readings niederschlagen.
Nicht jeden Wert kann man minutengenau bzw. zeitgewichtet ermitteln, zumindest nicht mit vertretbaren Aufwand der nicht auch die Übersicht über die Logik zerstört.
Grundsätzlich verwende ich im Modul das 1-Stundenraster. Die Wetterlieferanten/API's liefern ihre Werte in der 1-Stundenauflösung. Das FHEM DWD Device ebenso. Dementsprechend normiere ich unsere selbst gemessenen Werte wie SOC, Energieverbrauch der Consumer o.ä. ebenfalls in das 1-Stundenraster.
Man sieht es an den Readings wie z.B. Today_HourXX_.*. Bei manchen Werten errechne ich eine Zeitgewichtung über die laufende Stunde. Das ist aber genau genommen eine Verallgemeinerung. Denn wer sagt denn, dass eine Änderung der PV Prognose der laufenden Stunde sich auf die letzten verbleibenden 15 Minuten bezieht und nicht auf die vergangenen 30 Minuten wenn die Prognose für die gesamte laufende Stunde gilt?
Es gibt also keinen Grund das so anzunehmen.
So gesehen ist eine teilweise vorgenommene Zeitgewichtung nur eine verallgemeinerte Annahme oder Schätzung, die auf einer angenommenen Gleichverteilung einer PV-Erzeugung oder des Hausverbrauches über die Stunde beruht. Diese Annahme wird in der Realität aber nur in seltenen Fällen zu 100% zutreffen. D.h. selbst wenn es gelingen würde die kleine Stufe in der Grafik programmtechnisch "wegzuglätten", hat es für uns - außer einer ästhetischen Komponente - keine oder nur sehr minimale Auswirkungen, die mir momentan aber auch nicht einfallen würden.
Ich glaube da gibt es aktuell wichtigere und interessantere Dinge die uns auch messbare Vorteile bringen können wenn ich sie hinbekomme. 

LG,
Heiko