Leistungsprognose für Wechselrichter

DS_Starter · 09 Januar 2024, 22:41:46

Der Gesamtwert des Hauses ist ein zusammengesetzter Wert, der aus PV-Erzeugung, Meterwert Einspeisung, Meterwert Bezug und ggf. Batterie ein/aus gebildet wird.
Wahrscheinlich wären bei dir die Schlüssel gcon und gfeedin im currentMeterDev anzupassen, d.h. die dort angegebenen Readings müssen den Wert (2) statt (3) repräsentieren.

Wscheff · 09 Januar 2024, 22:57:52

Danke für die schnelle Rückantwort. Ich wollte nur wissen ob ich in der Konfiguration was übersehen habe, scheint also nicht der Fall zu sein.

Ich habe jetzt nach der Antwort verstanden, dass das Haus-Symbol die Summe der ConsumerXX plus das currentMeterDev (Lampe) anzeigt, richtig?

Dann werde ich mir für meine Konfiguration wohl ein Dummy basteln

DS_Starter · 09 Januar 2024, 23:02:04

ZitatIch habe jetzt nach der Antwort verstanden, dass das Haus-Symbol die Summe der ConsumerXX plus das currentMeterDev (Lampe) anzeigt, richtig?

Im Prinzip ja, allerdings ist die Logik etwas anders. Die Lampe zeigt die Restmenge aus GesamtConsumption (das Haus) minus aller Verbraucher mit Energiemessung an, also die Energie die nirgendwo einem Verbraucher zugeordnet werden kann.

Wscheff · 09 Januar 2024, 23:09:15

Zitat von: DS_Starter am 09 Januar 2024, 23:02:04
ZitatIch habe jetzt nach der Antwort verstanden, dass das Haus-Symbol die Summe der ConsumerXX plus das currentMeterDev (Lampe) anzeigt, richtig?
Im Prinzip ja, allerdings ist die Logik etwas anders. Die Lampe zeigt die Restmenge aus GesamtConsumption (das Haus) minus aller Verbraucher mit Energiemessung an, also die Energie die nirgendwo einem Verbraucher zugeordnet werden kann.

Ok dann muss ich meine Anlage nochmal anschauen. Vielen Dank!

DS_Starter · 09 Januar 2024, 23:23:10

Die Lampe kann man übrigens mit dem Attr flowGraphicShowConsumerDummy ausblenden.

DS_Starter · 10 Januar 2024, 20:28:43

Hallo zusammen,

ich habe realisiert, dass automatsch einige Sekunden vor dem Ende sowie einige Sekunden nach dem Start einer vollen Stunde jeweils eine Datensammlung erfolgt sofern ctrlInterval nicht explizit auf "0" gesetzt ist.
Dadurch werden alle Datensammlungen der Energieerzeugung und Verbrauchs genauer als bisher im Stundenzyklus erfasst.
Voraussetzung dafür ist natürlich, dass die Daten in den Quellendevices ebenfalls sehr zeitnah aktualisiert werden was im Modul nicht beeinflusst werden kann.

Mit ctrlDebug=collectData erkennt man die Datensammlungen außer der Reihe:
...
2024.01.10 13:59:49.744 1: SolCast DEBUG> Start of unscheduled data collection at the end of an hour
2024.01.10 13:59:49.746 1: SolCast DEBUG> collect Weather data - device: DWD.Solar.Forecast =>
2024.01.10 13:59:49.747 1: SolCast DEBUG> sunrise/sunset today: 08:13 / 16:25, sunrise/sunset tomorrow: 08:12 / 16:27
2024.01.10 13:59:49.748 1: SolCast DEBUG> wid: fc0_14_ww, val: 0, txt: Bewölkungsentwicklung nicht beobachtet, cc: 20, rp: 2.00, temp: -4.20
...
2024.01.10 13:59:49.779 1: SolCast DEBUG> collect Inverter data - device: InverterDummy =>
2024.01.10 13:59:49.779 1: SolCast DEBUG> pv: 3489 W, etotal: 57412910 Wh
2024.01.10 13:59:49.780 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2024.01.10 13:59:49.781 1: SolCast DEBUG> gcon: 20.5 W, gfeedin: 0 W, contotal: 529916.6 Wh, feedtotal: 7566.6 Wh
2024.01.10 13:59:49.782 1: SolCast DEBUG> collect Battery data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2024.01.10 13:59:49.783 1: SolCast DEBUG> pin=2680 W, pout=0 W, totalin: 1336321.71428482 Wh, totalout: 1273522.83564187 Wh, soc: 89
2024.01.10 14:00:04.401 1: SolCast DEBUG> Start of unscheduled data collection at the beginning of an hour
2024.01.10 14:00:04.406 1: SolCast DEBUG> collect Weather data - device: DWD.Solar.Forecast =>
2024.01.10 14:00:04.409 1: SolCast DEBUG> sunrise/sunset today: 08:13 / 16:25, sunrise/sunset tomorrow: 08:12 / 16:27
2024.01.10 14:00:04.410 1: SolCast DEBUG> wid: fc0_15_ww, val: 0, txt: Bewölkungsentwicklung nicht beobachtet, cc: 18, rp: 2.00, temp: -4.40
...

