76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

300P

Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

DS_Starter

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wolle02

Gibt es eigentlich eine Möglichkeit die "Nachzieheffekte" bei der Verbrauchsprognose zu beeinflussen oder zu beschränkten?

Bei mir hat das immer mal wieder den Effekt, dass wenn ich einen unvorhersehbaren, unplanbaren oder in der Logik noch nicht abbildbaren hohen, punktuellen Verbrauch habe, dann steigt in der Verbrauchsprognose der Prognosewert für die folgenden Stunden ebenfalls. Siehe Bild 1.
Dies wiederum führt dazu, dass das die Differenz der PV-Prognose und der Verbrauchsprognose geringer wird als die Realität eigentlich hergibt. Siehe Bild 2 (oben PV-Prognose, unten Verbrauchsprognose)
Das hat wiederum zur Folge, dass der Wert des Readings 'Battery_ChargeOptTargetPower_01', das ich zur Laderegelung meiner Batterie einsetze, nicht mehr zutreffend ist, sondern die Ladung meiner Batterie mit pinmax freigibt, woraufhin die Batterie mit der Maximalleistung vollgeladen wird und eventuell schon Mittags voll ist und dann bis zum Abend auf 100% steht. Das läuft eigentlich dem Ansinnen der Laderegelung von 'smartPower' zuwider.

DS_Starter

#6363
Die Antwort ist eindeutig Jaein.

Der von dir beschriebene Sachverhalt ist Teil der grundlegenden Logik. Sogenannte Lags und rollende Durchschnitte geben dem NN Hinweise.
Vereinfacht, wenn es höhere (niedrigere) Verbäuche als vorgesagt in Stunde X gibt, ist die Wahrscheinlichkeit hoch, dass Stunde Y auch etwas davon abbekommt.
Allerdings wird das NN, wenn es in Stunde Y wieder einen gegenteiligen Verbrauch festtellt, seine Vorhersage für die kommenden Stunden wieder revidieren. (sieht man bei dir in den Stunden 06-08)

Bei mir sieht man es auch. Allerdings ist bei dir die Auswirkung "nach hinten" deutlicher ausgeprägt. Möglicherweise weil 13:00 der Verbrauch nicht nur höher, sondern drastisch höher ausgefallen ist.
Hinzu kommt auch, dass ich bei mir bereits einen Weiterentwicklung aktiviert habe, die zusätzliche Features in den Lags eingebaut hat.
Ich werde mir noch ein paar Gedanken machen, welche zusätzlichen Maßnahmen hier evtl. helfen können.
Aber wenn ich das nächste Update zum Test freigebe, kannst du es gern mal bei dir einbauen ob sich dann evtl. schon Verbesserungen ergeben.

Welches Profil und welche Einstellung für aiConActFunc setzt du ein? Am Besten die ganze aiControl mal posten.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wolle02

Hallo Heiko, klar probiere ich die nächste Contrib-Version gerne aus.
Als Profil verwende ich aktuell v1_common_pv
aiConActFunc habe ich nicht gesetzt; demzufolge müsste der Default=SIGMOID greifen.

Die ganze aiControl sieht aktuell so aus:
aiConBitFailLimit=0.34 aiConMomentum=0.8 aiConLearnRate=0.0005 aiConActivate=1 aiConTrainStart=3:3 aiConTrainLimit=4700 aiConProfile=v1_common_pv aiConTrainAlgo=INCREMENTAL aiConSteepness=1.2 aiConHiddenLayers=50-25

DS_Starter

Das Profil v1_common_pv ist gut wenn du Geräte aktiv bei PV Erzeugung steuerst, also WaMA/Trockner und andere Geräte aktivierst wenn Überschuß vorhanden ist.
Es sollte dann der übrwiegende Leistungsanteil im Haushalt sein. Hintergrund: FANN würde dann lernen, dass bei PV Erzeugung/Überschuß der Verbrauch hochgeht.
Wenn das nicht der Fall ist und du "nur" eine PV Anlage hast, dann eher auf v1_common oder v1_common_active ausweichen.

aiConMomentum=0.8 und aiConSteepness=1.2 sind zwar insgesamt ok, aber verstärken die Dynamik und könnten dadurch dein beobachtetes Verhalten fördern.

Bei mir war heute Mittag eine ähnliche Situation eingetreten. In der Stunde 12 ein starker Mehrverbrauch durch Kochvorgänge der in der Stunde 13/14 zu erhöhter Prognose führte, die aber ab 15:00 wieder auf Standardlevel ist.

Meine Einstellungen sind diese:

aiConTrainStart=7:3
aiConHiddenLayers=50-25
aiConTrainAlgo=INCREMENTAL
aiConLearnRate=0.003
aiConMomentum=0.3
aiConSteepness=0.7
aiConShuffleMode=1
aiConActivate=1
aiConAlpha=1
aiConShufflePeriod=20
aiConActFunc=SIGMOID
aiConProfile=v1,active
aiConBitFailLimit=0.22
aiConTrainLimit=0

Das nur zur Info und soll nicht zur direkten Übernahme animieren, muß ja zum Haushalt passen. Mit der kommenden contrib Version kannst du ein verändertes Profil, aiConMomentum und/oder aiConSteepness ausprobieren.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wolle02

Danke für die Erläuterungen. Das Profil mit v1_common_pv passt dann bei mir eigentlich ganz gut, weil wir tatsächlich versuchen die Verbraucher anhand des Überschusses zu fahren.

Die Schlüssel aiConMomentum und aiConSteepness habe ich aufgrund der Vorschläge im Berater eingestellt. Ich habe jetzt aiConMomentum=0.6 und aiConSteepness=0.5 eigenstellt und schaue was sich verändert.