76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Habe es grad bei mir probiert, bekomme auch nur den default in das Reading. Schaue ich mir an, komisch ...

[DS_Starter]

Ja, das Problem sitzt vor dem Bildschirm 

Natürlich ist der Index falsch, so ist es richtig:

Code Auswählen Erweitern

{
  # Hinweis: die Zeichen '::' vor der Routine sind durch das SolarForecast Package bedingt
  ::batSocChargeMgmnt ($name,'BYD_Battery');

  # Anlegen des Readings "Ladestrategie" und füllen mit dem gesetzten Wert
  my $wert = NexthoursVal ($name, "NextHour00", "strategybat01", "loadRelease");
  storeReading ("Ladestrategie", $wert);
}

Ändere ich auch im Wiki.

[Hadl]

Ich habe eine Variante in opt/smartPower eingebaut, die funktionieren könnte um zur aktuellen Stunde eine Zeitgewichtung zu realisieren ohne dass je mehr sich die aktuelle Stunde dem Ende neigt der Überschuß gegen 0 geht und somit die Leistungsgrenze sprunghaft gegen unendlich (pinmax) läuft.

Ich habs bei mir eingespielt und werde heute mal schaun wie's läuft.
Beim drübersehen ist mir aber aufgefallen, das die Gewichtung bei "$total" meiner Ansicht nach noch fehlt. Hier wird die laufende Stunde voll mit in die Summe gerechnet.

Code Auswählen Erweitern

      my @remaining_hods = grep { int $_ >= int $hod } @sortedhods;
      my $total          = 0;                                               
      $total            += $hsurp->{$_}{surplswh} for @remaining_hods;                                           # Gesamtkapazität aller Stunden mit PV-Überschuß ermitteln
damit würde achievable weiterhin am Ende der Stunde zu optimistisch sein

Code Auswählen Erweitern

          if ($runwhneed > 0 && $total * $befficiency < $runwhneed) {                                            # Erreichbarkeit des Ziels (benötigte Ladeenergie total) prüfen
              $achievable = 0;                                                     
          }

Wäre es generell nicht vorteilhaft für eine gleichmäßige Ladeleistung wenn man die Ladeleistung nicht anhand der Werte der aktuellen Stunde berechnen würde ($spls), sondern anhand des Resttages?
Also die Schleife von der schwächsten zur stärksten Überschuss-Stunde immer wieder neu berechnen, und sobald man nurnoch Stunden hat die den mittleren Restbedarf decken können wird dieser Wert als neue Leistung genutzt. Auch auf die Gefahr hin das die aktuelle Stunde das vielleicht garnicht liefern kann, aber die Leistung ist ja eh ein max-Wert.

Stunde0 ist aktuelle Stunde, Stunde1 die nächste usw.

Also wenn ich im Akku noch 5 kWh brauche, und folgende Stunden mit Überschuss habe:

Code Auswählen Erweitern

Stunde0: 0.4 kWh, aber es ist schon 15 Minuten vor Stundenende (0.1kWh Rest-Erwartung)
Stunde1: 10  kWh
Stunde2: 5  kWh
Stunde3: 1  kWh
Stunde4: 0.5 kWhDann würde die Schleife folgendes machen startend bei einem Bedarf von 5 kWh

Code Auswählen Erweitern

Stunde0: 0.1 kWh => Rest 4,9 kWh in 4,25 Stunden => 1,15 kW Bedarf im Schnitt (limit 0,1kWh)
Stunde4: 0.5 kWh => Rest 4,4 kWh in 4,25 Stunden => 1,04 kW Bedarf im Schnitt (limit 0,5kWh)
Stunde3: 1  kWh => Rest 3,9 kWh in 3,25 Stunden => 1,20 kW Bedarf im Schnitt (limit 1  kWh)
Stunde2: 5  kWh => Rest 2,9 kWh in 2,25 Stunden => 1,29 kW Bedarf im Schnitt
Stunde1: 10  kWh => Rest 1,61kWh in 1,25 Stunden => 1,29 kW Bedarf im Schnitt
Aktuelle Stunde => Rest 0,32kWh in 0,25 Stunden => OTP 1,29kW => aktuell zu setzen auch wenn nicht zu erwartenDamit würde man für dem aktuellen Zeitpunkt eher den maximalen Wert anfordern den man voraussichtlich an diesem Tag noch zum laden braucht. Wenns besser läuft als gedacht würde er sogar im Laufe des Tages sinken.

Das ganze dann natürlich noch mit den Safety Margin und den achievable-Aufschlägen zu garnieren.

Wenn ich das richtig gesehen habe ist die Strategie eh schon sehr ähnlich, nur die aktuelle Stunde wird anders behandelt. Was hältst du davon?

Viele Grüße

Christian

[DS_Starter]

Hallo Cristian,

Beim drübersehen ist mir aber aufgefallen, das die Gewichtung bei "$total" meiner Ansicht nach noch fehlt. Hier wird die laufende Stunde voll mit in die Summe gerechnet.
Code Auswählen
      my @remaining_hods = grep { int $_ >= int $hod } @sortedhods;
      my $total          = 0;                                             
      $total            += $hsurp->{$_}{surplswh} for @remaining_hods;                                          # Gesamtkapazität aller Stunden mit PV-Überschuß ermitteln
damit würde achievable weiterhin am Ende der Stunde zu optimistisch sein

Dabei hast du übersehen, dass in  @sortedhods bzw. $hsurp->{XX}{surplswh} bereits der zeitgewichtete PV-Überschuß der aktuellen Stunde enthalten ist. Das wird in einem Codeblock vorher gemacht.

Wäre es generell nicht vorteilhaft für eine gleichmäßige Ladeleistung wenn man die Ladeleistung nicht anhand der Werte der aktuellen Stunde berechnen würde ($spls), sondern anhand des Resttages?
Also die Schleife von der schwächsten zur stärksten Überschuss-Stunde immer wieder neu berechnen, und sobald man nurnoch Stunden hat die den mittleren Restbedarf decken können wird dieser Wert als neue Leistung genutzt.

So ist es und das ist bereits seit langem implementiert. Diese Aufgabe übernimmt die Iterations-Sub ___batFindMinPhWh.

Die Stunde 00 (aktuelle Stunde) erhält dann noch eine Nachbehandlung mit allen möglichen bisher eingebrachten Anforderungen und Wünschen.
Danke fürs mitdenken. 

LG,
Heiko

[DS_Starter]

Die Einstellung der aktuellen Testversion hat sich für optPower als zu aggressiv erwiesen. Aus dem Grund ist wurde optPower wieder auf den vorigen Code zurückgesetzt. Dafür hat smartPower als agressivere Variante diesen Code übernommen. Die eingebaute Zeitgewichtung ist geblieben.
Dadurch ist optPower für User mit dem Ziel moderaterer Ladeleistungen gegeüber smartPower wieder besser geeignet.

Contrib ist upgedatet.