76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[peterboeckmann]

Hallo Heiko,

@Shadow3561, @peterboeckmann,

euch würde ich raten ein Training zunächst mit dem KI-Standardwerten auszuführen und dann erneut das Ergebnis zu bewerten.

das habe ich gestern abend mal mit folgender Konfiguration getan:

Code Auswählen Erweitern

attr SolarForecast aiControl aiTrainStart=3 aiStorageDuration=18250 aiTreesPV=30 aiConActivate=1 aiConProfile=v1_common_active_pv
Das Bild der Verbrauchsprognose hat sich dabei nicht wirklich verbessert:

Du darfst diesen Dateianhang nicht ansehen.

Ich werde aus MAE und MedAE nicht wirklich schlau. Die liegen angeblich unter 200Wh. Der hier prognostizierte Verbrauch von 11 kWh nach Mitternacht ist unrealistisch und in der Vergangenheit auch gar nicht oder höchst selten vorgekommen.
Warum denkt das NN dann, dass die Vorhersage so genau ist (MAE: 180.37 Wh, MedAE: 79.75 Wh)?

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 05.03.2026 22:35:01 / Laufzeit in Sekunden: 1568
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 19.72 ms
Verbrauchernummer Wärmepumpe: -

=== Modellparameter ===

Normierungsgrenzen: PV=11440 Wh, Hausverbrauch: Min=0 Wh / Max=15960 Wh
Trainingsdaten: 7691 Datensätze (Training=6152, Validation=1539)
Architektur: Inputs=69, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steepness=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 2530 (max. 15000)
Training MSE: 0.000306
Validation MSE: 0.000402
Validation MSE Average: 0.000356
Validation MSE Standard Deviation: 0.000007
Validation Bit_Fail: 0
Model Bias: 159 Wh
Model Slope: 0.9
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 180.37 Wh
MedAE: 79.75 Wh
RMSE: 221.29 Wh
RMSE relative: 31 %
RMSE Rating: good
MAPE: 21.46 %
MdAPE: 11.16 %
R²: 0.92

=== Rauschen ===

Rauschen Bewertung: borderline
Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: 4.29
Drift RMSE ratio: 3.95
Drift Slope: 0.118
Drift Bias: 4.17
Drift Bewertung: none

Schade, dass ich die Begeisterung über die Genauigkeit der Verbrauchsprognose nicht teilen kann, die andere hier im Thread schon geäußert haben.

Vielleicht hat ja jemand einen Tipp (oder eine Art Leitfaden), wie ich bei der Konfiguration des NN am besten vorgehe?

Vielen Dank und viele Grüße,
Peter

[TheTrumpeter]

Hab' grad einen Fehler in der Anzeige des "Rest-PV" Wertes in der Kopfzeile gefunden...

Der dort angezeigte Wert stimmt nicht mit der Summe der Balken-Werte überein, siehe Screenshot.
(Selbst wenn noch der ganze Wert von 16-18 Uhr verwendet würde und nicht nur anteilig ab 16:11 Uhr, ist es viel zu viel...)

Gerade wieder nachgerechnet...
Rest heute lt. Kopfzeile: 59438
Rest heute lt. Balken: 58060
Differenz ca. so groß wie die aktuelle Stunde, ev. wird die aktuelle Stunde doppelt berücksichtigt? 1x mit der kompletten Vorschau und 1x mit dem Rest der aktuellen Stunde? 59438 lt. Kopfzeile, 58060 lt. Balkensumme ab 07:00, Differenz=1378
Der Screenshot ist von 07:02, die Prognose für die aktuelle Stunde ist 1450. 1450 anteilig auf 58 Minuten ergeben 1401.
Gestern wäre die Differenz auch ungefähr der Restwert der aktuellen Stunde gewesen: 4636 lt. Kopfzeile, 2620 lt. Balkensumme, Differenz=2016
Der Screenshot war von 16:12, die Prognose für die aktuelle Stunde war 2520. 2520 anteilig auf 48 Minuten ergeben 2016Wh.

Beim Verbrauch scheint es ähnlich zu sein, wenngleich aufgrund der ähnlichen Stundenwerte nicht so klar ist ob die vergangene Stunde noch dabei ist oder die aktuelle Stunde annähernd doppelt. (6743 lt. Kopfzeile, 6413 lt. Balkensumme ab 07:00)

[peterboeckmann]

@TheTrumpeter,

welche Version des Moduls benutzt Du? Seit v2.1(?) steht die Versionsnummer im Kopf, bei Dir fehlt die.

In der aktuellen Version 2.2.3 passen die Restwerte zusammen, ich habe es gerade nachgerechnet.
Die Version ist seit heute im regulären Update enthalten.

