76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Wolfdieter,

Ab wann wird AI result genutzt und wann nicht?
Die Werte von 7 und 8 Uhr sind 8 Tage alt. Einmal Ai und einmal nicht.

Das kommt darauf an, ob die verwendete KI ein Ergebnis liefert oder nicht.
Für die PV-Vorhersage wird (noch) AI::DecisionTree verwendet. Das ist kein neuronales Netz wie das für
die CON-Prognose verwendete FANN. Es arbeitet nach der Methode von Entscheidungsbäumen und ist nicht so in der Lage zu lernen wie FANN.
AI::DecisionTree will ich aber ablösen und auch diese Prognose auf FANN umstellen. Wenn das erledigt ist, basiert alle KI-Unterstützung im Modul einheitlich auf dem neuronalen Netz FANN. Diese Implementierung wird dann vermutlich nicht mehr so aufwändig sein wie die Verbrauchsprognose, da ich auf bereits erarbeiteten Code und Wissen zurückgreifen kann.

LG,
Heiko

[300P]

Hallo Heiko !

hab ich grad erst  entdeckt - du machst Dörrobst

dehydrator - Verbraucher ist eine Dörrmaschine (z.B. Trockengerät für Obst)

[DS_Starter]

Ja, ein kleines Gerät für die Küche. Äpfel und andere Dinge für Müsli usw. 

[Prof. Dr. Peter Henning]

Also ->> Es müsste dann ja jede Minute einmal der Wert  in dem jeweiligen Modus addiert werden der sich aus aktueller Modulation am Minutenende und bei dem jeweiligen aktuellen Modus zum Minutenende ergibt....?

Das Problem ist hier die Asynchronität der einzelnen Messungen - "einmal pro Minute" heißt nicht, dass alle notwendigen Messwerte zur gleichen Zeit ankommen.

LG

pah

[Wolle02]

Hallo Heiko, ich habe jetzt auch mal versucht mit der KI zu optimieren und scheinbar ist es jetzt auch laut dem internen Berater ok, nur das Lernverhalten empfindet dieser als nicht ok, obwohl die KI sagt, dass es gut wäre. Vielleicht müsste man das mal die Systeme untereinander ausdiskutieren lassen 

Laut KI "verrauscht" scheinbar nur die BEV-behandlung das Modell. Folgendes hat mit die KI als Endergebnis und Empfehlung ausgespuckt:

Meine Empfehlung

Ich würde jetzt tatsächlich aufhören, die FANN-Parameter weiter zu optimieren.

Der beste Parametersatz scheint momentan zu sein:

aiConSteepness=0.6
aiConHiddenLayers=48-24
aiConBitFailLimit=0.35
aiConMomentum=0.4
aiConLearnRate=0.001
aiConActivate=1
aiConActFunc=SIGMOID
aiConTrainStart=3:3
aiConTrainLimit=9000
aiConProfile=v1,bev,pv
aiConTrainAlgo=INCREMENTAL
Was ich stattdessen untersuchen würde

Mich würde jetzt viel mehr interessieren:

Wie sieht die Prognose an Tagen ohne BEV-Ladung aus?
Wie sieht die Prognose an Tagen mit BEV-Ladung aus?
Welche Features liefert aiConProfile=v1,bev,pv eigentlich konkret ins Netz?

Ich habe den Verdacht, dass die Prognose des reinen Haushaltsverbrauchs bereits ziemlich gut ist und das BEV den gesamten Datensatz "verrauscht".

Falls das SolarForecast-Modul eine Möglichkeit bietet, die Wallboxleistung oder ein "BEV lädt"-Flag als separates Feature einzuspeisen, könnte das deutlich mehr bringen als jede weitere Änderung von Hidden Layers oder Lernrate.

[DS_Starter]

Moin,

Laut KI "verrauscht" scheinbar nur die BEV-behandlung das Modell.

