76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Moin,

@TheTrumpeter,
das ist eigentlich überhaupt kein Ergebnis. Vermutlich hat das Training alle verfügbaren Durchläufe und Steps (max. 15000) pro Durchlauf ausgenutzt ohne ein vernürnftiges Ergebnis.
Wenn du das Trainingslog zur Verfügung stellen kannst, lohnt sich sicherlich ein Blick darauf.

Jedenfalls lautet die Empfehlung immer noch "0.4":

Das ist unverständlich da es im Code nur diese 4 Stufen gibt und kein 0.4 dabei ist:

Code Auswählen Erweitern

  if    ($score >= 3) { $flag = 'noisy';      $bfl  = 0.40; }
  elsif ($score >= 2) { $flag = 'borderline'; $bfl  = 0.34; }
  elsif ($score >= 1) { $flag = 'low';        $bfl  = 0.28; }
  else                { $flag = 'stable';     $bfl  = 0.22; }

Aber gut, das nehme ich jetzt mal so hin, ist ja nicht zuviel verlangt eine 0 anzuhängen. 

Was ich weiters nicht verstehe:
Ich habe VOR dem Training den neuen Schlüssel gesetzt:
Code Auswählen
conEnergyHourLimit=35000

Trotzdem werden mir nun Verbräuche weit jenseits dieses Limits vorhergesagt.

Die Einstellung conEnergyHourLimit verhindert ab dem Zeitpunkt des Setzens die Speicherung zu hoher Ist-Verbrauchswerte durch Fehler.
Zitat Comref:

Limitierung des maximal möglichen Energieverbrauches im Hausnetz pro Stunde (Wh).
Werte oberhalb des Limits werden durch SolarForecast als ungültig bewertet und nicht gespeichert.

Die KI verwendet die gespeicherten Rohdaten. Bei dir sind dort - wie ersichtlich - erhebliche Fehler enthalten.
Deswegen kommt das Training vermutlich zu keinem Ergebnis.

Ist aber kein unlösbares Problem.
Mit

Code Auswählen Erweitern

set ... reset aiData searchValue=con>=35000

kannst du dir zunächst anschauen welche historischen Werte größer deiner Grenze es in den Rohdaten gibt. Wahrscheinlich mehr als einer.

Die kannst du alles entfernen mit.

Code Auswählen Erweitern

set ... reset aiData delValue=con>=35000

Wenn das erledigt ist, startest du das Training neu.
Vermutlich wird es nun deutlich kürzer laufen.
Meine produktiven Trainings sind in ca. 600 Sekunden durch. (recht leistungsfähige Hardware)

LG,
Heiko

[DS_Starter]

@klaus.schauer und Peter,

danke für eure Hinweise.
Die nehme ich mit auf.

Zur Erläuterung ... im ersten Step der BEV Implementierung geht es:

- um die Aufnahme und Speicherung von sinnvollen Daten mit denen die KI in die Lage versetzt wird die Verbrauchsvorhersage anzureichern
- NICHT um die Steuerung der Wallbox durch SF, also die Beeinflussung der Ladeleistung und Zeiten

Die Steuerung durch SF würde vermutlich mit anderen Steuereinheiten (evcc) kollidieren. Aber das Thema ist zu neu für mich um bereits jetzt alles abschätzen zu können
was geht und was sinnvoll ist.
Deswegen gehen wir schrittweise vor, zunächst also die Sammlung und Speicherung relevanter Größen, Einbau eines Trainingsprofils und Training der Verbrauchsprognose.
Das setzt auch das Vorhandensein genügender Trainingsdaten mit BEV voraus die erstmal gesammelt werden müssen.
Wenn das alles klappt, kann im Step 2 auch an eine Steuerung gedacht werden. Dann liegen auch schon Erfahrungen mit dem Thema vor.

LG,
Heiko

[TheTrumpeter]

Danke.

Mit

Code Auswählen Erweitern

Code Auswählen Erweitern

set ... reset aiData searchValue=con>=35000
kannst du dir zunächst anschauen welche historischen Werte größer deiner Grenze es in den Rohdaten gibt. Wahrscheinlich mehr als einer.

Code Auswählen Erweitern

2026.03.24 08:38:45 1: mySolarForecast - AI Raw data found - idx: 2026030714 -> key=con, val=17674868344
2026.03.24 08:38:45 1: mySolarForecast - AI Raw data found - idx: 2026032017 -> key=con, val=1470478103Dabei bleibt's auch, wenn ich 10 kWh als Suchlimit eingebe.

Die kannst du alles entfernen mit.

Code Auswählen Erweitern

Code Auswählen Erweitern

