76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

aiNeuralNetConState empfiehlt aiConBitFailLimit=0.4

Bist du sicher dass 0.4 und nicht 0.40 empfohlen wurden?
Wenn doch, dann war es ein Artefakt. In der aktuellen Version ist die Empfehlung immer zweistellig nach dem Komma (0.XX).
Ich werde es aber nochmal im Code sicherstellen.

Zu 99% sicher... das neue Training läuft immer noch (seit bald 7h... so lange hat es mit Abstand noch nie gebraucht), drum kann ich nicht nachschauen.

In der aktuellen Version ist die Empfehlung immer zweistellig nach dem Komma (0.XX)

Gelernt wurde noch mit der alten Version, ausgelesen habe ich aber jedenfalls mit der neuen Version.
Unabhängig davon, auch wenn die Empfehlung künftig immer Hundertstel angibt, erschließt sich mir als Mathematiker nicht, warum der Syntax-Check nicht auch Zehntel akzeptiert. Ich hab' grad mal "0.4x" probiert um auszuschließen, dass es nur um die Anzahl an Zeichen ginge, was aber auch nicht akzeptiert wird. Entsprechend läuft da ja ohnehin schon irgendeine Plausibilisierung. Lt. Commandref ist zulässig: "0.05 .. 0.50". Warum also nicht einfach den Schlüssel auslesen und prüfen, ob mathematisch korrekt "0.05 <= Schlüssel <=0.5" erfüllt ist?

[dieter114]

Hallo Heiko,
nur kurze Rückmeldung:
Nachdem ich den Fehler in der Config beseitigt hatte ist die Abweichung soll/ist schon nach einem Tag <8%.
Das sind unglaublich gute Werte.

Und noch ein Hinweis:
Im Grafik Kopfbereich steht rechts "PV Abweichung heute....." und "CO Abweichung fortlaufend...."
Mach doch bitte aus dem CO mal ein CON für Consum...
Das ist nicht so verwirrend wenn jemand das erste Mal draufschaut.

LG WDS

[300P]

@TheTrumpeter

Das wird schon so im Programmcode gemacht:

Code Auswählen Erweitern


aiConBitFailLimit  => { comp => '0\.(0[5-9]|[1-4]\d|50)',                                    act => 0 },



[tomcat.x]

ich hätte mal eine Frage zur Darstellung der Verbrauchswerte; und zwar nicht zur Verbrauchsvorhersage, sondern zur Darstellung des realen Verbrauchs.

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

Viele Grüße
Thomas

[DS_Starter]

Hallo Wolle02,

Das passt mit 397 Wh eigentlich ganz gut.
Warum wird bei den blauen Balken für den realen Verbrauch bei Stunde 12 dann 918 Wh angezeigt?

Jetzt ist die Frage was tatsächlich real war und wann das etotal der beteiligten Geräte upgedated wird.
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.

Edit: Überschneidung ...jetzt erst den Beitrag von tomcat.x gelesen ...
 

[DS_Starter]

Mach doch bitte aus dem CO mal ein CON für Consum...

Gerne, kein Problem.

[DS_Starter]

Gerade noch gelesen ...

Ich hab' grad mal "0.4x" probiert um auszuschließen, dass es nur um die Anzahl an Zeichen ginge, was aber auch nicht akzeptiert wird.

Also zum Beispiel:

Code Auswählen Erweitern

aiConBitFailLimit=0.44  oder
aiConBitFailLimit=0.40  etc.
wird problemlos akzeptiert.
Geprüft wird mit Regex wie 300P schon geschrieben hat.

[Elektron]

Hallo zusammen,

Zunächst vielen, vielen Dank DS_Starter für das Tolle Modul!!!

Ich habe seit einigen Monaten das Problem, dass mein FHEM immer wieder (unregelmäßig, aber meistens Nachts) blockiert.
Ich stoppe dann den FHEM-Service über die Console und starte ihn neu, danach ist wieder alles gut.