Viele Grüße,
Peter

[peterboeckmann]

Hallo Marco,

Code Auswählen Erweitern

setupInverterDev01 OpenDTU_2370752 pvOut=summe_PVdirekt:W capacity=800 etotal=yieldtotal:kWh strings=Ost,West
setupInverterDev02 OpenDTU_2370752 pvOut=summe_PVbat:W capacity=800 etotal=yieldtotal:kWh strings=SüdGarage,SüdGarten feed=bat
setupInverterStrings SüdGarage,SüdGarten,Ost,West

was mir an Deiner Konfiguration auffällt:
Beide Inverter haben eine capacity von 800 W. Ist das so richtig? Oder hast Du nur einen Inverter mit insgesamt 800W max. Ausgangsleistung?
Genauso bei etotal: Hier müssten vermutlich zwei getrennte Zählerstände konfiguriert werden.
Und: Ist das Reading yieldtotal am OpenDTU_2370752 tatsächlich in kWh oder liefert der Wh?

Viele Grüße,
Peter

[TheTrumpeter]

welche Version des Moduls benutzt Du? Seit v2.1(?) steht die Versionsnummer im Kopf, bei Dir fehlt die.

Habe die hier: 76_SolarForecast.pm:v2.0.0-s30783/2026-01-25

Lese hier eigentlich mit und habe keinen Änderungshinweise dazu gesehen, deshalb auch noch kein Update gemacht... aber dann mach' ich das mal, dann sollte es ja weg sein.



NACHTRAG: Nach dem Update scheint es zu passen, zumindest gerade eben. Werde das weiter beobachten.

[erwin]

Hi,
könntest du da mal eonen Blick drauf werfen?
Mir ist nicht klar, wo diese "krummen" Werte herkommen, von Input oder im Modul durch eine Division?
Jedenfalls sollten Integer-werte für die Anzeige reichen.
l.g. erwin
Du darfst diesen Dateianhang nicht ansehen.

[peterboeckmann]

Hallo erwin,

das Problem wurde gestern in #5236 schon das erste Mal gemeldet und inzwischen auch schon korrigiert.
Wenn Du ein fhem-Update machst, kommen keine neuen Dezimalzahlen mehr dazu.

War ne Menge los seit gestern hier im Thread... 

Viele Grüße,
Peter

[erwin]

ich habe ein update heute auf 2.2.3 gemacht, allerdings erst nachdem das Problem aufgetreten war...
Sorry erwin

[DS_Starter]

@Daniel,

Irgendetwas muss die Berechnung im Modul durcheinander bringen.
Oder übersehe ich etwas?

In den ermittelten Hausverbrauch gehen etliche Werte/Readings von diversen FHEM Devices ein. Siehe Wiki.
Es ist sehr wichtig, dass du dir diese Quellen genau anschaust, ob die Erfordernisse die das Modul an diese Daten stallt auch erfüllt werden.
Also die richtigen Größenordnungen, Units, Kontunuität und solche Dinge. Ich fasse es unter dem Begriff Datenqualität zusammen.
SF kann schon eine Menge wegfiltern, aber wenn die Datenqualität schlecht oder unzuverlässig ist, kann das beste Modul und die beste KI nichts
brauchbares liefern. Schau dir also die besagten Quellen genau an was die liefern.
Du kannst als Hilfe ctrlDebug=collectData,consumption verwenden.

LG,
Heiko

[DS_Starter]

Hallo Peter,

nicht verzweifeln, für die Einstellung der KI braucht man durchaus mal Geduld.

Ich werde aus MAE und MedAE nicht wirklich schlau. Die liegen angeblich unter 200Wh. Der hier prognostizierte Verbrauch von 11 kWh nach Mitternacht ist unrealistisch und in der Vergangenheit auch gar nicht oder höchst selten vorgekommen.
Warum denkt das NN dann, dass die Vorhersage so genau ist (MAE: 180.37 Wh, MedAE: 79.75 Wh)?

Die Kennwerte MAE / MedAE beziehen sich auf die erreichten KPI im Training bezogen auf die Testdatensätze.

Die erreichten Kennwerte im Training sehen wirklich gut aus. Aber natürlich ist das Ergebnis als solches schlecht.

Ich würde hier die KI selbst bemühen um die Ergebnisse bewerten zu lassen. Sicherlich gibt es einen Grund dafür.
Die Vorgehensweise wäre:

