Leistungsprognose für Wechselrichter

[DS_Starter]

 

Die nächsten Tage werde ich mich noch mit der Astro Implementierung befassen.
Mal schauen ob/was das noch bringt.

[ch.eick]

Hallo zusammen,
ich habe auch mal schnell umgestellt und die ersten Vergleichswerte für morgen.
Bei mir ist zu beachten, dass ich eine Stunde verschoben habe, da das mit der Kurve der Realwerte besser übereinstimmt. Warum das so ist, kann ich nicht erklären
Mit Astro Winkel, und ohne Autokorrektur. Die E,S,W Ausrichtung entspricht exakt meiner Ausrichtung in Winkeln -90,0,+90 .

Somit ist fc1_10 <> 11 Uhr im SolarForecast Modul.
Hinter meine Werte habe ich mal den Abweichungsfaktur zum SolarForecast geschrieben.
Wie weit es von der Realität entfernt sein wird sehen wir dann morgen.

Code Auswählen Erweitern


Solar_forecast_fc1_10 46   > 2.3
Solar_forecast_fc1_11 45   > 1.5
Solar_forecast_fc1_12 38   > 1.3
Solar_forecast_fc1_13 116  > 1.7
Solar_forecast_fc1_14 172  > 1.6
Solar_forecast_fc1_15 199  >  2.1
Solar_forecast_fc1_16 159  > 3.24

NextHour14_PVforecast 20 Wh
NextHour14_Time 28.01.2021 11:00:00
NextHour15_PVforecast 30 Wh
NextHour15_Time 28.01.2021 12:00:00
NextHour16_PVforecast 29 Wh
NextHour16_Time 28.01.2021 13:00:00
NextHour17_PVforecast 68 Wh
NextHour17_Time 28.01.2021 14:00:00
NextHour18_PVforecast 107 Wh
NextHour18_Time 28.01.2021 15:00:00
NextHour19_PVforecast 97 Wh
NextHour19_Time 28.01.2021 16:00:00
NextHour20_PVforecast 49 Wh
NextHour20_Time 28.01.2021 17:00:00

Damit ich nicht mogle, habe ich mal die Prognosekurve für morgen beigelegt ...boa wird das grausam.

Solar_forecast_fc1_day 775   <<< Das sind echt Wh
Ab zoom +500 sieht man einen kleinen Hügel.

VG
  Christian

[DS_Starter]

Ich vermute die Ermittlung des Sonnenstandes über das Astro-Modul hat einen entscheidenden Einfluß auf das Ergebnis weil sich dadurch entsprechend dynamische Anpassungen ergeben. Dadurch ergibt sich ein zeitlicher Zusammenhang in Bezug auf die Modulausrichtung. Alle anderen Faktoren sind ja relativ Fix abgesehen von der Globalstrahlung und der Autoanpassung.

Also ich bin gespannt wie sich die Ergebnisse entwickeln wenn ich das eingebaut habe ...

[ch.eick]

Hallo zusammen,
ich weiß nicht mehr wer es war, aber es gab mal eine Bemerkung, dass die Prognose zum Abend hin wegen Schatten eines Berges daneben liegt.
Dies könnte man durch die Berücksichtigung der Sonnenwinkel in meiner Funktion Solar_Plain() anwenden.
Hierbei handelt es sich dann natürlich um eine individuelle Anpassung.
Wenn Heiko die Winkelfunktionen ins Modul einbaut, wäre so etwas nur möglich mit einem Attribut, das eine Perl Funktion auswertet.

99_myUtils.pm Funktionen
Solar_Plain()_Test

45 ist die Dachneigung
20 die Ausrichtung

Code Auswählen Erweitern


{Solar_plain(45,40,"2020-10-11 15:00:00") } => 2.00234055111251
{Solar_plain(45,40,"2020-10-11 16:00:00") } => 2.42298713810404
{Solar_plain(45,40,"2020-10-11 17:00:00") } => 3.20079343955795
{Solar_plain(45,40,"2020-10-11 18:00:00") } => 0.001
{Solar_plain(45,40,"2020-10-11 19:00:00") } => 0.001

Hier sieht man die Abriegelung um 18:00 Uhr auf 0.001, was dann nahe Null ist. Die anderen Werte kommen aus der Winkelberechnung.

Hinter diesen Codezeilen könnte man dann noch die eigenen Winkel Einschränkungen einfügen und einen besser passenden Faktor zurück geben.
Den Faktor ermittelt man aus der Differenz von Realität zur bisherigen Prognose zur gewünschten Zeit.
Wichtig sind natürlich die korrekten Astro Eingaben für den Standort der Module, also auch die Höhe über NN

Code Auswählen Erweitern


...
# avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
    if ($elevation <= 0.14) {
      Log 3, "Solar_plain: factor = $factor";
      return($factor);
    };
...


Viele Grüße
     Christian

[EinEinfach]

Hat jemand eine Idee, wie ich die Vorhersage am besten:

Code Auswählen Erweitern