Rudolf gab mit dem Tip zu sehen welches Modul nach dem ,,Abschießen" im Log steht.
Habe ich jetzt mal gemacht und die letzten Minuten stehen nur Einträge aus dem SolarForecast im Log.
Kann es sein, dass das Modul blockiert? Ich verwende SolarForecast schon sehr lange, bisher immer ohne Auffälligkeiten.


Hier der Auszug aus dem Log:
2026.03.22 19:36:31 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:36:33 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:37:04 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:37:35 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:38:06 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:38:08 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:38:39 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:39:10 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:39:39 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:39:41 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:40:12 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:40:42 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:41:11 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:41:13 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:41:44 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:42:15 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings

Vielen Dank und Grüße Michael

[DS_Starter]

Hallo zusammen,

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.

LG,
Heiko

[DS_Starter]

Hallo Michael,

man soll zwar niemals nie sagen, doch ich glaube nicht daran dass SF der unmittelbare Verursacher ist.
Alle API-Abfragen sind non-Blocking ausgeführt und die Geräteabfragen / Datensammlungen werden durch Auslesen von Readings realisiert und nicht durch die direkte Geräteabfrage. Das ist Aufgabe der Gerätemodule.

Problematisch können Schaltvorgänge von Verbrauchern sein, was aber hier nicht der Fall zu sein scheint.

Die Meldung:

Code Auswählen Erweitern

SolarPrognose_getdata return value: Data cycle triggered, watch readings

Ist die Rückmeldung der SF-Zentralschleife, d.h. zu diesem Zeitpunkt ist alles schon durch und erledigt.

Die Meldung:

Code Auswählen Erweitern

Wechselrichter_getdata return value: There are still path commands in the action queue
Ist mir unbekannt und wird nicht von SF generiert. Das muß eine Rückmeldung deines WR Gerätemoduls sein.

Ich schlage dir vor dass du das Special Reading special_runTimeCentralTask aktivierst:

Code Auswählen Erweitern

attr ... ctrlSpecialReadings runTimeCentralTask

Dieses Reading liefert die die Zeit eines gesamten Schleifenzyklus von SF mit allen darin enthaltenen Zeiten für Abfragen etc (im Bereich 0.2-0.3 s bei mir). Die Zeiten kannst du loggen (File oder DB) und später auswerten (SVG, DbRep). Dann siehst du ob und wann evtl. Probleme aufgetreten sind.

Falls du jetzt schon weist dass du irgendwelche Verbraucher aktiv schaltest, wäre das eine heiße Spur wenn die relevanten Gerätemodule beim Schalten des Consumers durch Warten auf das Schaltergebnis blockieren.

Edit: Ich vergaß zu erwähnen, dass SF in regelmäßigen Abständen die modulinternen Datenstrukturen in das Filesystem schreibt. Sollte dein Filesystem Probleme haben, wäre das eine mögliche Blockierungsquelle. 

LG,
Heiko

[DS_Starter]

Zur Vorgehensweise bei Blockierungsanalysen habe ich jetzt einen Abschnitt im Wiki hinterlegt.

LG,
Heiko

[TheTrumpeter]

Bist du sicher dass 0.4 und nicht 0.40 empfohlen wurden?
Wenn doch, dann war es ein Artefakt. In der aktuellen Version ist die Empfehlung immer zweistellig nach dem Komma (0.XX).
Ich werde es aber nochmal im Code sicherstellen.

Der Lernprozess ist gestern nach 10h dann doch noch abgeschlossen worden, wenngleich's bei dem Ergebnis Schade um jedes Watt dafür war, siehe anbei...

Jedenfalls lautet die Empfehlung immer noch "0.4":

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 23.03.2026 19:27:43 / Laufzeit in Sekunden: 36950
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 94.76 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=16500 Wh, Hausverbrauch: Min=0 Wh / Max=1911621534 Wh
Trainingsdaten: 9697 Datensätze (Training=7757, Validation=1940)
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: 10 h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 14460 (max. 15000)
Training MSE: 0.000000
Validation MSE: 0.044375
Validation MSE Average: 0.044375
Validation MSE Standard Deviation: 0.000000
Validation Bit_Fail: 2
Model Bias: -11213 Wh
Model Slope: -0.0
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 9928981.28 Wh
MedAE: 46865.15 Wh
RMSE: 19758743.31 Wh
RMSE relative: 5924661 %
RMSE Rating: very bad
MAPE: 16687.34 %
MdAPE: 10280.69 %
R²: -0.00