- ctrlDebug=aiProcess einschalten
- das Training durchlaufen lassen
- nach dem Training das Trainingslog, die Metrikergbnisse und ein Screenshot des Balkendiagramms an ein LLM deiner Wahl (z.B. MS Copilot im Edge) zu übergeben
  mit etwa folgendem Text:

  Ich benutze das FHEM Modul SolarForecast mit AI::FANN zur Prognose meines Energieverbrauchs.
  Die erreichten Kennwerte erscheinen sehr gut zu sein, das Ergebnis der Prognose ist jedoch unrealistisch insbesondere .....
  Anbei ist das Trainingslog, die erreichten Kennwerte und die Visualisierung. Ich möchte eine Bewertung und Vorschläge zur Verbesserung.

Damit bekommst du sehr wahrscheinlich Hinweise zur Verbesserung der Einstellung. Sie sind manchmal mit Vorsicht zu genießen und auch nicht in jedem Fall stimmig weil
die KI auch nicht alles wissen kann was hier schon eingebaut/passiert ist.

Du kannst diese Dinge auch hier posten und ich kann dann auch eine Analyse laufen lassen. Das meiste steht ja schon da, nur das Log des Traings fehlt.

LG,
Heiko

[300P]

Vielleicht hat ja jemand einen Tipp (oder eine Art Leitfaden), wie ich bei der Konfiguration des NN am besten vorgehe?

Vielen Dank und viele Grüße,
Peter

Spiel doch mal etwas mit den Parametern und schau was dann prognostiziert wird.

Ich habe bestimmt mehr als 20 (eher 80) Berechnungen in den letzten 30 Tagen durchgeführt.

Hier (nur als Beispiel !!!) meine Werte.

Code Auswählen Erweitern

aiConActivate=1
aiConAlpha=0.9
aiConTrainStart=30:3
aiConActFunc=GAUSSIAN_SYMMETRIC
aiConHiddenLayers=80-40
aiConLearnRate=0.001
aiConMomentum=0.6
aiConShuffleMode=1
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConProfile=v1_heatpump_active_pv
aiConBitFailLimit=0.18

Als erstes nutze aiConBitFailLimit und stelle es jeweils auf 0.05 / 0.15 / 0.25 jeweils und lasse es 1 Tag laufen.
Das was am besten zum realen Verbrauch passt MERKEN und lassen.
Dann spiele mit dem aiConAlpha rauf und runter.
Auch da MERKEN was besser ist und lassen.
Erst danach dann all die anderen mal versuchen und immer schauen ob es besser oder schlechter wird.

Es dauert halt manchmal etwas ehe man sieht wie das ,,System" regariert.😉

[DS_Starter]

Hallo Marco,

Code Auswählen Erweitern

setupInverterDev01 OpenDTU_2370752 pvOut=summe_PVdirekt:W capacity=800 etotal=yieldtotal:kWh strings=Ost,West
setupInverterDev02 OpenDTU_2370752 pvOut=summe_PVbat:W capacity=800 etotal=yieldtotal:kWh feed=bat
Ergänzung zu den Bemerkungen von Peter in #5283 ->
Problem ist hier bei setupInverterDev02 der Schlüssel pvOut=summe_PVbat:W.
Das Reading summe_PVbat enthält offensichtlich nicht nur den Anteil der PV-Erzeugung, sondern ebenfalls die Ausgabe der Batterie.
Entweder hast du ein anderes Reading zur Verfügung, oder du must dir ein userReading erzeugen welches nur die PV-Erzeugung enthält.
Die Einstellung von setupBatteryDev01 wäre auch noch relevant/interessant.

LG,
Heiko

[Parallix]

Hallo erwin,

das Problem wurde gestern in #5236 schon das erste Mal gemeldet und inzwischen auch schon korrigiert.
Wenn Du ein fhem-Update machst, kommen keine neuen Dezimalzahlen mehr dazu.

War ne Menge los seit gestern hier im Thread... 
...

Auch die Skalierung arbeitet in der Version 2.2.3 nicht korrekt, wie man bei der  Verbrauchsprognose in der angefügten Grafik deutlich sehen kann.

@Heiko: Hast Du denn auch die bislang doch korrekt funktionierende Skalierung angepackt?

PS: Wegen Tests sind die Werte für die CO-Abweichung bei mir aktuell nicht aussagekräftig.

[300P]

Hallo Heiko,

wie wäre es, auch die Driftkennzahlen der letzten XX Tage noch mit in den Datenspeichern abzulegen ?

==>>damit man sich daraus eine kleine Grafik für deren Tendenz / Entwicklung / Ampel erstellen kann ?

=== Drift-Kennzahlen ===

Drift Score: 2.35
Drift RMSE ratio: 3.89
Drift Slope: 0.792
Drift Bias: 1.78