76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Wie kann ich diesen schönheitsfehler der von 00:00 bis 09:00 auftritt noch beseitigen

Wahrscheinlich so:

Code Auswählen Erweitern

sub PVForecast_log2
{
   Log 3, "Aufruf von PVForecast_log2 um ".localtime();
   
   # Alte Einträge erst einmal löschen
   my $timedelete = TimeNow();
   my ($year,$mon,$day,$hour,$min) = $timedelete =~ m/(\d\d\d\d)-(\d\d)-(\d\d) (\d\d):(\d\d):\d\d/;
   
   fhem "set DBRep_PV sqlCmd delete from history where DEVICE = 'Solar_Cast' AND reading like 'PVforecast%' and TIMESTAMP>='".$timedelete."'";
   
   # alle Verhersage Readings des Device durchlaufen
   for(my $i=$hour; $i < 24; $i++)
   {     
      # die Readings mit der Nummerierung richtig zusammen bauen (führende Nullen bei < 10)
      $i = sprintf "%02d", $i;
      my $reading = "Today_Hour".(sprintf "%02d", $i);
       
      #Timestamp für den Forecastwert
      my $timestamp = "$year-$mon-$day ".(sprintf "%02d", $i).":00:00";
      my $value = ReadingsNum("Solar_Cast",$reading."_PVforecast",0);
       
      # Wert in der Datenbank loggen
      #Log 3, "Logging: $timestamp  newForecast$i  PVforecast:$value";
      fhem "set DBLogging addCacheLine $timestamp|Solar_Cast|addlog|newForecast: $i|PVforecast|$value|";
   }
}


[DS_Starter]

Hallo Guido,

* Wird bei der Ermittlung des Status berücksichtigt, wie der Aktualisierungsintervall ist?

Nein. Das werde ich aber einbauen. Ich hoffe das relevante Attribut hat jetzt seine finale Version erreicht.

Die Zeitstempel vom DWD scheinen UTC zu sein. Wird das berücksichtigt?

Das stimmt, allerdings sind die Readings im DWD Device auf Localtime umgerechnet (außer fc_dwdDocTime zur Zeit). Ausgewertet wird fc_time welches Localtime ist, also kein UTC.
Voraussetzung dafür ist aber, dass die Installation von DWD entsprechend Wiki richtig ausgeführt wurde.

Zum Anhang:
Warum wird mir hier ein "i" angezeigt und kein "grüner Punkt"?

Das ist eine Information. In dem Fenster ist zuwenig zu sehen. Wenn du mehr postest kann ich dir Auskunft geben.

Grüße,
Heiko

[SparcWolf]

Beim "Mouse-Over" wird mir  10 Uhr angezeigt, was 11 Uhr Ortszeit entsprechen müsste.
Also "10:00:00Z" oder "10:00:00 UTC" fände ich hier besser.

Auf welches Wiki beziehst Du dich ( ... Installation von DWD entsprechend Wiki .. ) ?

Welches "mehr" würdest Du gerne sehen?

Danke und Gruß,
  Guido.

[DS_Starter]

Beim "Mouse-Over" wird mir  10 Uhr angezeigt, was 11 Uhr Ortszeit entsprechen müsste.
Also "10:00:00Z" oder "10:00:00 UTC" fände ich hier besser.

Es wird das angezeigt, was im DWD-Device im Reading fc_time steht. Und das ist keine UTC Zeit sondern Local, deswegen wäre der Zusatz Z/UTC nicht richtig.

Auf welches Wiki beziehst Du dich ( ... Installation von DWD entsprechend Wiki .. ) ?

Das DWD-Wiki: https://wiki.fhem.de/wiki/DWD_OpenData

Welches "mehr" würdest Du gerne sehen?

Siehe mein Beispiel.

[SparcWolf]

OK, dann hat der DWD getrödelt. Die 10 Uhr Daten waren erst nach 11 Uhr verfügbar.

Danke, werde das DWD-Wiki nochmal sichten.

Im Anhang ist ein neuer Screenshot.

VG,
  Guido.

[DS_Starter]

OK, dann hat der DWD getrödelt. Die 10 Uhr Daten waren erst nach 11 Uhr verfügbar.

