76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Jetzt ist mir aufgefallen das meine configdb-Datenbank sehr groß geworden ist weil in der fhemb64filesave
eine Unmenge an PVH_SolarForecast_Solar_Cast_datum und PVC_SolarForecast_Solar_Cast_datum Dateien befinden.
Habe ich etwas falsch eingestellt? Kann ich die Daten entfernen?

Ja, die kannst du löschen. Es sind Sicherungsdateien, die du bei Nutzung von configdb im Prinzip nicht brauchst.
Deswegen kannst du bei dir

Code Auswählen Erweitern

plantControl->backupFilesKeep=0

einstellen. Dann werden die Dateien nicht mehr geschrieben.

[peterboeckmann]

Hallo Heiko,

bitte nochmal ziehen.

ich hatte die Version gezogen. Zeitstempel der Datei ist 30.01.2026 08:26:15.
FHEM habe ich nach dem Download neu gestartet.

Damit habe ich immer noch den Eindruck, dass der Anteil der aktuellen Stunde fehlt.
Hier mal einige Auszüge aus dem List mit meinen Berechnungen danach:

Code Auswählen Erweitern

     2026-01-30 09:35:34   RestOfDayPVforecast 2763 Wh
     2026-01-30 09:35:34   Today_PVdeviation -71.56 %
     2026-01-30 09:35:34   Today_PVforecast 2981 Wh
     2026-01-30 09:35:34   Today_PVreal    63 Wh
   
    bisher vorhergesagt: 2981-2763 = 218
    63/218 = x/100
    63/218*100 = 28,8
    100-28,8 = 71,2

Code Auswählen Erweitern

     2026-01-30 09:38:59   RestOfDayPVforecast 2759 Wh
     2026-01-30 09:38:59   Today_PVdeviation -67.43 %
     2026-01-30 09:38:59   Today_PVforecast 2977 Wh
     2026-01-30 09:38:59   Today_PVreal    71 Wh
    bisher vorhergesagt: 2977-2759 = 218
    71/218 = x/100
    71/218*100 = 32,6
    100-32,6 = 67,4
   

Code Auswählen Erweitern

     2026-01-30 09:46:33   RestOfDayPVforecast 2749 Wh
     2026-01-30 09:46:33   Today_PVdeviation -57.34 %
     2026-01-30 09:46:33   Today_PVforecast 2967 Wh
     2026-01-30 09:46:33   Today_PVreal    95 Wh
    bisher vorhergesagt: 2967-2749 = 218
    95/218 = x/100
    95/218*100 = 43,6
    100-43,6 = 57,4

Code Auswählen Erweitern

     2026-01-30 09:50:45   RestOfDayPVforecast 2991 Wh
     2026-01-30 09:50:45   Today_PVdeviation -50.92 %
     2026-01-30 09:50:45   Today_PVforecast 3209 Wh
     2026-01-30 09:50:45   Today_PVreal    107 Wh
    bisher vorhergesagt: 3209-2991 = 218
    107/218 = x/100
    107/218*100 = 49,1
    100-49,1 = 50,9

Code Auswählen Erweitern

     2026-01-30 09:56:06   RestOfDayPVforecast 2944 Wh
     2026-01-30 09:56:06   Today_PVdeviation -42.66 %
     2026-01-30 09:56:06   Today_PVforecast 3162 Wh
     2026-01-30 09:56:06   Today_PVreal    125 Wh
    bisher vorhergesagt: 3162-2944 = 218
    125/218 = x/100
    125/218*100 = 57,3
    100-57,3 = 42,7

Code Auswählen Erweitern

     2026-01-30 10:01:27   RestOfDayPVforecast 3023 Wh
     2026-01-30 10:01:27   Today_PVdeviation -79.37 %
     2026-01-30 10:01:27   Today_PVforecast 3716 Wh
     2026-01-30 10:01:27   Today_PVreal    143 WhWh
    bisher vorhergesagt: 3716-3023 = 693
    143/693 = x/100
    143/693*100 = 20,6
    100-20,6 = 20,6
   
