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?