Da müsstest du tatsächlich nochmal schauen. Verzögerungen kommen zwar mal vor, allerdings eher selten.
Normalerweise sind die Werte nach ca. xx:25 verfügbar.

EDIT: Eine falsche Zeit bei den DWD Readings hätte auch Auswirkungen bzgl. einer Verschiebung deiner Vorhersage um 1 Stunde!

Jetzt sieht man es ...
Die Info bezieht sich darauf dass das gewählte SF-Model kein AI/KI unterstützt.

Grüße,
Heiko

[SparcWolf]

Ich habe mir die DWD Daten nochmal angesehen.

Um 22:59 CET gab es eine neue MOSMIX_L_LATEST_10400.kmz.
Zeitstempel der Datei 21:56 (vermutlich UTC).
In der Datei:
  IssueTime  2024-03-03T21:00:00.000Z
  1. TimeStep 2024-03-03T22:00:00.000Z

Der erste Datensatz ist dann für die Stunde ab 23:00 CET.
Passt. Habe mich nur verwirren lassen.

OK, wegen der AI/KI. Alles klar.

Grüße,
  Guido.

[minierm]

Hallo minierm,

in deiner pvHistory gibt es den Tag 08 und 8, woher auch immer der Eintrag kommt ist er falsch/überflüssig.
Lösche ihn einfach mit:

Code Auswählen Erweitern

set <name> reset pvHistory 8    (nicht 08)


Danke, Tag 8 ist gelöscht.

Ich weiss jetzt, warum es Tag 8 statt 08 gibt: Weil ich reset 8 10 statt 08 10 ausgeführt habe
Bei der Eingabe müsste wohl generell auf zweistellig gewandelt werden damit solche Fälle abgefangen werden.

[DS_Starter]

Guter Hinweis, danke.
Kommt mit in das nächste Update.

LG

[stefanru]

Hi Heiko,

kurze Frage.
Habe heute gesehen dass in der Grafik Werte unter 1000 Wh nicht mehr angezeigt werden?
Ist das neu? Hab ich etwas verpasst?

Du darfst diesen Dateianhang nicht ansehen.

Danke und Gruß,
Stefan

[DS_Starter]

Hallo Stefan,

Ist das neu? Hab ich etwas verpasst?

Weder noch.
Das ist eine Frage des Platzes. Du kannst mit dem Attr graphicBeamHeight spielen um dein Optimum zu finden.

Grüße,
Heiko

[stefanru]

Ah jetzt ja

War schon meine Schuld.
Habe graphicBeamHeight heruntergesetzt damit es in mein Tablet UI passt.

Mit dem Standard von 200 sieht alles super aus.

Danke!

[DS_Starter]

Hallo zusammen,

morgen früh ist eine neue Version im Update.
Maßgebliche Inhalte sind:

- in der Anzeige des Wetter/Strahlungs Alters der Daten wird die verwendete MOSMIX Variante beachtet
- im ConfigCheck wird die verwendete MOSMIX Variante (das DWD Attr forecastRefresh) sowie das Alter geprüft
- die Mouse-Over der relevanten LED's ist angepasst
- diverse Code Changes

Die Version findet ihr bereits jetzt in meinem contrib.
Dort liegt auch die aktuelle / getestete Entwicklungsversion von 55_DWD_OpenData.
Ab dieser DWD_OpenData Version ist das Attribut forecastRefresh für die MOSMIX Variante zu verwenden (1=MOSMIX_S, 6=MOSMIX_L).
Holt euch auch diese Version damit die Prüfungen/Anzeigen optimal zusammenarbeiten.

Grüße,
Heiko

[kask]

werden, wenn mehrere dwd devices angelegt sind, die MOSMIX_S Werte nur einmal abgefragt? oder hintereinander? oder wenn es der Zufall es so will, alle zusammen?

[DS_Starter]

Die DWD Devices haben einen zufällig gesteuerten Zeitversatz zueinander. Damit wird die Wahrscheinlichkeit minimiert gleichzeitig ablaufende Prozesse zu haben, ausgeschlossen ist es jedoch nicht.
Geplant ist mit einem DWD Device mehrere Stationen in einem Abruf zu parsen.