76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[peterboeckmann]

Hallo 300P, hallo Heiko,

das "Problem" besteht schon länger als Version 2.5.3. Ich habe die Version 2.5.1 und ein ähnliches Bild:
Du darfst diesen Dateianhang nicht ansehen.

Die doppelten Einträge im Log habe ich auch, allerdings jeweils nur für morgen:
Du darfst diesen Dateianhang nicht ansehen.

Folgendes DbRep wird per at jede Nacht um 23:47 Uhr ausgeführt, damit ich wenigstens den aktuellen Tag "sauber" habe:

Code Auswählen Erweitern

defmod Rep.Del.AllPVforecastsToEvent DbRep logdb
attr Rep.Del.AllPVforecastsToEvent alias Löschen Readings AllPVforecastsToEvent des Folgetages
attr Rep.Del.AllPVforecastsToEvent comment ermöglicht dass die Readings AllPVforecastsToEvent am Folgetag wieder neu und aktuell geschrieben werden können
attr Rep.Del.AllPVforecastsToEvent devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.AllPVforecastsToEvent device SolarForecast
attr Rep.Del.AllPVforecastsToEvent disable 0
attr Rep.Del.AllPVforecastsToEvent event-on-update-reading state
attr Rep.Del.AllPVforecastsToEvent group Z_Automatik
attr Rep.Del.AllPVforecastsToEvent icon edit_delete
attr Rep.Del.AllPVforecastsToEvent reading AllPVforecastsToEvent
attr Rep.Del.AllPVforecastsToEvent room Garten->PV-Anlage
attr Rep.Del.AllPVforecastsToEvent showproctime 1
attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end next_day_end
Ich meine, wir hatten das Thema vor längerer Zeit schonmal.
Wenn ich mich recht erinnere, liegt das daran, dass das Event "AllPVforecastsToEvent" jede Nacht mit allen verfügbaren Daten für den aktuellen Tag und die Folgetage gefeuert wird. Dadurch kommen die Werte eben mehrfach in die LogDB.

Warum jetzt aber bei 300P verschiedene Zeitstempel (19:59:59, 20:00:00, 20:00:01) dran stehen, kann Heiko vielleicht herausfinden.
Findet da irgendwo eine Addition der Zeiten statt, die bei mir innerhalb der 59. Sekunde abgeschlossen ist und bei 300P zwei Sekunden dauert?

Viele Grüße,
Peter

[DS_Starter]

Moin Peter,

Wenn ich mich recht erinnere, liegt das daran, dass das Event "AllPVforecastsToEvent" jede Nacht mit allen verfügbaren Daten für den aktuellen Tag und die Folgetage gefeuert wird. Dadurch kommen die Werte eben mehrfach in die LogDB.

Ja, genauso ist es. Das ist technisch bedingt. Sonst hat man nicht die Prognose für die nächsten Tage als initiale Vorhersage. Deswegen muß man mit DbRep eine Bereinigung vornehmen.
Die initialen Events werden täglich ca. 5 Minuten nach Mitternacht gefeuert. Wenn man wie du kurz vor Mitternacht die DB räumt, sollte das passen.
Allerdings räumt timestamp_end=next_day_end nur bis Ende des Folgetages. Die Events reichen aber bis ca. 72 Stunden in die Zukunft. Das war "früher" nicht so breit.
Ich würde es mit timestamp_end=current_month_end versuchen. Leider gibt DbRep momentan kein z.B. "next 5 days" her. Wäre mal etwas für den Entwickler. 

Bei mir sieht es völlig i.O. aus.

LG,
Heiko

[peterboeckmann]

Hallo Heiko,

Ich würde es mit timestamp_end=current_month_end versuchen.

Danke für den Tipp. Ich habe jetzt mal gleich "current_year_end" gesetzt. Dann kommen bei mir nur noch am Jahreswechsel unsaubere Diagramme raus.

Viele Grüße,
Peter

[300P]

EDIT:
ups - bin zu langsam beim Umsetzen und schreiben......


...Danke
Dann nehme ich mal Ende des laufenden Jahrs. Zur Jahreswende achte ich nicht so auf die PV-Grafiken 