Das Feature ist eingescheckt und morgen früh im Regelupdate enthalten.

TheTrumpeter · 10 Januar 2024, 21:03:16

Wow, das ging ja schnell, Danke.
Werde das Update morgen früh gleich machen.

DS_Starter · 10 Januar 2024, 21:05:11

Ja ... musste erstmal dahinterkommen wie es umsetzbar wäre.

DS_Starter · 15 Januar 2024, 22:19:17

In meinem contrib liegt die V1.7.0.
Die wichtigste Neuerung ist im Consumer Management. Nach der initialen Planung erfolgt ein Review der Planungsdaten jedes Consumers alle 30 Minuten (xx:15, xx:45) sofern der Consumer noch nicht gestarted wurde (also nur planned) bzw. suspended (ausgesetzt wegen zu wenig erwarteten Überschuß).
Es erfolgt in dem Fall eine Neuberechnung mit den dann verfügbaren Vorhersagedaten.

Ein ctrlDebug = consumerPlanning zeigt dann z.B. diese Ausgabe:

Code Auswählen

2024.01.15 21:45:58.498 1: SolCast DEBUG> consumer "05" - Review switch time planning name: SolCastDummy4 alias: SolarForecast Consumer Dummy 4
2024.01.15 21:45:58.499 1: SolCast DEBUG> consumer "05" - Consider consumption forecast in consumer planning: no
2024.01.15 21:45:58.500 1: SolCast DEBUG> consumer "05" - epiece1: 1000.00
2024.01.15 21:45:58.500 1: SolCast DEBUG> consumer "05" - mode: can, mintime: 5, relevant method: surplus
2024.01.15 21:45:58.501 1: SolCast DEBUG> consumer "05" - surplus expected: 24, starttime: 2024-01-16 08:00:00, nexthour: 11, today: 0
2024.01.15 21:45:58.501 1: SolCast DEBUG> consumer "05" - surplus expected: 175, starttime: 2024-01-16 09:00:00, nexthour: 12, today: 0
2024.01.15 21:45:58.502 1: SolCast DEBUG> consumer "05" - surplus expected: 709, starttime: 2024-01-16 10:00:00, nexthour: 13, today: 0
2024.01.15 21:45:58.502 1: SolCast DEBUG> consumer "05" - surplus expected: 924, starttime: 2024-01-16 11:00:00, nexthour: 14, today: 0
2024.01.15 21:45:58.503 1: SolCast DEBUG> consumer "05" - surplus expected: 972, starttime: 2024-01-16 12:00:00, nexthour: 15, today: 0
2024.01.15 21:45:58.503 1: SolCast DEBUG> consumer "05" - surplus expected: 652, starttime: 2024-01-16 13:00:00, nexthour: 16, today: 0
2024.01.15 21:45:58.504 1: SolCast DEBUG> consumer "05" - surplus expected: 5, starttime: 2024-01-16 14:00:00, nexthour: 17, today: 0
2024.01.15 21:45:58.504 1: SolCast DEBUG> consumer "05" - surplus expected: 84, starttime: 2024-01-16 15:00:00, nexthour: 18, today: 0
2024.01.15 21:45:58.505 1: SolCast DEBUG> consumer "05" - surplus expected: 0, starttime: 2024-01-16 23:00:00, nexthour: 26, today: 0
2024.01.15 21:45:58.505 3: SolCast - Consumer "SolarForecast Consumer Dummy 4" suspended: the max expected surplus is less 1000.00

Durch diese Implementierung kann die Consumerplanung nunmehr dynamisch auf sich verändernde bzw. zeitlich verschiebende PV-Erzeugungen reagieren.
Bevor ich das Release einchecke, mchte ich das Verhalten noch ein wenig testen.
Wer das auch tun möchte, kann die V herunterladen UND auf jeden Fall danach FHEM restarten!

Grüße,
Heiko

DS_Starter · 18 Januar 2024, 22:23:50

eingecheckt und morgen früh im Update.

TheTrumpeter · 19 Januar 2024, 12:05:37

Danke, erster Eindruck: Funktioniert

Tomk · 20 Januar 2024, 14:16:05

