76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Bei mir gibt es nach einem Restart ebenfalls keine Probs.

@300P,

Die Bewertung der PV-Prognose wird aktuell ja schon im Tooltip angezeigt.
Kannst du diesen Tooltip evtl. mit der Drift-Historie der CON erweitern ?

Was meinst du genau mit Drift-Historie?
Drift beschreibt, wie stark sich das reale Verbrauchsverhalten vom gelernten Modell entfernt.
Es ist also kein Qualitätsmerkmal des Modells selbst, sondern ein Messwert für die Übereinstimmung zwischen Modell und Realität.
Vor diesem Hintergrund wäre der DriftIndex ein guter Indikator:

Code Auswählen Erweitern

* Wenn DriftIndex dauerhaft > 2.0 → Modell altert.
* Wenn DriftIndex > 3.0 → Modell passt nicht mehr.


[300P]

Ich vervollständige jetzt wieder erneut und beobachte es weiter.

Kann bestätigen das es jetzt NICHT wieder beim erneuten Update / Restart aus dem Contrib mit V2.5.0   passiert ist-

War nur seltsam das ich 2 mal vergessen haben würde / sollte auf "Save Config" zu drücken, außerdem wird bei mir nach Änderung eine Kopie erstellt. Aus der letzten Kopie habe ich ja die Daten jeweils wiederhergestellt....    

Vor diesem Hintergrund wäre der DriftIndex ein guter Indikator:

Ja - das wäre eine gute Idee ! 
Dann kann man auf einen Blick sehen ob die CON-Prognose okay ist.

Drift-Historie wäre wie im Log:

Forecast DEBUG> DRIFT [con]: Flag=moderate | Block=negative_slope_drift | SlopeLive=-0.039 | DriftSlope=-0.051 | BiasLive=1945.35 | DriftBias=1626.64 | RMSErelLive=46.6 | RMSErelRatio=2.03 | BiasVarNorm=0.20 |DriftScore=1.98 | Zone3Hours=17 | Hist=[moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate,moderate]

[DS_Starter]

In dem Speicher aiRawData wird die Consumernummer einer installierten Wärmepumpe gespeichert. Damit wird es mir zukünftig möglich sein, über eine Zuordnung den gespeicherten Stundenverbrauch der WP (später auch mehrere) explizit im KI-Training zur Verfügung zu stellen und damit das WP-Profil zu stärken.

Update liegt im contrib.

[TheTrumpeter]

Deinen Hinweis bzgl. "Ist nämlich der erste Balken das Maximum, wächst das entsprechende Diagramm sehr stark in der Höhe ..." gehe ich mal nach, wobei ich mir nicht denken kann einen Wert nicht zu berücksichtigen. Aber wer weiß, vllt. ist es eine heiße Spur.

Ich beobachte die "zu hohen Balken" auch immer wieder, und gerade eben trifft die Vermutung mit dem "Maximum beim ersten Balken" auch zu.
Vielleicht hängt's irgendwie mit der Darstellung der "vergangenen Stunden" zusammen?

Wenn ich folgendes setze:

Code Auswählen Erweitern

attr mySolarForecast graphicHistoryHour 3Ist das Problem weg. Da ist dann der Maximum-Wert auch nicht bei der 1. dargestellten Stunde, sondern bei der 2.

Das Thema ist noch nicht gelöst, oder? (Ich verwende die offiziell 2.4.0.)

[DS_Starter]

Ich hatte mich bereits damit befasst. Es gab aber nichts zu lösen, alle Daten werden berücksichtigt. Das Verhalten ist durch die automatische Höheneinstellung vor allem gemäß beamHeightlevel und scaleMode bedingt. Dabei ist zu beachten, dass beamHeightlevel kein Absolutwert, sondern ein Faktor ist. In der Hilfe gibt es ein Link zum Wiki dazu.
Wenn die Dynamik der dargestellten Werte sehr groß ist - wie bei dir im Bereich min=127 und max=2450 - wäre die Einstellung von scaleMode=<Ebene>:log meiner Meinung nach sinnvoll.