set ... reset aiData delValue=con>=35000

Habe ich gemacht, aber auf 10 kWh gesetzt (war eigentlich egal, siehe oben).

Code Auswählen Erweitern

2026.03.24 08:41:46 1: mySolarForecast - AI Raw data deleted - idx: 2026030714 -> key=con, val=17674868344
2026.03.24 08:41:46 1: mySolarForecast - AI Raw data deleted - idx: 2026032017 -> key=con, val=1470478103
2026.03.24 08:41:47 1: mySolarForecast - AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_mySolarForecast

Wenn das erledigt ist, startest du das Training neu.
Vermutlich wird es nun deutlich kürzer laufen.

Habe die Debug-Ausgabe wieder eingeschaltet und gestartet.

[ahlermi]

Meine Anlage ist aktuell in der Abriegelung, im Wintermodus ist der Akku immer bei mindestens 80%.

Die Statistik zeigt jetzt nicht so direkt das aufgrund der Abrieglung nicht mehr Leistung produziert werden kann, (Inselanlage) wäre es möglich das darzustellen?

Du meinst vermutlich "Prognose" und nicht "Statistik"?
Die Problematik bei der Abregelung der Anlage ist die Frage der Abregelungsgrades. SF weiß nicht ob deine Anlage auf 0 oder einen anderen Grenzwert begrenzt wird.
Wenn es möglich wäre ´nicht nur 0 oder 1 als Indikatior von der Anlage zu bekommen, könnte ich diesen Wert als Prognosegrenzwert einetzen. Wäre das gegeben?

Werden die KI Statistiken sauber fortgeschrieben, also am besten die Stunden ignoriert?

Ja, werden sie.
Abhängig vom Ergebnis weird in aiRawData (und anderen Speichern) das Valid-Bit "pvrlvd" (nicht) gesetzt.

Es ist eine Inselanlage, es wird immer so weit abgeriegelt das nicht eingespeist wird. Völlig Dynamisch

[DS_Starter]

Es ist eine Inselanlage, es wird immer so weit abgeriegelt das nicht eingespeist wird. Völlig Dynamisch

Ja, genau deswegen weiß SF ja nicht auf welchen Grenzwert deine Anlage abgeregelt wird (für die Prognose).
Gäbe es denn in dem für 'reductionState' angegebenen Reading nicht nur 0|1 sondern den Grenzwert für die Abregelung zum Auslesen?

Edit: Naja in gewisser Weise weiß SF das schon, denn es wäre im Prinzip der aktuelle Verbrauch des Haushalts + BatIn als max. möglichen Erzeugungswert. Aber das muß ja nicht bei jeder Abregelungslogik so sein.

[DS_Starter]

In #5558 habe ich die Version 1.1 des BEV Integrationspflichtenheftes angehängt.

[klaus.schauer]

Die Steuerung durch SF würde vermutlich mit anderen Steuereinheiten (evcc) kollidieren.

Wenn man sich z. B. für evcc als Steuerungselement für die Wallbox entscheidet, nutzt man i. d. R. auch dessen Prognosefunktonen. evcc holt sich aktuelle die PV-Leistung, Informationen zur Batterie und zum Energiefluss des Hausanschlusses. Das Überschussladen kann man von extern kaum beeinflussen.

[Parallix]

ich habe mir mit dem Wissen vorangegangener Diskussionen weitere Gedanken zur BEV-Integration gemacht (ist nicht in Vergessenheit geraten) und mit Hilfe einer leistungsfähigen KI ein Pflichtenheft zur BEV Einbindung im Kontext der vorhandenen Consumer- und AI::FANN Verbrauchvorhersage erstellt.

Es ist hier angehängt und interessierte User bitte ich einen Blick darauf zu werfen und ggf. Ideen/Ergänzungen zu geben.

Die Schlüssel targetSoC und hourOfDeparture sind sicherlich als Verknüpfungen variabel. Statt hourOfDeparture würde ich timeOfDeparture verwenden. Eine Abfahrt könnte auch erst für Übermorgen geplant sein.
...

Bei mir ist es neben "Übermorgen" auch häufig in zwei oder drei Tagen.

Hatte in #4547 und davor ja auch schon einmal etwas zum Thema BEV-Ladeplanung aufgeschrieben und habe den Eindruck, dass der ein oder andere Aspekt hier nicht vergessen werden sollte.

Ein Kernelement der beim "BEV" relevanten Prozesse ist aus meiner Sicht die Berücksichtigung ggf. völlig unterschiedlicher harter und weicher Ziele für SoC und den korrespondierenden Zeitpunkt. Da diese Ziele keine KI der Welt kennen kann, muss der User diese explizit angeben, was über interaktive Dashboards realisierbar ist.