Hat eigentlich keiner außer mir das Problem das aufgrund von Schnee kein Strom erzeugt wird? Somit verlernt solarForecast die mühsam gelernten Werte! Kann man nicht bei Temperaturen dauerhaft unter null und einer Erzeugung kleiner 5% automatisch von Schnee ausgehen und die Prognose entsprechend anpassen sowie den lernalgo stoppen?

Danke schonmal für eure Meinung.

ch.eick · 20 Januar 2024, 18:01:38

Zitat von: Tomk am 20 Januar 2024, 14:16:05Hat eigentlich keiner außer mir das Problem das aufgrund von Schnee kein Strom erzeugt wird? Somit verlernt solarForecast die mühsam gelernten Werte! Kann man nicht bei Temperaturen dauerhaft unter null und einer Erzeugung kleiner 5% automatisch von Schnee ausgehen und die Prognose entsprechend anpassen sowie den lernalgo stoppen?

Hallo zusammen,
in meiner KI_Prognose helfe ich der KI einwenig, indem ich die euphorischen Prognosen mit einem Maximum limitiere. Da hört die KI in Grenzbereichen dann doch auf.

Code Auswählen

1. Das Maximum des Yield aus der Prognose darf nie größer wie der Durchschnitt der letzten 30 Tage sein.
2. Ist der gestrige Tag kleiner wie 10 % von Punkt 1. , dann liegt Schnee, oder eine Decke :-) auf den Modulen.

In beiden Fällen begrenze ich die KI_Prognose auf das jeweilige yield Maximum.
Ob es bei den 10% bleibt oder nicht werde ich festlegen, wenn der Schnee runter rutscht.
Gestern hatte ich 1 kWh und die Prognose für heute ist 940 Wh.
Der WR sagt momentan "SW_Statistic_Yield_Day 344", was mir gut genug ist

VG Christian

DS_Starter · 20 Januar 2024, 18:39:38

ZitatHat eigentlich keiner außer mir das Problem das aufgrund von Schnee kein Strom erzeugt wird? Somit verlernt solarForecast die mühsam gelernten Werte! Kann man nicht bei Temperaturen dauerhaft unter null und einer Erzeugung kleiner 5% automatisch von Schnee ausgehen und die Prognose entsprechend anpassen sowie den lernalgo stoppen?

So dramatisch ist das nicht. Die maximale Änderung der Korrekturfaktoren (ohne KI) ist per default auf 0.5 begrenzt und verhindert exorbitante Anpassungen. Darüber hinaus kannst du mit dem Attribut affectMaxDayVariance den Anpassungsfaktor begrenzen bzw. abschalten.

Wenn du

affectMaxDayVariance = 0.0

setzt, erfolgt keine Anpassung der verwendeten Faktoren. Du kannst das Attribut in den Wintermonaten auch stark heruntersetzen, z.b. 0.02 o.ä. Das kann man natürlich auch automatisieren abhängig von dem Wetter in deiner Gegend.
Mit KI bekommt die KI auch die Temperaturen mitgeteilt und lernt dadurch auch diesen Zusammenhang. Dauert halt seine Zeit.
Wenn dir diese Möglichkeiten noch nicht ausreichen, kann ich den Setter pvCorrectionFactor_Auto noch erweitern um z.B. eine Option "noLearning" damit im Hintergrund auch der KI keine Werte zugeführt werden.
pvCorrectionFactor_Auto ist deswegen auch als Settr und nicht als Attribut ausgeführt damit man die Arbeitsweise dynamisch per notify oder DOIF umschalten lassen kann.

Übrigens ist Temp. kleiner 0 nicht mit Schnee auf den Modulen gleichzusetzen. Heute hatte ich -5 Grad und volle Sonne. Kein Schnee auf den Modulen weil sie vorgestern bereits durch die Südlage abgetaut (runtergerutscht) waren und hat 27kWh erzeugt.
D.h. die Anforderungen können je nach Lage sehr unterschiedlich sein.

LG,
Heiko

DS_Starter · 20 Januar 2024, 19:06:34

Allerdings ...

ZitatKann man nicht bei Temperaturen dauerhaft unter null und einer Erzeugung kleiner 5% automatisch von Schnee ausgehen und die Prognose entsprechend anpassen sowie den lernalgo stoppen?

... kann ich schon implementieren. Nur was versteht man unter "dauerhaft" und wo zieht man die Grenze zu "vorübergehend"?
Und wie steht es mit der Schneebedeckung wenn es kleiner 8% aber größer 5% sind? Liegt dann kein Schnee?
Die Frage kann man beliebig variieren .... was ist mit Schnee wenn die Erzeugung zwischen 5% und 15%? Nur ein Teil der Module bedeckt oder "dünne" Schneedecke?