NextHour01_PVforecast
NextHour02_PVforecast
...

in die Datenbank (DBLog Device) wegschreiben kann, um die Zukunft quasi vorab zu plotten. Ich abreite mit Grafana und da ist mein X-Vektor TIMESTAMP, jetzt muss ich irgendwie beim wegschreiben dem Forecast Reading den richtigen TIMESTAMP zuordnen.

Für einen Denkastoß wäre ich dankbar.

[ch.eick]

Hat jemand eine Idee, wie ich die Vorhersage am besten:

Code Auswählen Erweitern

NextHour01_PVforecast
NextHour02_PVforecast
...

in die Datenbank (DBLog Device) wegschreiben kann, um die Zukunft quasi vorab zu plotten. Ich abreite mit Grafana und da ist mein X-Vektor TIMESTAMP, jetzt muss ich irgendwie beim wegschreiben dem Forecast Reading den richtigen TIMESTAMP zuordnen.

Für einen Denkastoß wäre ich dankbar.

Das ist weiter vorne bereits gefragt worden. Man kann wohl die readings für DbLog forformatieren und die Einheit abschneiden. Das wird wohl später unterstützt werden, oder Du musst mit userreadings und Perl arbeiten

Und hier ist genau Dein Wunsch für Grafana bereits implementiert
Wenn Du parallel das Solar_forecast() testest, sind die readings direkt Datenbank tauglich und die Funktion würde sie auch mit einem HH:00:00 TIMESTAMP direkt in die DbLog schreiben. Der fc1 wird dabei auch direkt schon für morgen in der Datenbank abgelegt. Im DbRep Modul ist das auch bereits implementiert und man kann die Werte für morgen auch wieder timestamp_begin und timestamp_end, zB als Summe, extrahieren.

EDIT:
Grafana

Code Auswählen Erweitern


Solar_Calculation_fc0:
SELECT
  TIMESTAMP AS "time",
  value AS "Solar_Calculation_fc0"
FROM history
WHERE
  TIMESTAMP BETWEEN FROM_UNIXTIME(1611964800) AND FROM_UNIXTIME(1612051199) AND
  DEVICE = 'PV_Anlage_1' AND
  READING = 'Solar_Calculation_fc0'
ORDER BY TIMESTAMP

Solar_Calculation_fc1:
SELECT
  TIMESTAMP AS "time",
  value AS "Solar_Calculation_fc1"
FROM history
WHERE
  TIMESTAMP BETWEEN FROM_UNIXTIME(1611964800) AND FROM_UNIXTIME(1612051199) AND
  DEVICE = 'PV_Anlage_1' AND
  READING = 'Solar_Calculation_fc1'
ORDER BY TIMESTAMP


VG
    Christian

[DS_Starter]

Hat jemand eine Idee, wie ich die Vorhersage am besten .... wegschreiben kann

Das ist relativ einfach mit dem Attribut DbLogValueFn machbar. Dieses Attr wird in jedem Device proklamiert wenn man DbLog einsetzt.
Ich habe mal auf die Schnelle etwas zusammengebaut. Ist aber nicht getestet und man kann es sicherlich noch verbessern.
Aber das Prinzip wird klar denke ich.

Code Auswählen Erweitern


attr SolCast1 DbLogValueFn
{
  if ($READING =~ /NextHour.*?_PVforecast/x){
    my $tie       = (split "_", $READING)[0];
    $VALUE        = (split " ", $VALUE)[0];
    my $ts        = ReadingsVal ($name, $tie."_Time", "");
    my ($dt,$tm)  = split " ", $ts;                   
    my ($d,$m,$y) = $dt =~ /(\d{2}).(\d{2}).(\d{4})/x;
    $TIMESTAMP    = "$y-$m-$d $tm";
  }
}


SolCast1 ist das ForeCast Device. Die Beschreibung des Attr steht in der DbLog Commandref. Man kann auch das Attr valueFn benutzen. Das ist aber zentral im DbLog Device zu setzen.

LG,
Heiko

[EinEinfach]

Das ist relativ einfach mit dem Attribut DbLogValueFn machbar.

Jetzt bin ich kein Perl-Experte, und habe einfach den Attribut übernommen. Leder ändert sich am TIMESTAMP nichts. Kannst du kurz erläutern was jede einzelne Zeile macht?

Code Auswählen Erweitern

attr SolCast1 DbLogValueFn
{
  if ($READING =~ /NextHour.*?_PVforecast/x){                          - Wenn Reading "NextHour" und "PVforecast" enthält mach weiter
    my $tie       = (split "_", $READING)[0];                                   - Trenne den String auf, Trennzeichen "_" Ergebnis:(NextHour01, PVforecast)
    $VALUE        = (split " ", $VALUE)[0];                                       - Trene den Value-String auf, Trennzeichen " " Ergebnis:(Wert, Wh)?
    my $ts        = ReadingsVal ($name, $tie."_Time", "");             - Definiere Variable ts und schreibe dort den Timestamp rein?
    my ($dt,$tm)  = split " ", $ts;                                                  - Definiere Variablen dt und tm und schreibe jeweils den aufgetrennten String vom ts rein? Fehlen hier nicht die Runden Klammern (split " ",$ts)?
    my ($d,$m,$y) = $dt =~ /(\d{2}).(\d{2}).(\d{4})/x;              - Matrixcode!
    $TIMESTAMP    = "$y-$m-$d $tm";                                           - Schreibe den neuen String in die Variable TIMESTAMP
  }
}

