76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Gisbert]

Beim SetupMeterDev waren gcon und gfeedin gleich definiert.
Das steht auch so falsch im WiKi (hat noch keiner bemerkt  )

Hallo WDS,

in der commandref (also den Erklärungen im Device) findet man diese Beschreibung - meinst du etwa das?

Code Auswählen Erweitern

Special cases: If the reading for gcon and gfeedin should be identical but signed, the keys gfeedin and gcon can be defined as follows:

    gfeedin=-gcon    (a negative value of gcon is used as gfeedin)
    gcon=-gfeedin    (a negative value of gfeedin is used as gcon)

Das sieht zwar etwas wild aus, aber wenn es richtig im Modul umgesetzt ist, dann ist es nachvollziehbar. Es wird nur Bezug auf ein Reading gemacht. Der positive Wert des Readings (als Beispiel) ist gcon (=Bezug) und der negative Wert des Readings wird als Einspeisung (gfeedin) in Form des Absolutwertes identifiziert. Das ganze geht dann auch, falls die Vorzeichen für Bezug und Einspeisung gegenüber dem Beispiel vertauscht sind. Es ist schon ein Gehirnverzwirner, aber nur ein kleiner .

[peterboeckmann]

Moin Heiko,

der Entladevorgang der Batterien sieht in v2.6.7 gut aus.

auch der Ladevorgang sieht in der v2.6.7 gut aus.
Screenshot anbei.

Viele Grüße,
Peter

[dieter114]

EDIT:
SF-Wiki ? - dann kann ich es korrigieren

Nö im WiKi Fronius Komplettbeispiel.
Das mache ich wenn alles endlich mal richtig läuft.

LG WDS

[DS_Starter]

Moin @all,

danke für die Rückmeldung Peter.
Da können wir nun einen Haken dran machen denke ich. Auch bei mir passt alles nach wie vor.

LG,
Heiko

[300P]

Gestern hab ich NN neu trainiert
Grund:
Mein WW-Programm in der WP läuft seit mehr als 1 Woche total anders um während der WW-Aufbereitung die WW-Arbeitszahl der WP höher zu bekommen....
- verschiedene Zeiten mit verschiedenen Temperaturen
- Legionellenprogramm aktiv mit 63 °C und 1x / Woche am SA um 14:00 Uhr
- wenig Komforverlust
Ergebnis ist im Schnitt ca. 2-2.7 kWh/Tag weniger Energieverbrauch bei der WW-Aufbereitung
(vorher 1 x täglich Mittagszeit auf 57 Grad und da war schon Potential (3 kWh/Tag) gegenüber vorher rausgekommen)


NN-Ergebnis leider grad erst angeschaut:
=>>> WOW - wenns wirklich stimmt und dauerhaft bleibt

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 09.05.2026 21:38:52 / Laufzeit in Sekunden: 5168
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 78.03 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6770 Wh
Trainingsdaten: 12069 Datensätze (Training=9655, Validation=2414)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.002, Momentum=0.8, BitFail-Limit=0.28
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Period=20
Modellalter: 11 h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 5706 (max. 15000)
Training MSE: 0.000634
Validation MSE: 0.000073
Validation MSE Average: 0.000094
Validation MSE Standard Deviation: 0.000011
Validation Bit_Fail: 0
Model Bias: -7 Wh
Model Slope: 1.0
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 44.38 Wh
MedAE: 33.76 Wh
RMSE: 48.59 Wh
RMSE relative: 4 %
RMSE Rating: excellent
MAPE: 3.88 %
MdAPE: 2.41 %
R²: 1.00

=== Rauschen ===

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

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: 1
Drift Bias: 0
Drift Bias Live: -
Drift Index: -
Drift Bewertung: fresh_model
Slope recalibrated: 1.0
Bias recalibrated: -7
letzte Rekalibrierung: -




Meine neueste aktuelle Einstellung in attr aiControl:

Code Auswählen Erweitern

aiConAbsOversample=0.25
aiConActFunc=ELLIOT_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.28
aiConHiddenLayers=80-40
aiConLearnRate=0.002
aiConMomentum=0.8
aiConProfile=v1_heatpump_active_pv
aiConShuffleMode=2
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConTrainStart=7:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30


Mal sehen was nach 24 Stunden an Ergebnis kommt

[DS_Starter]

Wow, das wäre natürlich der Hit. So richtig glauben kann ich es noch nicht    ... aber lassen wir uns mal überraschen.
Wenn das Ergebnis sich bewahrheitet mußt du aber eine Runde ausgeben. 

[Mikel2906]

ch habe das Problem, dass die Variablen GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer zeigen. Ich lese die Daten direkt über Tasmota MQTT am Zähler ab. Meine Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht.

Ich habe meine Konfiguration angehängt. Ich benötige diesbezüglich Hilfe, ich bin mit meinem Latein am Ende.