=== Rauschen ===

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

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: fresh_model
Slope recalibrated: -
Bias recalibrated: -
letzte Rekalibrierung: -
Was ich weiters nicht verstehe:
Ich habe VOR dem Training den neuen Schlüssel gesetzt:

Code Auswählen Erweitern

conEnergyHourLimit=35000
Trotzdem werden mir nun Verbräuche weit jenseits dieses Limits vorhergesagt.
(Abgesehen davon liegen meine echten Verbräuche in den letzten Wochen immer unterhalb 5 kWh. Ich kann nicht ausschließen, dass es einzelne "Fehlanzeigen" gab, zumindest habe ich bei der "CO Abweichung" verzeinzelt Werte jenseits der Zig-Tausend Prozent gesehen. Warum diese offensichtlichen Fehlwerte durch den neuen Schlüssel aber nicht "weggebügelt" werden, verstehe ich nicht.

Ich setze den Wert mal auf 15 kWh runter und starte das Training nochmal. Andere Empfehlungen

[klaus.schauer]

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 der Ladefreigabe benötigt eine Wallbox Vorgaben zur Leistung oder dem Ladestrom. Dabei gibt es bei den mir bekannten Geräten folgende technische Abhängigkeiten.
Der Ladestrom kann zwischen 6 A und 16 A bzw. 32 A in 1er Schritten gewählt werden. Abhängig davon, ob 1 oder 3 Phasen genutzt werden, ist die Mindestleistung ca. 1380 W oder 4140 W. Dies ist beim dem Schwellwert currChargePower zu berücksichtigen.
Bei neueren Wallboxen kann man die Anzahl der genutzten Phasen im Betrieb über ein API-oder Modbus-Kommando ändern. So kann man recht granular die Leistungsaufnahme von 1380 W bis 11040 W bzw. 22080 steuern. Dabei ist zu beachten, dass in Deutschland bei einphasigem Betrieb max. 16 A eingestellt werden dürfen.

Konkret für das Modul bedeutet das, dass des drei Steuergrößen geben sollte
- Betrieb: EIN/AUS
- Strom: 6 - 16 / 32
- Phasenanzahl: 1, 3

Alternativ könnte das Modul auch nur die Ladeleistung vorgeben. Dann müsste man noch eine externe Steuerlogik haben.

Falls es Wallboxen geben sollte, denen man unmittelbar die Ladeleistung vorgeben könnte oder man auch Wallboxen ohne Phasenumschaltung einbinden wollte, wäre eine externe individuelle Steuerung wahrscheinlich sogar die bessere Lösung.

[peterboeckmann]

Hallo Heiko,

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.

auch ich habe mir das Pflichtenheft angesehen und (zusätzlich zu denen von klaus.schauer) nur diese eine Anmerkung:
Der Standardwert des targetSoC sollte 80% sein. Das wird i.d.R. für längere Batterielebensdauer empfohlen.

Zu klaus.schauers Anmerkung mit der Einstellbarkeit:
Meine Wallbox (und sicher mehrere andere auch) unterstützt die Einstellung des Ladestroms in Schritten von 0,1 A.
Ich kann mir vorstellen, dass andere Wallboxen auch die Ladeleistung als Sollwert entgegennehmen.
Da dies sicher je Wallbox individuell ist, gehe ich da mit der Idee von klaus.schauer, lediglich die Ladeleistung vorzugeben.

Viele Grüße,
Peter

[300P]

Wow !!

Normierungsgrenzen: PV=16500 Wh, Hausverbrauch: Min=0 Wh / Max=1911621534 Wh


Max Verbrauch = 1.911.621.534 Wh =>> Atommeiler in der Nähe ?