Danke und Gruß
Alexander

[DS_Starter]

Hallo Alexander,

du hast deine Kommenatare genau richtig hingeschrieben.
"Matrixcode" ... naja ein Regex der die einzelnen Datumbestandteile trennt.
Da fällt mir ein ... benutzt du global language DE ? Wenn nicht, stimmt der Regex nicht.
Im englischen Format sieht das Timeformat anders aus und man kann sich die Zerlegung sparen.

Kannst mal global language DE einstellen wenn nicht gemacht.
Ansonten

Fehlen hier nicht die Runden Klammern (split " ",$ts)?

Nein, geht mit und auch ohne.

[EinEinfach]

Ich sehe immer noch nicht, an welcher Stelle der TIMESTAMP manipuliert wird. Es muss doch irgendwo +1Std oder oder auftauchen?

[ch.eick]

Hallo nochmal,
auch hier gilt natürlich dann, dass man mit DbRep die Einträge für morgen als z.B. min-, max- oder sumValue abfragen kann.

Im DOIF ist es dann auch möglich die Werte von morgen direkt aus der Datenbank für Entscheidungen zu verwenden.
Hier frage ich den Forecast Wert von fc0 für 12:00:00 Uhr ab.

Code Auswählen Erweitern


...
################################################################################################################
## 13 Pool Startzeit durch Forecast verschieben. Der Forecast wird um 7:00 im Device PV_Schedule aktualisiert
##
DOELSEIF
([07:17])
    (
     {my $timestamp = POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time));
      my $VALUE     = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",$timestamp,0);
      if ( $VALUE < 4000 )
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartWinter",0) )}
      else
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartSummer",0) )}
     },
     {Log 3, "Pool_PV cmd_13 : Pool TimeStart switched"}
    )
...


[ch.eick]

Ich sehe immer noch nicht, an welcher Stelle der TIMESTAMP manipuliert wird. Es muss doch irgendwo +1Std oder oder auftauchen?

Der TIMESTAMP wird aus dem zweiten reading mit _Time entnommen.

[DS_Starter]

Das ist die Stelle:

  $TIMESTAMP    = "$y-$m-$d $tm";

Der fertige Timestamp für DbLog wäre dann z.B..  2021-01-29 14:22:00
Das Format muß stimmen sonst wird er von DbLog nicht übernommen.

Du kannst dir in das Attr auch eine Logausgabe einbauen, z.B.

Code Auswählen Erweitern


attr SolCast1 DbLogValueFn
{
  if ($READING =~ /NextHour.*?_PVforecast/x){
    my $tie       = (split "_", $READING)[0];
    $VALUE        = (split " ", $VALUE)[0];
    my $ts        = ReadingsVal ($name, $tie."_Time", "");
    my ($dt,$tm)  = split " ", $ts;                   
    my ($d,$m,$y) = $dt =~ /(\d{2}).(\d{2}).(\d{4})/x;
    $TIMESTAMP    = "$y-$m-$d $tm";
    Log3 ($DEVICE, 1, "old TS: $ts, new TS: $TIMESTAMP");
  }
}


[ch.eick]

Der fertige Timestamp für DbLog wäre dann z.B..  2021-01-29 14:22:00
Er muß stimmen sonst wird er von DbLog nicht übernommen.

Achtung, in der Formatierung wäre es besser auf ganze Stunden oder 30' zu formatieren. Das sieht im Diagramm besser aus und läst sich nach meinem Beispiel auch besser wieder in der Datenbank abfragen.

[EinEinfach]

OK Vielen Dank, habe Dank dem Trick:

Code Auswählen Erweitern

Log3 ($DEVICE, 1, "old TS: $ts, new TS: $TIMESTAMP");

den Fehler gefunden:

Code Auswählen Erweitern

my $ts        = ReadingsVal ($name, $tie."_Time", "");

durch den $name kam ein leerer String zurück, habe einfach auf den Namen des Gerätes geändert und jetzt tut es!! Vielen Dank!

Code Auswählen Erweitern

{
  if ($READING =~ /NextHour.*?_PVforecast/x)
  {
    my $tie = (split "_", $READING)[0];
    $VALUE = (split " ", $VALUE)[0];
    my $ts = ReadingsVal("DR.PVforecast", $tie."_Time", "");
    $TIMESTAMP = $ts;
Log3 ($DEVICE, 1, "old TS: $ts, new TS: $TIMESTAMP");
  }
}