76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Könnte es sein das im setupInverterDevXX eines Reading (im WR-Device zusammengesetztes Userreading) durch addieren von BEV-Verbrauch oder PV-Erzeugung irgendwie künstlich erhöht ?

Wenn damit gemeint ist, ob SF die in setupInverterDevXX angegebenen Readings nicht nur liest sondern diese Readings auch beschreibt, kann ich es absolut verneinen.

[300P]

Nein - nicht schreibend - das wäre ja fatal wenn SF das einfach mal so machen würden 

Ich meinte damit, das die bereitgestellten Readings IM Fronius-WR schon "mehr als nur allein die Verbräuche" evtl. bereitstellen würden.   

EDIT:
 z.B. etotal = ........

[DS_Starter]

Achso  ... das kann ich dir nicht sagen, kenne Fronius WR bzw. das Modul dazu nicht.

[DS_Starter]

Im AI Status Popup gibt es nun einen Bewertungsüberblick. Alle anderen Bereiche sind per default zugeklappt und können bei Bedarf geöffnet werden.

-> contrib

[dieter114]

Hallo 300P,

Ich blicke aber bei seinem Fronius-WR leider nicht so ganz durch 

Das Ganze sieht folgendermassen aus:
1 Fronius Inverter mit Batterie und zusätzlich 2*2kW Growatt WR über ein zusätzliches Fronius Smartmeter angeschlossen.
Nur so ist es möglich alle relevanten Daten auch ins Fronius Solarweb zu bekommen und die zusätzliche PV
Energie auch in die Batterie zu laden. Fronius kann das.
Für meine eigenen ElectricityCalculatoren Bezug,Erzeugung,Einspeisung und Hausverbrauch nehme ich teilweise
Userreadings aus dem Fonius Modul weil nur so stabil gleichlaufende saldierende Zähler dafür zu erhalten sind.
Das ist aber alles nur auf der Erzeugerseite, hat also mit Verbrauch nichts zu tun.
Die BEV-Werte kommen per MQTT2 aus dem evcc System und die Poolpumpe liefert eh eigene Werte.
Also ein totol überhöhter Verbrauch ist und war nie vorhanden.
Lösungsvorschlag: Kann ich nicht einmal alle "historischen" Werte dazu löschen (Wie ?)
Die CON Werte werden bei mir noch nicht zu irgendwelchen Steuerungen herangezogen
eben weil sie bisher so unplausibel waren.

LG Wolfdieter

[Burny4600]

Ich habe leider das Projekt schon längere Zeit nicht mehr verfolgt.
Mir ist jetzt aber ein Log-Eintrag betreffend ctrlUserExitFn aufgefallen.

LOG

Code Auswählen Erweitern

2026.05.18 12:19:13.019 1: AB_WS_SS - ERROR executing userExitFn: Can't use an undefined value as a SCALAR reference at ./FHEM/76_SolarForecast.pm line 34874.

Hat sich betreffend ctrlUserExitFn an der Schreibweise etwas geändert?

ctrlUserExitFn

Code Auswählen Erweitern

{
# ::batSocChargeMgmnt ($name);         ### Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
# return;
 
  ::dishControl ($name, '02', 250);    ### EG-Küche Geschirrspüler

  ::washControl ($name, '03', 120);    ### EG-Wirtschaftsraum Waschmaschine
  ::dryControl  ($name, '04',  90);    ### EG-Wirtschaftsraum Trockner 

  ::dishControl ($name, '05', 250);    ### OG1-Küche Geschirrspüler
  ::washControl ($name, '06', 210);    ### OG1-Küche Kombi-Waschmaschine

  ::pumpControl ($name, '07', 180);    ### AB-Pool Zirkulationspumpe
}

[peterboeckmann]

Hallo Heiko,

ich habe ein Phänomen, das ich mir aktuell nicht erklären kann.

Aktuell sind beide Batterien voll geladen und es steht ausreichend PV-Überschuss zur Verfügung.
Trotzdem wird für beide Batterien ein SoC zum Ende der aktuellen Stunde von ca. 89% prognostiziert.
Siehe Screenshot anbei.
Die oberen Balken beinhalten pvReal und pvForecast, die unteren Balken conReal und conForecast.

Hast Du eine Idee, woran das liegen könnte?

Ich nutze aktuell die v2.6.9 aus dem Repository, keine contrib-Version.

Vielen Dank und viele Grüße,
Peter

[300P]

Für meine eigenen ElectricityCalculatoren Bezug,Erzeugung,Einspeisung und Hausverbrauch nehme ich teilweise
Userreadings aus dem Fonius Modul weil nur so stabil gleichlaufende saldierende Zähler dafür zu erhalten sind.
Das ist aber alles nur auf der Erzeugerseite, hat also mit Verbrauch nichts zu tun.
Die BEV-Werte kommen per MQTT2 aus dem evcc System und die Poolpumpe liefert eh eigene Werte.
Also ein totol überhöhter Verbrauch ist und war nie vorhanden.
Lösungsvorschlag: Kann ich nicht einmal alle "historischen" Werte dazu löschen (Wie ?)

