76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

okay - gebe mich geschlagen...   

[DS_Starter]

siehe mein Edit ... Patt würde ich sagen 

[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]

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

[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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

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

[Wolle02]

Nach dem ich nun mit den Einstellungen gefühlte 20-mal "retrain" als Empfehlung hatte, wird mir heute kein Retrain mehr empfohlen und ein "gesundes Lernverhalten" attestiert.

aktuell habe ich folgende Einstellungen:

Code Auswählen Erweitern

Normierungsgrenzen: PV=8140 Wh, Hausverbrauch: Min=0 Wh / Max=11459 Wh
Trainingsdaten: 4694 Datensätze (Training=3755, Validation=939)
Architektur: Inputs=49, Hidden Layers=15-10, Outputs=1
Hyperparameter: Learning Rate=0.0003, Momentum=0.6, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID, Steepness=0.5, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_pv
Zufallsgenerator: Mode=1, Period=10
Modellalter: -0 h
Mal schauen wie sich das jetzt auf die CON-Prognose auswirkt.

[300P]

gefühlte 20-mal "retrain"

Aha - Willkomen bein "Berufs-Retrainern"

[DS_Starter]

Hallo zusammen,

heute hat sich bei mir ein anschauliches Verbrauchsbild ergeben, in dem man die Arbeitsweise des KI Modells recht gut erkennen kann.
Man sieht heute 3 Spots. Alle drei sind verursacht durch nicht vorhersehbare Nutzng von Waschmaschine, Trockner und Backofen. Für die KI sind das externe Störungen, die in der Prognose ausgeglichen werden sollen. Diesen Ausgleich machen Features wie rollierende Durchschnitte, Lags, Delta- und Spikeerkennung. Die Driftlogik kommt mit diesen Sprüngen nicht klar, dafür ist sie nicht gemacht. Die Rekalibrierung wird geblockt und ist in dieser Situation gewünscht. Ansonsten würde die Grundverbrauchsprognose nach oben ausbrechen, was aber wegen des temporären Charakters der Störung nicht richtig wäre. Ein Retraining werde ich nicht vornehmen, da es kein Driftverhalten gibt, sondern die Störung verursachende Faktoren bekannt sind. 

Im Cluster 1 erfolgt ein Verbrauchspeak 8:00 und wird 9:00 mit einer entsprechend angehobenen Prognose neutralisiert. Die Stunde 10 erhält wieder das normale Prognoselevel. Der Cluster 2 (11:00-12:00) sieht genauso aus. In beiden Fällen wird das Normalmaß wieder sehr schnell eingepegelt.

Im Cluster 3 dauert die Störung länger von 15:00-18:00. Hier wurde gebacken. Auch hier steuerte die Logik dagegen, braucht aber etwas länger um wieder zu normalisieren.

Der hier gezeigte Verlauf führt bis jetzt zu einer kumulativen Abweichung von 10,5%. Zum Vergleich zeigt meine parallele SF-Instanz mit der Legazy-Prognose heute eine Abweichung von 46,4%. Das ist kein Statement gegen meine Legacy-Verbrauchsprognose, die ebenfalls i.A. sehr gut funktioniert. Aber auf die heutigen Herausforderungen kann sie einfach nicht adäquat reagieren, das ist nicht möglich.

Um z.B. den Einsatz von WaMA/Trockner für die KI besser vorhersagbar zu machen, müsste man Features einbauen die mit der Nutzung korrelieren. Anzuführen wäre zum Beispiel eine permanente Gewichtserfassung des Schmutzwäschekorbs. Die KI würde lernen, ab welchem Level (ggf. in Verbindung mit Wochentag oder PV-Erwartung bei Auswahl des PV-Profils) die Wahrscheinlichkeit der Gerätenutzung steigt und in die Prognose einbeziehen. Aber wer macht das schon. 

Das NN kann insgesamt schon recht viel, aber Hellsehen geht leider noch nicht.      

Das gezeigte Verhalten ist mit meiner aktualisierten V 2.7.0 erstellt, die aber noch nicht zur Nutzung in das Contrib geladen wurde. Ich baue noch etwas ein, dann stelle ich die V zur Verfügung.

LG,
Heiko

[Gisbert]

Hallo Heiko,

man könnte statt Wäschekörbe und den Mehlvorrat zu wiegen , Verbrauchsmessungen für den Backofen/Herd, Waschmaschine und Trockner installieren. Das ist im Zählerschrank mit etlichen TE verbunden, sowie erheblichem Verdrahtungsaufwand. An der Verbrauchsstelle könnte man auch messen, aber das ist aus Platzgründen auch nicht schön.
Mit gewissen Unzulänglichkeiten muss man wohl leben. Vor ein paar Jahren gab es jährliche Ablesung des Zählers, mehr nicht.

Viele Grüße Gisbert

[DS_Starter]

  ... naja, der Punkt ist wenn man das macht - was absolut hilfreich ist - kennt die KI nur den Wert des Verbrauchsbeitrages des Consumers am Gesamtverbrauch. Sie kann dann den Wert der Verbrauchserhöhung genauer vorhersagen. Aber die KI kann immer noch nicht den Zeitpunkt vorhersagen, WANN der Verbraucher wahrscheinlich benutzt wird. Das ist das Hauptproblem ... auch bei BEV usw.
Deswegen braucht man weitere, mit diesem Verbraucher korrelierende Triggerwerte. Dann wird es leichter und genauer.