[TheTrumpeter]

Habe die Debug-Ausgabe wieder eingeschaltet und gestartet.

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 24.03.2026 10:22:15 / Laufzeit in Sekunden: 5908
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 84.48 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=16500 Wh, Hausverbrauch: Min=0 Wh / Max=6400 Wh
Trainingsdaten: 9718 Datensätze (Training=7774, Validation=1944)
Architektur: Inputs=98, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.4, BitFail-Limit=0.40
Aktivierungen: Hidden=SIGMOID, Steepness=1.2, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Period=10
Modellalter: - h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2401 (max. 15000)
Training MSE: 0.000885
Validation MSE: 0.002142
Validation MSE Average: 0.002222
Validation MSE Standard Deviation: 0.000036
Validation Bit_Fail: 0
Model Bias: 55 Wh
Model Slope: 0.9
Trainingsbewertung: Borderline

=== Fehlermaße der Prognosen ===

MAE: 144.24 Wh
MedAE: 45.95 Wh
RMSE: 189.80 Wh
RMSE relative: 57 %
RMSE Rating: acceptable
MAPE: 20.03 %
MdAPE: 10.89 %
R²: 0.89

=== Rauschen ===

Rauschen Bewertung: borderline
Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)Lustigerweise schlägt es jetzt wieder BitFail 0.34 vor, was ich vor dem Update auf die neue Version schon hatte... werde das wieder ändern und neu starten. Die Prognose sieht nun jedenfalls wieder vernünftig aus.

[DS_Starter]

Lustigerweise schlägt es jetzt wieder BitFail 0.34 vor, was ich vor dem Update auf die neue Version schon hatte... werde das wieder ändern und neu starten. Die Prognose sieht nun jedenfalls wieder vernünftig aus.

Das ist eine logische Konsquenz der jetzt sauberen/plausibleren Daten. Das vermindert das sogenannte 'Rauschen' und ermöglicht niedrigere Einstellung von BitFail. Siehe auch dazu diesen Abschnitt im Wiki.

Und die Laufzeit ist nun auch wieder völlig i.O:

Code Auswählen Erweitern

letztes KI-Training: 24.03.2026 10:22:15 / Laufzeit in Sekunden: 5908


[Wolle02]

Moin Thomas und Heiko,

Nur weil das so ähnlich ist, wie bei mir bis vor kurzem (bei PV Erzeugung stimmt der Verbrauch nicht mehr): Hast Du mal mit get ... pvHistory für die entsprechende Stunde )oder generell) geprüft, ob alle pvrl01, pvrl02 und pvrl03 plausible Werte haben? Falls wirklich was nicht passt, würde ich bei der Verteilung der PV-Leistung auf pvrl03 tippen.

Ansonsten noch der Verweis zum Wiki, den Heiko mir gegeben hatte:  Verbrauchsermittlung

danke für deine Tipps, aber die pvrl01-03 sehen mit den Werten 65, 3403 und 449 eigentlich ganz richtig aus.
Aber es ging ja auch eher um den Verbrauch als um die Produktion und da sehe ich bei pvHistory nur diese Werte:

Code Auswählen Erweitern

conlegfc: 1576, conaifc: 331, confc: 331, conbiascorr: 78, con: 939, gcons: 0Aber auch hier erkennt man, dass der festgestellte Verbrauch über 500 Wh über der Prognose liegt, obwohl der tatsächlich festgestellte Verbrauch nur bei ca. 400 Wh liegt.

Den Link zum Wiki muss ich mir mal in einer ruhigen Minute genauer anschauen.

Das kann man so nicht beantworten. Für ein Debug wäre "collectData" recht sinnvoll.
Man darf auch nicht vergessen, dass die Verlustleistung der Inverter mit eingeht, die bei hohen PV Umsätzen auch erkennbar steigt. Aber das sieht man dann.

Ist hier ein Wert von 500 Wh als Verlustleistung wirklich realistisch? Irgendwie bekomme ich so einen Wert gedanklich nicht bei mir unter, wenn ich mir am Tagesende die Werte von Produktion und Verbrauch anschaue.
Ich muss grade mal warten, bis ich wieder eine vergleichbare Situation wie gestern habe und dann versuche ich das mal mit dem Debug collectData. Aber da ist halt leider wieder das schonmal angesprochene Problem, dass diese DebugLogs eigentlich nicht handlebar sind, weil sie alle 10 sec das Logfile vollschreiben, das innerhalb kürzester Zeit riesengroß wird. Nochmal die Frage, ob man diese Debuglogs nicht in ein separates Logfile schreiben kann?
Wie lange müsste der collectData-Debug denn laufen bis man aussagekräftig was sehen kann? 1 min, 5 min, 15 min, 1 h, ganzer Tag?