Kannst du mal genau schauen (zeigen) ob die Werte vom 'EM-Meter' wirklich durchgehend sauber aufsteigend in deinem DBLog/LogFile vorhanden sind ?

Vor allem diese 2 Werte
- contotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh
- feedtotal=Meter_0_EnergyReal_WAC_Minus_Absolute:Wh

Code Auswählen Erweitern

attr Forecast setupMeterDev Fronius_Symo gcon=Bezug:W contotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh gfeedin=Einspeisung:W feedtotal=Meter_0_EnergyReal_WAC_Minus_Absolute:Wh conprice=0.30:€ feedprice=0.083:€



Löschen ->>> momentan 100 % nein - erst die Ursache finden warum die Sprünge kommen.....

[300P]

Mal nebenbei:

Aktuell habe ich fast CON-Trainings seit ein paar Tagen mit sch.... Ergebnissen bekommen.....   😤🤬😭😱🤔🤦 

Insgesamt 14 Trainingläufe mit verschiedensten Einstellung haben mich dann heute nach Tagen wieder auf ein einigermaßen Ergebnis gebracht.


Soviel zum Thema bei mir mit "Auskennen" 

Meine Problem - alle Berechnungliefn nur mit max 20 -25 Epochen durch - dadurch kein aktzeptables Ergebnis.
Jetzt bin ich wenigsten wieder bei ca 50- 80 Epochen gelandet.....

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 18.05.2026 16:50:21 / Laufzeit in Sekunden: 522
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 97.11 ms
Alpha: 0.7
Verbrauchernummer Wärmepumpe: 08

Bewertungsüberblick
Trainingsbewertung: ok (ok)
Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
Drift Bewertung: fresh_model
Empfehlung für Retrain: keine (Grund: -)

Modellparameter
Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
Trainingsdaten: 9550 Datensätze (Training=7640, Validation=1910)
Architektur: Inputs=94, Hidden Layers=40-20, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.4, BitFail-Limit=0.30
Aktivierungen: Hidden=SIGMOID_SYMMETRIC, Steepness=0.5, Output=LINEAR
Trainingsalgorithmus: RPROP, Registry Version=v1_heatpump_pv
Zufallsgenerator: Mode=1, Period=15
Modellalter: 0 h

Trainingsmetriken
bestes Modell bei Epoche: 52 (max. 15000)
Training MSE: 0.006566
Validation MSE: 0.004814
Validation MSE Average: 0.012047
Validation MSE Standard Deviation: 0.000049
Validation Bit_Fail: 3
Model Bias: 434 Wh
Model Slope: 0.76
Trainingsbewertung: ok

Fehlermaße der Prognosen
MAE: 361.80 Wh
MedAE: 280.44 Wh
RMSE: 419.88 Wh
RMSE relative: 30 %
RMSE Rating: good
MAPE: 27.37 %
MdAPE: 20.10 %
R²: 0.65

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

Drift-Kennzahlen (berechnet ab Modellalter > 24 h)
Analysefenster: - h
Drift RMSE Ratio: -
Semantic Ratio: -
Slope Reference: 0.76
Slope Live: -
Slope Drift: 1
Bias Reference: 434
Bias Live: -
Bias Drift: 0
Score: -
Index: -
Drift Bewertung: fresh_model
Empfehlung für Retrain: keine (Grund: -)
letzte Rekalibrierung: -



[dieter114]

Hallo 300P diese Werte

Vor allem diese 2 Werte
- contotal=Meter_0_EnergyReal_WAC_Plus_Absolute:Wh
- feedtotal=Meter_0_EnergyReal_WAC_Minus_Absolute:Wh

stammen aus dem "Haupt"Smartmeter des Fronius und werden nicht berechnet.
Das sind die Einspeisung und der Bezug. Und ja: es wird z.Z. Eingespeist und der Wert von feedtotal steigt kontinuierlich in Wh.
Da ist definitiv kein Fehler.
Ich hatte dort bis vor ca 8 Tagen eine Vertauschung drin, und die waren Falsch.
Deshalb auch meine Frage: Wie bekomme ich die alten falschen Speicherwerte weg.

LG WDS

[dieter114]

Noch ne Frage:
Ich habe ein KI Training gestartet.
Bisher ging immer die Systemlast vom PI5 ordenlich nach oben.
Nun zeigt mir FC "The AI for forecasting con is not yet operational.
Cause: the neural network for consumption forecasting is just being trained" an
aber es passiert einfach nix!
Was ist den da nu wieder los?
LG WDS