Code Auswählen Erweitern

attr Rep.Del.AllPVforecastsToEvent timestamp_begin next_day_begin
attr Rep.Del.AllPVforecastsToEvent timestamp_end current_year_end

[tupol]

Die gefühlte 24h Verschiebung kommt durch die Umstellung auf Sommerzeit zustande. Die Korrekturfaktoren müssen sich erst der neuen Situation anpassen.

Hallo Heiko,
also die Vorsage-Werte sind Ok. Es ist also nicht die Zeitumstellung. Dazu ist die Passung zu den tatsächlichen Werten auch zu auffällig.

Ich habe zwei DWD-Vorhersagen von zwei Nachbarorten konfiguriert. Kann das was damit zu tun haben?

Könnte eine Ursache auch sein, dass die Werte vom DWD zum Zeitpunkt der Event-Trigger noch vom Vortag sind?

Gruß
Tupol

[DS_Starter]

Ich habe zwei DWD-Vorhersagen von zwei Nachbarorten konfiguriert. Kann das was damit zu tun haben?

Wenn du damit zwei Wetter-Devs meinst, glaube ich das nicht. Die wären zu dicht nebeneinander und werden auch gemerged.

Könnte eine Ursache auch sein, dass die Werte vom DWD zum Zeitpunkt der Event-Trigger noch vom Vortag sind?

Das ist ein guter Hinweis! Ich feuere kurz nach Mitternacht. Vllt. wäre es besser das erst nach 1:00 oder gar 3:00 zu machen damit vorher DWD sicher aktualisiert hat.

LG,
Heiko

[tupol]

Meine DWD-Device gibt immer die nächsten zwei Tage aus. Vielleicht ist es möglich, das Datum zu berücksichtigen?

[DS_Starter]

Meine DWD-Device gibt immer die nächsten zwei Tage aus. Vielleicht ist es möglich, das Datum zu berücksichtigen?

Leider nicht wirklich konsequent machbar. Wir haben auch noch andere API's bei denen es kein Aktualisierungsdatum als solches gibt. Ein DWD Device ist nur eine mögliche Quelle.
Aber wenn ich die Eventgenerierung genügend weit schiebe, sollte es kein Problem mehr geben. Ich werde es mal einrichten und dann werden wir ja sehen wie es sich macht.

[tupol]

Diese Fehlernachricht nach dem Update hatte ich übersehen: "SolarVorhersage - WARNING - device "DWD" -> attribute "forecastProperties" should contain: FF"

Ich hoffe, dass ist nicht die Ursache.

[DS_Starter]

FF ist Windgeschwindigkeit, wird die Environmentparameter verwendet. 

[DS_Starter]

Ich habe ein Update der 2.6.0 in mein contrib geladen.
Die spezielle Eventgenerierung habe ich auf ca. 03:10 verlegt.
Weiterhin wurde in dieser Version stark in Caching investiert. In den Internals erahnt man etwas von der Arbeit der Caches. Dadurch konnte ich die Laufzeit eines Zyklus bei mir fast halbieren.
Es gibt das Reading Tomorrow_CONforecast. Es wird das Reading Tomorrow_ConsumptionForecast ablösen. Für eine Übergangszeit bleibt das Reading Tomorrow_ConsumptionForecast bestehen bis ich es mit Vorankündigung entferne.
Wer es irgendwo verwendet kann schon langsam auf Tomorrow_CONforecast umstellen.

LG,
Heiko

[300P]

Weiterhin wurde in dieser Version stark in Caching investiert. In den Internals erahnt man etwas von der Arbeit der Caches. Dadurch konnte ich die Laufzeit eines Zyklus bei mir fast halbieren.

Bei mir sind es auch ca. 50 % (nach ein paar Minuten Laufzeit)
->> Stark!!!!
jetzt bin ich auch mit dem RPI4 und meiner etwas großen Last wieder unter 1 s Laufzeit     

[DS_Starter]

Ich arbeite noch weiter daran. Es gibt noch mehr Coding welches mit LRU Caching beschleunigt werden könnte.