LG,
Heiko 

[TheTrumpeter]

Ich verstehe was Du meinst, sehe aber nicht, dass das "Problem" alleine durch die hohe Dynamik kommt.

Habe nochmal ein bisschen herumprobiert. Gegenüber des Screenshots von 11 Uhr ist aktuell zwar das Maximum bei den aktuellen Screenshots identisch, der Minimum-Wert ist nun aber etwas höher (150 statt 127). Ich käme dabei auf folgendes Verhältnis Max/Min: 16,33 bzw. 19,29. Damit kann ich Dein Argument nachvollziehen, d.h. vorhin war die Dynamik höher, daher auch der Maximum-Balken höher.

ABER: Wenn ich die beiden neuen Screenshots übereinanderlege (1x Max bei der 1. Stunde, 1x Max bei der 2. Stunde, Daten ansonsten gleich), ist trotzdem der Balken höher wenn das Maximum auf die 1. Stunde fällt.

[DS_Starter]

...sehe aber nicht, dass das "Problem" alleine durch die hohe Dynamik kommt.

Vielleicht siehst du ja mehr als ich, vier Augen sehen bekanntlich mehr als zwei.

Wenn du Lust hast, schaust du dir die Skalierung ab Zeile 20717 (V2.4.0) bis 20758 mal an.

Code Auswählen Erweitern

      if ($lotype eq 'double') {
          ....
          if ($scm eq 'staple') {
           .....
          }
          else {
              if ($hfcg->{$i}{beam1} >= $hfcg->{$i}{beam2}) {
                  $z2    = $hfcg->{$i}{beam1};
                  $z3    = $hfcg->{$i}{beam2};
                  $titz2 = qq/title="$hfcg->{0}{beam1txt}"/;
                  $titz3 = qq/title="$hfcg->{0}{beam2txt}"/;
              }
              else {                                                                                                                        # tauschen, Betrag Beam1 < Betrag Beam2
                  $z2    = $hfcg->{$i}{beam2};
                  $z3    = $hfcg->{$i}{beam1};
                  $titz2 = qq/title="$hfcg->{0}{beam2txt}"/;
                  $titz3 = qq/title="$hfcg->{0}{beam1txt}"/;
              }

              $mbdf = $maxVal - $z2;                                         # Wertedifferenz abs. Maxwert und größerem Balkenwert
          }

          $z1  = __normBeamHeight ( { val => $mbdf, maxVal => $maxVal, height => $height, ground => 0, scalemode => 'lin' } );
          $z2  = __normBeamHeight ( { val => $z2,   maxVal => $maxVal, height => $height, ground => 0, scalemode => $scm  } );
          $z3  = __normBeamHeight ( { val => $z3,   maxVal => $maxVal, height => $height, ground => 0, scalemode => $scm  } );
          $z2 -= $z3 if($scm eq 'lin');                                                                                                 # effektive Stapelhöhe, da $z2 + $z3 übereinander dargestellt wird

          if ($scm eq 'log' && $z2) {
             .....
          }
      }

In __normBeamHeight steckt die Skalierungslogik:

Code Auswählen Erweitern

sub __normBeamHeight {
  my $paref     = shift;
  my $val       = $paref->{val}       // 0;
  my $maxVal    = $paref->{maxVal}    // 0;
  my $height    = $paref->{height};
  my $ground    = $paref->{ground}    // 0;                                     # eine minimale Balkenhöhe die immer eingehalten werden soll
  my $scalemode = $paref->{scalemode} // 'lin';                                 # lin / log / staple

  my $px = $ground;
  return int($px) if($maxVal <= 0);                                             # Schutz: maxVal darf nicht 0 oder negativ sein

  if ($scalemode eq 'lin' || $scalemode eq 'staple') {
      $px = $ground + (($val / $maxVal) * ($height - $ground));
  }
  elsif ($scalemode eq 'log') {
      return int($px) if($val <= 0);                                            # Logarithmus nur für positive Werte

      my $logMax = log($maxVal);
      return int($px) if($logMax <= 0);                                         # verhindert log(1)=0 oder log(<1)<0

      $px = $ground + ((log($val) / $logMax) * ($height - $ground));
  }

return int($px);
}