[300P]

Ich hatte dort bis vor ca 8 Tagen eine Vertauschung drin, und die waren Falsch.
Deshalb auch meine Frage: Wie bekomme ich die alten falschen Speicherwerte weg.

Das ist jetzt der Volltreffer :
Dadurch - Vergangenheitswerte definitiv falsch- ist es mir klar warum die Vorhersage so nicht passt / klappt.

Sind denn aktuell alle Werte nun weiterhin "richtig" ?  Wenn ja AB WANN ist alles okay Angabe bitte ->>> YYYYMMHH 
Wenn ja - dann wäre es auf jeden Fall besser alle alten Daten - während vertauscht gemeldet / gemessen wurde - sauber zu löschen.

Könnte Dir einen Set-Befehl geben der dir dabei helfen könnte....  

[300P]

Nun zeigt mir FC "The AI for forecasting con is not yet operational.
Cause: the neural network for consumption forecasting is just being trained" an
aber es passiert einfach nix!
Was ist den da nu wieder los?

Schalte wieder ctrlDebug ein - dann siehst du im LOG was grad passiert.

Ergänze dein 'attr SFNAME ctrlDebug none,aiProcess,aiProcess_long'  (Screenshot)

[300P]

Hallo Dieter,

her die Erläuterung für den "Befehl".


Erläuterung:
Mit den nachfolgenden Argumenten können KI-Rohdaten selektiv oder komplett entfernt werden:
delDataAll - löscht die KI Instanz inklusive aller Trainings- und Rohdaten sowie Daten auf Fileebene und initialisiert sie neu
delIndex=<Index>,<Index>,... - löscht einen oder mehrere Datensätze mit dem Index. Der Index kann als Regex angegeben sein.
Sind im Argument Leerzeichen vorhanden, ist das gesamte Argument in Hochkomma einzuschließen.
Beispiele: 1.) delIndex=2025013023 2.) delIndex='2025013023, 2025013024' 3.) delIndex=202501.* 4.) delIndex=20250130[0-9]
searchValue - sucht den Zahlenwert im angegebenen Schlüssel. Mögliche Vergleichsoperatoren sind: > | >= | == | <= | < (Findings sind im Logfile)
Beispiele: 1.) searchValue=con==9786 2.) searchValue=con>=14578 3.) searchValue=temp<=-5
delValue - löscht den Zahlenwert im angegebenen Schlüssel. Mögliche Vergleichsoperatoren sind: > | >= | == | <= | < (Löschbestätigung im Logfile)
Beispiele: 1.) delValue=con==9786 2.) delValue=con>=14578 3.) delValue=temp<=-5



Für dich passt auf jeden Fall z.B.
->>> Alles aus dem Jahr 2025 löschen: (Jeder Tag / Jede Stunde)

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=2025.*


Januar 2026 löschen

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=202601.*

Februar 2026 löschen

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=202602.*

März 2026 löschen

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=202603.*

April 2026 löschen

Code Auswählen Erweitern

set SFNAME  reset aiData delIndex=202604.*


Mai 2026 tageweise löschen
1. ->> Alle Tage bis einschließlich den 09.05.2026 löschen

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=2026050.*

2. ->> Alle Tage einzeln löschen die fehlerhafte Daten enthalten

Code Auswählen Erweitern

set SFNAME reset aiData delIndex=20260510.*
set SFNAME reset aiData delIndex=20260510.*
set SFNAME reset aiData delIndex=20260511.*
set SFNAME reset aiData delIndex=20260512.*
set SFNAME reset aiData delIndex=20260513.*
set SFNAME reset aiData delIndex=20260514.*
set SFNAME reset aiData delIndex=20260515.*
set SFNAME reset aiData delIndex=20260516.*

Du must aber allein entscheiden welche Tage mit den Daten gelöscht werden sollen.


Du kannst aber auch restlos alles (PV- und CON-Hisory) löschen und das ganze neu initialisieren:
(siehe Beschreibung oben)
DEINE alleinige Entscheidung !!!

Code Auswählen Erweitern

set SFNAME reset aiData delDataAll


[DS_Starter]

Hallo Chris,

Ich habe leider das Projekt schon längere Zeit nicht mehr verfolgt.
Mir ist jetzt aber ein Log-Eintrag betreffend ctrlUserExitFn aufgefallen.

Du hast vermutlich die Änderung in timestringsFromOffset verpasst die im Beitrag https://forum.fhem.de/index.php?msg=1362465 beschrieben ist:

 Wer die interne Funktion timestringsFromOffset in eigenem Code verwendet, muß den Aufruf mit $name ergänzen:

                             timestringsFromOffset ($name, <time>, <offset>);

Kontrolliere die in ctrlUserExitFn aufgerufenen Routinen und ergänze $name wie oben angegeben.

LG,
Heiko