Fazit: Die Berechnung kann ich nachvollziehen.
Aber: Today_PVforecast steigt, genau wie RestOfDayPVforecast, deren Differenz bleibt innerhalb der Stunde konstant.

Viele Grüße,
Peter

[DS_Starter]

Hallo Peter,

nein, der Eindruck täuscht.
Aber ich habe mich gestern zu einer Maßnahme hinreißen lassen, die falsch war jedoch im ersten Moment logisch erschien.
Die Tagesvorhersage wird immer von dem Datenlieferanten vorgegeben. Die vergangenen Stunden logischerweise dabei nicht mehr berücksichtigt.
D.h. die bisherige Berechnung ist absolut richtig. Allerdings müsste ich dafür sorgen, dass RestOfDayPVforecast nie größer als
Today_PVforecast werden kann da systembedingt vergangene Tagesstunden nicht mehr verändert werden.
Das hätte aber wieder andere Konsequenzen, da RestOfDayPVforecast ein wichtiger Faktor für andere Dinge ist wie z.B. Consumer- oder Batteriesteuerung
die einen höheren Stellenwert haben als eine Korrekturdifferenz zur Anziege die obendrein nur in bestimmten Fällen wie beschrieben auftritt.
Ich habe die Änderung von gestern Abend zurückgenommen und ins contrib gestellt. Vllt. fällt mir noch etwas dazu ein, mal schauen.

LG,
Heiko

[DS_Starter]

Habe eine Änderung ins contrib gestellt, die sich im Bedarfsfall NUR auf die Azeige auswirkt.
Die Readings bleiben unverändert.
Liegt im contrib.

[peterboeckmann]

Hallo Heiko,

ich habe mir die Readings nochmal angesehen und nachgerechnet:

Du darfst diesen Dateianhang nicht ansehen.

Es scheint, als wäre der Stundenanteil auf die Today_PVforecast addiert worden und nicht auf die RestOfDayPVforecast?

Viele Grüße,
Peter

[DS_Starter]

Ja genau und das hatte mich irritiert, ist aber falsch dies zu tun weil Today_PVforecast anders ermittelt wird wie beschrieben.
Deswegen Rolle rückwärts und wieder raus. Bei RestOfDayPVforecast ist der Anteil richtigerweise schon immer integriert.

[peterboeckmann]

Ok, ich hab die neue Version gezogen und schaue nachher mal drauf.

[Parallix]

@Parallix,

Da "noSchedule" auch kein wirklicher Typ ist, schlage ich vor, noSchedule als Attributwert für "mode" zu entfernen und die Maßnahmen für "noSchedule" dann anzuwenden, wenn der "mode"-Attributwert auf "mustNot" steht, bzw. aus einem Reading bezogen wird.

noSchedule gibt es als Option für "mode" nicht und kann somit dort nicht entfernt werden.
Wahrscheinlich meinst du vielmehr noSchedule als "type" zu entfernen und statt dessen "mode" zu ergänzen, sodass dann "mode" die Optionen can, must und noSchedule bekommen kann.

Ja, in der Tat meinte ich "noSchedule" als "type".

In der Realität würde das dann bedeuten der Consumer kann, muß oder wird nicht (noSchedule) eingeplant.

Ja, genau! Und da "mode" auch aus einem Reading bezogen werden kann, kann der Consumer dann auch dynamisch in der Planung einbezogen werden oder aber dort herausgelassen werden.

Programtechnisch würde ich dann sehr wahrscheinlich den type nicht entfernen, sondern nur den "mode" um diese Option ergänzen, je nachdem wie gut es umsetzbar ist ohne zu tief in den Code einzugreifen.
..

Die Ergänzung von der "mode"-Werte um "mustNot" ist in der Tat völlig ausreichend!