Leistungsprognose für Wechselrichter

[DS_Starter]

Ah, selbst gemachtes Elend.
Irgendwann gab es mal das Märchen IT würde Zeit sparen.   

[grappa24]

wie krieg ich denn diese FTUI-Warnung weg?

[DS_Starter]

Möglicherweise ein Problem mit deiner Internetverbindung?

[minierm]

Interessant wäre natürlich wieso du dir so oft Falscheinträge einhandelst.
Hast du eine Idee?

Bei mir war es M-Tec, die bei einem Wert zwischendurch einen Einbruch haben.
Statt MTEC_Station data_curve_01_eTotal muss ich MTEC_Station data_eRatioGraph_eDayTotal nehmen obwohl es kein Tageswert ist.
Ähnlich beim Verbrauch, MTEC_Station data_eRatioGraph_eUse statt MTEC_Station data_curve_01_eusetotal.
Wobei MTEC_Station von dieser API kommt:

Code Auswählen Erweitern

https://energybutler.mtec-portal.com/api/sys/curve/station/queryStationBarChartDu darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

@grappa24, @all,

ich habe soeben ein Update der V1.6.0 in mein contrib geladen. Bei dem FTUI check wird nun bei einem negativen Testergebnis wie bei dir eine nähere Angabe zu der Fehler-Ursache erscheinen.

Außerdem gibt es im ctrlDebug einen Eintrag "batterieManagement" um sich nähere Informationen zur Generierung des Wertes im Reading Battery_OptimumTargetSoC auszugeben.
Ein paar Erkenntnisse sind bereits in die Logik zum Battery_OptimumTargetSoC eingeflossen.

[grappa24]

@grappa24
Bei dem FTUI check wird nun bei einem negativen Testergebnis wie bei dir eine nähere Angabe zu der Fehler-Ursache erscheinen.

da fehlte bei mir eine Datei:

Code Auswählen Erweitern

automatic check of SVN widget_smaportalspg.js version not possible: No such file or directory.

Code Auswählen Erweitern

get <SolarForecast-Device> ftuiFramefileshat das Problem gelöst.

[DS_Starter]

Ja, sieht so aus. Setze dir bitte verbose 5 im SolarForecast und führe den Check nochmal aus.
Im Log wird dann einiges stehen. Poste das dann bitte.

[DS_Starter]

Ich denke ich weiß wie die Lösung aussehen kann. Zieh dir die V1.6.0 aus dem contrib bitte nochmal und führe den Check aus. Dann sollte in der Spalte Note eine entsprechende Handlungsanweisung stehen.

[grappa24]

sorry, ich hatte geschrieben aber nicht abgeschickt ...

Code Auswählen Erweitern

get <SolarForecast-Device> ftuiFramefileshat mein Problem gelöst

[kask]

Ich nutze, zum testen, alle 4 möglichkeiten der Vorhersage: SolCastAPI, DWD, ForecastSolarAPI, Victron.
Die Parameterfütterung ist identisch sofern die Werte benötigt werden.

Die ForecastSolarAPI hat einen unheimlich großen Korrekturfaktor um 15Uhr. In den Balkendiagramm sind absolut utopische Werte um 14Uhr abgebildet.
Das gleiche für die SolCastAPI. Zudem ist mir dort aufgefallen das die höchsten Korrekturfaktoren um 7,15 & 20 auftretten. Vlt. Schattenwurf könnte sein.
Ich weiß nicht wieso das zustande kommt. Hat einer eine Idee?


Zum Vegleich habe ich noch die DWD angehangen. VictronVRM verhält sich ähnlich zu DWD.

@DS_Starter
Kann ich nur die "pvcorrf" manuell irgendwie, vieleicht über Umwege, anpassen?

[DS_Starter]

Kann ich nur die "pvcorrf" manuell irgendwie, vieleicht über Umwege, anpassen?

Ja, es gibt die Setter pvCorrectionFactor_XX zur Vorgabe eines festen Faktors für die Stunde XX des Tages.
Bei deinem Beipiel wäre es etwa:

 

Code Auswählen Erweitern

set ... pvCorrectionFactor_15 1.8

Eine Möglichkeit dass sich sowas manifestiert ist zum Beipiel, wenn man "mal" einen starken Ausreißer zwischen Vorhersage/Ist hatte UND das Attribut affectMaxDayVariance auf einen relativen hohen Wert gesetzt war bzw. ist.
Normalerweise hat dieses Attr einen Wert von 0.5 (kann man einstellen), d.h. die tägliche Veränderung des Korrekturfaktors darf maximal 0.5 sein. Das schützt das System vor unverhältnismäßig hohen Faktoren wenn man solche Ausreißer mal hat.

Die zur Anwendung kommenden Korrekturfaktoren findet man in der pvCircular. Sie werden fortwährend fortgeschrieben und neu über Durchschnitte errechnet. Der Schlüssel corr enthält den Faktor für die jeweilige Stunde des Tages, wobei "percentile" der einfache (simple) Korrekturfaktor ist. Die anderen haben den Bezug zur entsprechenden Bewölkung.