[DS_Starter]

Ist hier ein Wert von 500 Wh als Verlustleistung wirklich realistisch?

Nein, natürlich nicht, aber es ist ein Bausteinchen.

Aber da ist halt leider wieder das schonmal angesprochene Problem, dass diese DebugLogs eigentlich nicht handlebar sind, weil sie alle 10 sec das Logfile vollschreiben,

Man muß sich das etwas einfacher machen.
Hier interessiert nur der Stundenwechsel. Erstelle dir zwei at-Devices.
Mit dem einen stellst du 2(3) Minuten vor einer vollen Stunde das Debug an:

Code Auswählen Erweitern

attr ... ctrlDebug collectData

Und mit dem anderen at 2(3) Minuten nach der vollen Stunde wieder aus:

Code Auswählen Erweitern

attr ... ctrlDebug none

Damit sollte das übersichtlich und auch aauswertbar sein.
Und die 10 Sec sind ja von deiner interval Einstellung abhängig -> default 70 Sec.

[tomcat.x]

Aber es ging ja auch eher um den Verbrauch als um die Produktion

Den Zusammenhang wirst Du nach dem Lesen des Wikis (nur ein Abschnitt) erkennen. In die Verbrauchsberechnung der jeweiligen Stunde geht auch die Erzeugung ein. Im aktuellen Fluss sah bei mir alles gut aus, aber für den 3. Wechselrichter gab es kein etotal, damit war pvrl zu niedrig. Besser erkennbar war aber, dass pvrl03 0 war. Erzeugt wurde aber. Dadurch war der berechnete Verbrauch zu klein.

Aber ok, bei Dir ist es das nicht.

[Gisbert]

Hallo Heiko,

ich nutze dein Modul jetzt schon seit längerem, allerdings nutze ich derzeit im Wesentlichen nur die PV-Vorhersage. An der Stelle möchte ich meinen Dank für deine großartige Arbeit und dein Engagement aussprechen.

Ich hab zwei "Großverbraucher" - eine Wärmepumpe für die Heizung, sowie eine Brauchwasser-WP für Warmwasser. Da die Wärmepumpe für die Heizung wegen der Trägheit ab ca. Mitternacht loslegt (bei jetzigen Wetterbedingungen) und morgens oder am frühen Vormittag ausgeht, und die Brauchwasser-WP morgens bis mittags/nachmittags läuft, sind die Verbrauchsprognosen in diesen Zeit etwa 2-3mal so hoch wie z.B. ab mittags bis Mitternacht.

Ich habe derzeit noch kein Attribut consumerxx gesetzt. Da ich die Wärmepumpen nicht nach der PV-Prognose oder dem Akkustand steuern will bzw. es kaum Sinn macht, sondern nach den Bedürfnissen der Bewohner, benötige ich bei den Verbrauchern nicht den Part der Steuerung. Wenn ich will, dass es tagsüber warm ist, muss ich wegen der Trägheit der FBH ab ca. Mitternacht mit dem Beheizen loslegen.

Meine Frage:
Wird die Verbrauchsprognose (special_todayConsumptionForecast_xx, special_tomorrowConsumptionForecast_xx) in Summe fürs ganze Haus besser, wenn ich für die beiden Verbraucher je ein consumer-Attribut setze? Dann würde ich es machen. Wenn sich an der Gesamtprognose für alle Verbraucher im Haus nichts ändert, dann werde ich es lieber nicht machen. Eine Bilanz der Wärmepumpen hab ich bereits an anderer Stelle.

Viele Grüße Gisbert

[DS_Starter]

Hallo Gisbert,

Wird die Verbrauchsprognose (special_todayConsumptionForecast_xx, special_tomorrowConsumptionForecast_xx) in Summe fürs ganze Haus besser, wenn ich für die beiden Verbraucher je ein consumer-Attribut setze? Dann würde ich es machen. Wenn sich an der Gesamtprognose für alle Verbraucher im Haus nichts ändert, dann werde ich es lieber nicht machen.

Wahrscheinlich wird sich die Prognose - wenn auch nicht sofort - verbessern. Insbesondere mit KI wird es Auswirkungen haben. Wenn ich dich richtig verstanden habe, betreibst du sogar 2 WP?
Auch wenn der Erfolg nicht so eindeutig sein wird, du vergibst dir dadurch nichts. WP allgemein werden durch SF nicht gepöant oder gesteuert, nur ausgelesen und gespeichert.