Nun ja, ganz verkehrt ist das nicht. Wir haben zwar schon eine ganze Anzahl an Informationen rund um EV der KI bereitsgestellt,
aber ob das ausreicht wird erst die Zeit zeigen. So wäre es für die KI hilfreich wenn Verhaltensmuster erkennbar wären, also
der EV wird typischerweise jede Nacht geladen oder vorwiegend an bestimmten Tagen/Uhrzeiten usw.
Die eingebauten Features geben das her, ob der Haushalt so gleichfürmig tickt oder eher stochastisch, steht auf einem anderen Blatt.

alls das SolarForecast-Modul eine Möglichkeit bietet, die Wallboxleistung oder ein "BEV lädt"-Flag als separates Feature einzuspeisen, könnte das deutlich mehr bringen als jede weitere Änderung von Hidden Layers oder Lernrate.

Das wäre noch eine mögliche Maßnahme. Es gibt über die aktuell verbrauchte Energiemenge des Consumers einen Hinweis über die Hintertür, aber ein binäres Element 0|1 wäre mal zu testen.

LG,
Heiko

[300P]

Also ->> Es müsste dann ja jede Minute einmal der Wert  in dem jeweiligen Modus addiert werden der sich aus aktueller Modulation am Minutenende und bei dem jeweiligen aktuellen Modus zum Minutenende ergibt....?

Das Problem ist hier die Asynchronität der einzelnen Messungen - "einmal pro Minute" heißt nicht, dass alle notwendigen Messwerte zur gleichen Zeit ankommen.

Hallo pah,

du hast völlig recht, die Asynchronität der Messergebnisse ist messtechnisch bei FHEM-Devices schon immer eine der Herausforderungen.

Ja – penibelst genau auf die Millisekunde ist das vielleicht nicht, aber es ist um Magnituden genauer als alles vorher. Modulierende Wärmepumpen springen in diesen relativ kleinen Zeiträumen ja auch nicht permanent von 0 auf 100 %.

Wenn am Minutenende die Werte um einige Sekunden versetzt eintreffen, entsteht ein minimaler Jitter. Das ist ein bekanntes Problem der zeitlichen Diskretisierung, das man über ein einfaches ,,Sample-and-Hold"-Verfahren (das Modul rechnet mit dem jeweils letzten gültigen Zustand) so einigermaßen gut im Griff hat. Über die 60 Minuten einer Stunde hinweg gleicht sich dieser asynchrone Fehler statistisch n.m.M. so doch fast vollständig aus.

Würden wir stattdessen nach dem alten Dominanz-Prinzip (der längste Modus in der Stunde gewinnt) vorgehen, hätten wir bei jedem Moduswechsel einen massiven, systematischen Fehler. Wenn z. B. 25 Minuten intensiver Warmwasserbetrieb komplett unter den Tisch fallen, nur weil in dieser Stunde 35 Minuten sanftes Heizen dominierten, trainiert das der AI:FANN völlig falsche Kausalitäten zwischen Außentemperatur und Modus-Leistung an.

Daher ist der gewichtete Minuten-Punktwert trotz asynchronem Rauschen der mathematisch sauberere Weg für die Historie – und das, ohne das FHEM-System (und meinen kleinen Raspberry Pi) unnötig stark zu belasten.

Inwieweit Heiko das am Ende bei der Programmierung bis auf die Sekunde ausreizt, überlasse ich naturgemäß ihm. Soweit ich das im Code gesehen habe, nutzt er intern sogar schon die Sekunden je Modus, was das Problem der Asynchronität ohnehin dann elegant sehr sehr stark minimiert.

[dieter114]

Hallo Zusammen,
ich hab leider immer noch das Problem mit OpenMeteoDWD_D2-API.
Wenn ich auf direkt auf DWD gehe, kommen die FC Werte stündlich ohne Probleme
bei der OpenMeteoDWD_D2-API ist ganz oft die Anzeige oben Rechts Rot.
Allerdings sind die OpenMeteo Werte eindeutig besser für meine Lage.
Die nächste (passende) DWD Station ist ca 10km Luftlinie entfernt, das ist doch eigentlich nicht zuviel.
Woher die OpenMeteoDWD_D2-API seine Werte bezieht bzw. berechnet weis ich nicht.
Nur der Forecast ist damit sehr gut. Im Schnitt 1% bis max 4-5% Abweichung.
Bei DWD habe immer über 10-15% Abweichung.