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.

[DS_Starter]

Hallo zusammen,

im contrib liegt ein Update der V 2.7.0.
Zur Übersicht nachfolgend die wichtigsten Infos zum Inhalt dieser Version. Es ist bereits viel zusammengekommen.
Deswegen wird es ein bedeutendes Minor-Release:

- der von WDS gemeldete Boot-Fehler ist behoben (#6291)

- die Ausgaben bzw. Exporte der pvHistory können gefiltert werden

- Die Verbrauchsprognose FANN ist um weitere synthetische Features erweitert (bisher in sandbox zum Test enthalten)

- Codeverbesserungen in der Trainingslogik (Snap-Guard und Retrainidicator)

- Weiterentwickllung und Korrekturen im FANN Hinweissystem ("Berater" für die FANN-Einstellungen)

- das Reading Tomorrow_ConsumptionForecast ist entfernt (Tomorrow_CONforecast anstatt verwenden)

- Wichtig: Umstellung aiControl->aiConProfile auf Flags. Bei einer Neudefinition braucht man nur noch die Eigenschaften des
  Haushalts mit einfachen Flags wie pv,heatpump anzugeben. Das richtige Profil wird intern synthetisiert.
  Ihr braucht aber nichts anzupassen, die bisherigen Profile behalten ihre Gültigkeit bis zu einer Neueingabe.
 
- attr ConsumerX: Beim Ändern eines Consumers wird der Fingerprint identitätsbestimmender Schlüssel (type, switchdev, opmode)
  geprüft und ggf. das vorherige Löschen des Consumers und neu Anlegen requestet, z.B.:
 
  "Das Ändern des Geräts oder eines der identitätsbestimmenden Schlüssel (type, switchdev, opmode) eines bestehenden Verbrauchers
  ist nicht zulässig. Dies würde stillschweigend historische Daten (pvHistory) und bereits für 'consumer03' aufgezeichnete
  KI-Trainingsdaten beschädigen, da diese Daten nur anhand der Verbrauchernummer und nicht anhand der Geräteidentität indiziert sind.

  Bitte zunächst das Attribut 'consumer03' löschen (dadurch wird dessen Verlauf sicher entfernt) und erneut mit dem neuen Gerät bzw.
  den neuen Schlüsseln definieren. Die Verbrauchernummer kann unmittelbar danach wiederverwendet werden."
 
 
- in pvHistory und aiRawData werden nun die kumulativen Run-Minuten der Wärmepumpen-Modi
  getrennt nach Modus -> csmXX_(off|heating|defrost|hotwater|cooling|pool|poolheating)_minutes registriert und gespeichert.
  Dazu gibt es einen neuen Schlüssel aiControl->opmode für Consumer "heatpump"
  Hinweis: ähnlich wie bei BEV ist das nur erstmal eine Datensammlung. Effektiver Einbau in das KI-Training erfolgt später
           wenn wir bereits Daten gesammelt haben
         
- es können nun mehrere Consumer vom Typ "heatpump" erstellt werden


Durch ergänzende Features in der KI Verbrauchsprognose gibt es bei dieser Version Strukturänderungen.
Aus diesem Grund wird in den meisten Fällen ein Retraining erforderlich sein.

LG,
Heiko

[Burny4600]

Ich habe eine Frage zum Attribut setupWeatherDev*.

Bei mir erscheint immer wieder eine Warnung mit Bezug auf setupWeatherDev.
Liegt das daran, weil ich zwei Definitionen gemacht habe, oder an deren Reihenfolge?

Code Auswählen Erweitern

setupWeatherDev1 OpenMeteoDWDEnsemble-API
setupWeatherDev2 DWD_KR

[DS_Starter]

Moin Chris,

die Warnung kann berechtigt sein.
Hier wird das Alter der DWD Wetterdaten im Reading

 fc_time
   
des DWD-Devices ausgewertet. Ist es zu alt (bei MOSMIX_S mehr als 2 Stunden) kommt die Warnung.
Vergleiche die Einstellung des DWD Devices mit den Anforderungen.
Für MOSMIX_S sollte die Einstellung forecastRefresh=1 im DWD-Device sein.

Möglicherweise verzögert sich der Datenempfang mit dem DWD Device bei dir tatsächlich (Fehler etc.). Dann schauen ob das behoben werden könnte.

LG,
Heiko