Code Auswählen Erweitern

      corr: 0=0.99 6=1.03 7=1.10 13=1.19 15=0.85 16=1.00 17=1.01 19=0.95 20=1.08 21=0.99
            22=0.92 23=0.99 25=0.95 27=0.98 28=1.12 29=1.00 30=0.93 31=0.91 33=1.50 34=0.74
            35=0.49 36=1.09 37=1.07 38=1.00 40=1.06 42=1.50 44=1.25 45=1.07 46=1.06 47=0.80
            48=1.03 50=0.71 51=1.00 52=0.75 54=1.19 55=1.14 56=0.97 57=1.10 58=1.58 59=1.01
            60=0.67 61=0.54 62=1.39 63=1.73 64=1.04 65=0.34 66=1.41 67=1.24 68=1.10 69=1.47
            70=1.69 71=1.30 72=1.35 74=0.85 75=1.00 76=1.50 77=0.65 78=1.27 79=0.88 80=0.80
            81=0.96 82=1.30 83=0.96 84=0.91 85=0.32 86=0.82 87=1.11 88=1.40 90=0.80 92=1.33
            93=1.73 94=1.50 95=0.56 98=1.37 99=0.74 100=0.52
            percentile=0.96

Bei dir wird sich in der pvVircular zur Stunde 15 (Achtung im Diagramm ist die Stunde 15 des Tages Beginn 14 (uhr) ) ein oder mehrere hohe Werte bei der entsprechenden Bewölkung finden.
Man kann die Korrekturfaktoren dieser Stunde aus der pVCircular löschen:

Code Auswählen Erweitern

set <name> reset pvCorrection cached 15

Leider sind dann alle Korrekturfaktoren dieser Stunde verloren und müssen sich neu aufbauen.
Advanced User können einen falschen Wert auch sehr selektiv entfernen.
Dazu:

 1. FHEM stoppen
 2. die Datei PVC_SolarForecast_<name> in einem Editor öffnen und den falschen Wert, z.B. "94":"6.47", aus der Datei löschen
 3. FHEM starten, die pvCircular wird wieder eingelesen

Dadurch sind nicht alle Korrekturwerte dieser Stunde verloren.

[kask]

OK, das schaue ich mir mal genauer an. Verstehe ich jetzt so auf die schnelle nicht.
Das Atribute affectMaxDayVariance war bei mir nirgends gesetzt. Habe ich erst einmal so überaLL eingepflegt.

[DS_Starter]

Kurzes Update zu den laufenden Tests der V 1.6.0.
Gestern und heute waren bezogen auf die Güte der Vorhersagen sehr gute Tage mit einer Abweichung von lediglich 1,2% pro Tag.
Heute war verstärkt mit weniger Wolken bzw. etwas Sonnenschein zu rechnen, entsprechend wurde der SoC im Reading Battery_OptimumTargetSoC vom Modul von 50% auf 10% gesenkt. Das habe ich heute früh manuell im Batteriesystem nachgezogen.

Zu beobachten war, dass durch die zutreffende Prognose heute der SoC bis auf ca. 90% zulegen konnte. Es wurde sämtliche erzeugte Energie entweder sofort verbraucht oder in der Bat gespeichert. Momentan hat sich der SoC durch die Bat-Entladung wieder auf 83% verringert, wird aber gut bis in der morgigen Tag hinein reichen.

Auch morgen ist wieder viel Sonne vorhergesagt und das Modul belässt den Min SoC im Reading Battery_OptimumTargetSoC auf 10%. Dadurch ist die Batterie morgen wieder bereit die Ladung aufzunehmen, was das Ziel ist.

Weiterhin beobachte ich, dass der SoC der Batterien im Verbund mittlerweile deutlich erkennbar auseinanderdriftet. Wahrscheinlich wird morgen durch die Aufladung der Minimum maxSoC von 95% erreicht was den Verbund wieder harmonisieren sollte. Allerdings zeigt es auch, dass die von mir bisher veranschlagten 30 Tage zwischen zwei maxSoC Ladungsereignissen zu weit auseinander liegen dürften. kask hatte es bereits vermutet. Wahrscheinlich werde ich diesen Wert (careCycle) von default 30 auf 15 oder 20 Tage reduzieren. "Leider" wird morgen vermutlich der Zähler wieder auf 0 gestellt wenn maxSoC erreicht werden sollte.

Soweit meine aktuellen Beobachtungen zum Batterie Management.

[kask]

Wie bekomme ich den manuell gesetzten Wert wieder auf Auto?

[DS_Starter]

Mit

Code Auswählen Erweitern

set ... reset pvCorrection

Das löscht NICHT die gecachten Korrekturwerte, nur die Readings und die internen Strukturen dazu.
Sie werden automatisch wieder erstellt.