Solltest du einen Verbesserungsvorschlag unterbreiten können, schaue ich ihn mir gerne mal an.

LG,
Heiko

[TheTrumpeter]

In __normBeamHeight steckt die Skalierungslogik:

Nachdem das für alle Stunden identisch aufgerufen wird, sollte das keinen Einfluss haben. Was ich darin aber logisch nicht ganz nachvollziehen kann, ist:

Code Auswählen Erweitern

  if ($scalemode eq 'lin' || $scalemode eq 'staple') {
      $px = $ground + (($val / $maxVal) * ($height - $ground));Wäre korrekt(er) nicht:

Code Auswählen Erweitern

$px = ($ground > ($val / $maxVal * $height)) ? $ground : ($val / $maxVal * $height)Damit wird alles, was unter der Mindestbalkenhöhe wäre, auf die Mindestbalkenhöhe gesetzt. Warum Du bei Deiner Rechnung "ground" vom Quotient abziehst, verstehe ich nicht.

Habe mir auch die Subs _beamGraphicFirstHour sowie _beamGraphicRemainingHours durchgeschaut bzw. verglichen, weil ich da einen relevanten Unterschied erwartet hätte. Ist aber nicht so...

Kann es sein, dass sich durch den Text in den Balken ein Unterschied ergibt?
Oder eventuell doch durch die "Mindestbalkenhöhe"?
Die beiden Screenshots vorhin unterscheiden sich meiner Einschätzung nach exakt um die "Mindestbalkenhöhe". Ich sehe zwar im Code grad nicht warum sich das anders verhalten sollte abhängig davon ob der "maxval" aus _beamGraphicFirstHour oder _beamGraphicRemainingHours kommt, aber vielleicht kannst Du es eher nachvollziehen?

[DS_Starter]

Ich weiß nach 6 Jahren Entwicklungszeit nicht mehr wieso ich an einer Stelle so und nicht anders vorgegangen bin.
Aber an dieser Stelle geht es in meiner Erinnerung darum, dass der Balken in bestimmten Konstellationen nicht einfach verschwindet, zumindest konnte man es damit steuern.
Aktuell wird ground mit 0, das heißt ohne systematische Verschiebung aufgerufen. Du beschreibst es als "Mindestbalkenhöhe", die aktuell 0 ist.
Das führt bei positiven Werten zu  $px = ($val / $maxVal) * $height;
und bei negativen Werten entsprechend zu einem Balken unterhalb der Nullinie. Das passt dann so wie es kodiert ist.

Kann es sein, dass sich durch den Text in den Balken ein Unterschied ergibt?

Könnte sein. Aber auch die Höhe des sekundären Balkens spielt mit hinein.
Das kann man testen indem man eine weiteren Ebene anlegt und dort nur einen Balken, identisch zum primären Vergleichsbalken, anzeigen lässt.
 

[denis.robel]

Der linke gelbe Punkt liefert bei Mouse over:
Die KI-Unterstützung arbeitet einwandfrei, liefert jedoch keinen Wert für die aktuelle Stunde. Letztes KI-Training: 20.02.2026 02:15:26

Das ist ok.

Der rechte gelbe Punkt liefert:
das neuronale Netz zur Verbrauchsprognose wird gerade trainiert, die Prognose erfolgt ohne KI.
letztes Training des neuronalen Netzes Verbrauchsprognose: -

Hier ist das Traningslog wesentlich -> ctrlDebug=aiProcess -> dann Training (neu) starten.

Mein log zeigt folgende Zeilen:

Code Auswählen Erweitern

2026.04.01 18:17:19 1: SolarForecast_dach DEBUG> ################### ENDE Consumption forecast ###################
2026.04.01 18:17:19 1: SolarForecast_dach DEBUG> AI FANN for consumption forecast is not ready. Use legacy procedure ...
2026.04.01 18:17:19 1: SolarForecast_dach DEBUG> consumption since begin hour - day: 01, hod: 19, con: 136 Wh
2026.04.01 18:17:19 1: SolarForecast_dach DEBUG> write pvCircular consumption - hod: 99, todayConsumption: 6934 Wh
2026.04.01 18:21:08 1: SolarForecast_dach DEBUG> AI FANN Training for Consumption Forecast BlockingCall PID "239826" with Timeout 86400 s started
2026.04.01 18:21:10 1: SolarForecast_dach DEBUG> AI FANN - There are 1 Records skipped due to incomplete or invalid data.
2026.04.01 18:21:10 1: SolarForecast_dach DEBUG> AI FANN - dataset skipped - 2026032903 -> con=undef
2026.04.01 18:21:10 1: SolarForecast_dach DEBUG> AI FANN - Training aborted: insufficient number of valid data (767 < 2000)
2026.04.01 18:21:10 1: SolarForecast_dach DEBUG> AI FANN  Training BlockingCall PID '239826' finished
Und die zwei Punkte sind immer noch gelb.

Dazu noch meine Fragen:

1. Interpretiere ich es richtig, dass die Anzahl der Werte noch zu klein ist, um die KI zu trainieren?
Und wenn ja, muss ich einfach nur warten und das Training später noch einmal amstoßen?

2. reicht die Rechenpower von meinen Raspi 4 aus um alles in einer vernünftigen Zeit durchzurechnen oder ist das System damit überfordert?

VG Denis

[DS_Starter]

1. Interpretiere ich es richtig, dass die Anzahl der Werte noch zu klein ist, um die KI zu trainieren?
Und wenn ja, muss ich einfach nur warten und das Training später noch einmal amstoßen?

Genauso ist es und einfach nur warten. Es fehlen noch ca. 1233 Datensätze. Jede Stunde kommt ein Datensatz hinzu. D.h. noch ungefähr 52 Tage wird es dauern bis man davon ausgehen kann einen ersten Stock an aussagefähigen Daten zu haben.

2. reicht die Rechenpower von meinen Raspi 4 aus um alles in einer vernünftigen Zeit durchzurechnen oder ist das System damit überfordert?

Nach allem was ich bisher so gelesen habe, klappt das durchaus. Es kommt auch ein bisschen auf die Einstellungen und Datenqualität an. Aber da das Training in einem Parallelprozess läuft ist es letztendlich nicht so tragisch wenn es länger braucht. Allerdings -das will ich nicht verschweigen - braucht es u.U. etliche Versuche und Anläufe bevor man ein gutes Modell eingestellt und trainiert hat. Und wenn die Versuche lange laufen, kann das schon nervend sein. Ich glaube mindestens 300P kann ein Lied davon singen. 

Grüße,
Heiko

[denis.robel]

Genauso ist es und einfach nur warten. Es fehlen noch ca. 1233 Datensätze. Jede Stunde kommt ein Datensatz hinzu. D.h. noch ungefähr 52 Tage wird es dauern bis man davon ausgehen kann einen ersten Stock an aussagefähigen Daten zu haben.

Na dann übe ich mich in Geduld

Nach allem was ich bisher so gelesen habe, klappt das durchaus. Es kommt auch ein bisschen auf die Einstellungen und Datenqualität an. Aber da das Training in einem Parallelprozess läuft ist es letztendlich nicht so tragisch wenn es länger braucht. Allerdings -das will ich nicht verschweigen - braucht es u.U. etliche Versuche und Anläufe bevor man ein gutes Modell eingestellt und trainiert hat. Und wenn die Versuche lange laufen, kann das schon nervend sein. Ich glaube mindestens 300P kann ein Lied davon singen. 

Welche Einstellungen kann man denn variieren, damit es mit der Rechenleistung funktioniert?


Mein Setup scheint jetzt soweit i.O. zu sein. Ich werde mich also in den nächsten Tagen mit Beobachten des ganzen Systems begnügen müssen.

Die Grafik mit dem Energiefluss funktioniert jetzt auch vernünftig

Wenn Interesse für das konkrete System besteht, kann ich ja meine Config dokumentieren. Das würde ich aber entweder im Wiki oder in einem separaten Betrag machen, da es nichts mit der Modulentwicklung von Solarforecast zu tun hat.

Mein System besteht aus:
- 4x 445W Trina Solar
- Zendure Solarhub 2000
- 2x Akku Zendure AB2000,
- OpenDTU on Battery für die Nulleinspeisung
- Zendurbridge mit ESP home um den Solarhub lokal, ohne Cloud über MQTT auszulesen
- Shelly pro 3EM Smartmeter

VG Denis

[300P]

Ich glaube mindestens 300P kann ein Lied davon singen. 

Ja ein RPI4 schafft es mit einer Auslastung von ca. 20-50 %
Wenn du viele Daten in dem XXHistory-Ringspeicher hast - auch kein Problem.

Wenn du dann eine "gute" Einstellungsrichtung in der aiControl gefunden hast sind die Trainingsläufe auch kurz.
Meine aktuelle Laufzeit von 500 Sekunden und "29 Epochen"ist da ein äußerst sehr- sehr- sehr - sehr guter Wert.

Bis 5.000 Sekunden ist noch so grade okay (war bei mir meist entweder zu "tief" (98-64-32 oder 64-32-16. besser dann 80-40 nutzen) und zu genau "BitFail=0.05 oder 0.01 eingestellt etc. usw.)

Alles drüber an Laufzeit ist meist am Ende "Großer Mist" gewesen.

Mit einer WP erreicht man wegen deren Verbrauchsmuster oft nicht einen R2-Wert von >0.70  ab 0.65 bin ich zufrieden.

Hier Zur Info:
PV 3WR mit insgesamt 9.5 kW / 6 Strings mit insgesamt 14.5 kWp
Haus-Grundlast ca 4-500 Watt/h
Winter / WW ->> WP 7kW Wärmeleistung
Sommer > 27 Grad -> Klima mit 7 kW Kühlleistung
Rest siehe......

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 29.03.2026 21:44:43 / Laufzeit in Sekunden: 560
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 70.21 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

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

=== Trainingsmetriken ===

bestes Modell bei Epoche: 29 (max. 15000)
Training MSE: 0.005849
Validation MSE: 0.003886
Validation MSE Average: 0.008082
Validation MSE Standard Deviation: 0.001454
Validation Bit_Fail: 1
Model Bias: 319 Wh
Model Slope: 0.8
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 367.84 Wh
MedAE: 294.48 Wh
RMSE: 447.47 Wh
RMSE relative: 23 %
RMSE Rating: good
MAPE: 18.80 %
MdAPE: 15.71 %
R²: 0.67


[DS_Starter]

Wenn Interesse für das konkrete System besteht, kann ich ja meine Config dokumentieren.

Du würdest sicherlich vielen Nutzern helfen, wenn du deine Konfiguration und deine SF-Einstellungen/Setup im Wiki dokumentieren würdest. Es gibt den Punkt Konfigurationsbeispiele wo es m.M. nach gut hinpassen würde.

[300P]

Ganz vergessen,..... ich habe inzwischen wohl mehr als 200 Trainingsläufe hinter mir
Das kam aber auch nur daher, da ich selber am Code im Februar Hand angelegt hatte und meine eigenen speziellen WP-NN Einstellung / Semantic programmiert hatte.
Aber einen realen "AHA"-Verbesserungssprung gab es leider nicht - deshalb zurück auf Standart ohne ständig die neuen Versionen immer zu patchen....in der Hoffnung das für die WP noch mehr kommt