Viele Grüße

[DS_Starter]

Hallo Mikel2906,

willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.

Zunächst sind die von dir beschriebenen Sachverhalte:

a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht

zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.

Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen

- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?

Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.

LG,
Heiko

[DS_Starter]

@all,
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.

Mit der V 2.6.6 bis 2.6.7 kommen folgende Fixes und Änderungen ins System.

Consumersteuerung:

- pro SF-Zyklus wird ein PV-Überschußbudget geführt, aus welchem sich die Verbraucher beim Einschaltvorgang bedienen.
  Ist er aufgebraucht, wird kein Verbraucher im laufenden Zyklus mehr eingeschaltet und wird erst im nächsten wieder geprüft.
  Das Verfahren verhindert "Toggling" von Verbrauchern weil im nächsten Zyklus PV-Überschuß überzogen wurde und Verbraucher
  deshalb wieder abgeschaltet werden
 
- neuer Schlüssel swprio zur Prioritätssteuerung von Consumern


Flußgrafik:

- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)


Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
 
 
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.

- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
  Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.

- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
  Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
  das nächste freie Fenster.

- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
  Niedriger priorisierte Consumer weichen automatisch aus.

- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.

Die V 2.6.8 habe ich ins contrib geladen.

LG,
Heiko

[Mikel2906]

Hallo Heiko,

danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.

Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar

Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.

Beispiele:

    Today_Hour02_GridConsumption: 17516200 Wh
    Today_Hour04_GridFeedIn: 11315700 Wh

Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.

Das Skript für die Ladesteuerung ist im Anhang.

Viele Grüße
Michael

[DS_Starter]

Hallo Michael,

Code Auswählen Erweitern

    Today_Hour02_GridConsumption: 17516200 Wh
    Today_Hour04_GridFeedIn: 11315700 Wh

Das ist natürlich ein Grundübel und macht dir alles kaputt. Damit kann man keine Prognose oder Steuerung aufbauen. Die Werte werden abgeleitet aus:

   setupMeterDev Smartmeter
   gcon=Netzleistung:W
   contotal=MT175_E_in:kWh
   gfeedin=Einspeisung_Netz:W
   feedtotal=MT175_E_out:kWh

In diesen Readings von Device Smartmeter muß enthalten sein:

contotal    
Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
   Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
   In diesem Fall erfolgt eine Meldung im Log mit verbose 3.

feedtotal    
Reading welches die Summe der in das Netz eingespeisten Energie liefert (ein sich stetig erhöhender Zähler)
   Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
   In diesem Fall erfolgt eine Meldung im Log mit verbose 3.


Wenn diese Vorgabe nicht eingehalten wird, kommt nichts gescheites heraus. Jetzt ist die Frage ob diese Readings

- MT175_E_in
- MT175_E_out

inhaltlich tatsächlich die Summen (In bzw. Out) der gesamten Laufzeit des Meters enthalten. Das müßtest du in deinem System verifizieren.

Auf unserer können wir die Datenlieferung verfolgen mit

 ctrlDebug=collectData

Setz dir das mal. Am Besten per at-Device ein- bzw. ausschalten von 01:55 bis 02:05 und 03:55 bis 04:05. Es entstehen viele Daten etwa dieser Art:

Code Auswählen Erweitern

2026.05.10 14:12:02.633 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, source: pv, delivery: default =>
2026.05.10 14:12:02.634 1: SolCast DEBUG> pvOut: 4028 W, pvIn: 4052 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 71913664 Wh
2026.05.10 14:12:02.635 1: SolCast DEBUG> collect Inverter 02 data - device: MQTT2_cerboGX_c0619ab34e08_solarcharger_Common, source: pv, delivery: bat =>
2026.05.10 14:12:02.635 1: SolCast DEBUG> pvOut: 1594 W, pvIn: 1594 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 6143080 Wh
2026.05.10 14:12:02.636 1: SolCast DEBUG> collect Inverter 03 data - device: MQTT2_cerboGX_c0619ab34e08_vebus, source: bat, delivery: default =>
2026.05.10 14:12:02.636 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 45 W, etotal: 0 Wh
2026.05.10 14:12:02.636 1: SolCast DEBUG> summary data of all Inverters - pv: 5622 W, this hour Generation: 1045 Wh
2026.05.10 14:12:02.637 1: SolCast DEBUG> State of Plant derating: 0, info: The value of device "MQTT2_cerboGX_c0619ab34e08_solarcharger_Common", reading "Regulated" doesn't match the condition "1"
2026.05.10 14:12:02.637 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2026.05.10 14:12:02.638 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 15: 425.8 % -> pvrlvd: 1
2026.05.10 14:12:02.652 1: SolCast DEBUG> collect Energy Meter data - device: SMA_Energymeter =>
2026.05.10 14:12:02.652 1: SolCast DEBUG> gcon: 0 W, gfeedin: 3437.1 W, contotal: 1468.4 Wh, feedtotal: 9990.1 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> write to pvHistory - day: 10, hod: 15, GridConsumption (gcons): 0 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> collect Battery Readings data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2026.05.10 14:12:02.654 1: SolCast DEBUG> pin: 1506 W, pout: 0 W, totalin: 7910128.01605553 Wh, totalout: 7895642.85184491 Wh, soc: 89
2026.05.10 14:12:02.708 1: SolCast DEBUG> EnergyConsumption input -> PV: 1035 Wh, PP: 0 Wh, GridIn: 660 Wh, GridCon: 0 Wh, BatIn: 286 Wh, BatOut: 0 Wh
2026.05.10 14:12:02.709 1: SolCast DEBUG> EnergyConsumption result -> 89 Wh
2026.05.10 14:12:02.711 1: SolCast DEBUG> current Power values -> PV2Node: 4028 W, PV2Bat: 1594, PV2Grid: 0 W, Other: 0 W, GridIn: 3437 W, GridCon: 0 W
2026.05.10 14:12:02.711 1: SolCast DEBUG> current Power Battery -> BatIn: 1506 W (Node2Inv2DC: 0 W), BatOut: 0 W (DC2Inv2Node: 45 W)

Relevant sind diese Daten:

Code Auswählen Erweitern

2026.05.10 14:12:02.652 1: SolCast DEBUG> collect Energy Meter data - device: SMA_Energymeter =>
2026.05.10 14:12:02.652 1: SolCast DEBUG> gcon: 0 W, gfeedin: 3437.1 W, contotal: 1468.4 Wh, feedtotal: 9990.1 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> write to pvHistory - day: 10, hod: 15, GridConsumption (gcons): 0 Wh

Daran sieht man was wann vom Meter geliefert wird.

[Gisbert]

Hallo Heiko,
hallo 300P,

hier ist ein neuer Log-Auszug mit ctrlDebug aiProcess, gegen 11:30 gestartet; Hinweis ab 11:30 hab ich den Akku geladen.
Mein Ziel ist es ja, dass die Vorhersage für den Verbrauch die Realität (zumindest im groben) widerspigelt - im Moment gibt es noch Diskrepanzen, aber ich habe ja auch gerade erst mit KI-Unterstützung angefangen. Mittelerweile habe ich die DC-PV- Und AC-PV-Leistung auch richtig implementiert - es war learning by doing und heute morgen war noch eine Änderung nötig.

Viele Grüße Gisbert

[300P]

Hallo Gisbert,

Gratuliere !

Laufzeit
von : 2026.05.10 11:32:43.093
bis : 2026.05.10 11:55:57.255

Das sind ja sogar nur ca. 23 Minuten mit 3 Trainingsdurchgängen - sehr gut!!

Und das Endergebnis ist auch akzeptabel - der erste Schritt ist getan 

Code Auswählen Erweitern

2026.05.10 11:55:53.809 1: mySolarForecast DEBUG> Best model after retries comes from Attempt=2 with:
Seed=13783776,
Model Score=73,
Model Slope=0.71,
Model Bias=365.49,
VAL MedAE=206.24,
VAL MAE=311.86,
VAL weighted RMSE=359.56,
VAL weighted RMSE relative=51 %,
VAL weighted RMSE_Rating=acceptable,
VAL R2=0.78,
Val MSE=0.001582

Trotzdem gehe doch bitte einmal dem Wert von 109,6 kWh nach. das ist schon ein extremer CON-Verbaucher-Ausreißer.
=>> Die notwendige Anleitung dazu hast du ja schon gestern Abend von mir erhalten.

Code Auswählen Erweitern

2026.05.10 11:32:43.532 1: mySolarForecast DEBUG> AI FANN - Target-Norm: raw_max=109600, p99=3500, p99.5=11100, targmaxval=14430
2026.05.10 11:32:43.532 1: mySolarForecast DEBUG> AI FANN - True Outliers above p99.5 (11100): 109600
Gibst du auch noch bitte einmal den aktuellen Inhalt deines attr XYXYXYX aiControl .............in Kopie wenn du die Ausreißer eliminiert hast.......und erneut trainiert hast. 

Du kannst dann gern nach Trainingsschluss die "Informationen zum neuronalen Netz der Verbrauchsvorhersage" mit den Werten zur Statusmitteilung b.a.w. hier nutzen. (Screenshot).
Aber bitte nur den Text bis inklusive der Zeile mit
letzte Rekalibrierung: -
(da stehen in den letzten Zeilen aber erst nach 24 Stunden Laufzeit nach dem Training Werte)

kopieren und als

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 09.05.2026 21:38:52 / Laufzeit in Sekunden: 5168
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 69.73 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08
.....
....
...
..
.
Bias recalibrated: -7
letzte Rekalibrierung: -hier dann wieder zeigen.