Funktionsprinzip/ Formel Nulleinspeisung

Begonnen von Huabafranze, 28 Februar 2024, 22:34:33

Vorheriges Thema - Nächstes Thema

Huabafranze

Hallo zusammen,
mittlerweile bin ich soweit, dass ich alle nötigen Komponenten meiner PV-Stromerzeugung in FHEM eingebunden habe:
Regelbarer Wechselrichter, Victron MPPT zum Batterie laden, und Shelly Pro3EM.
Mir stellt sich jetzt die Frage, wie konfiguriere ich jetzt genau eine Nulleinspeisung. Ziel ist natürlich bei einer Einspeisung in das Netz den Wechselrichter zu drosseln und die Leistung in die Ladung der Batterie zu stecken. Es geht mir erst einmal um das Prinzip und wenn jemand nen Code dafür erstellen kann, bin ich als Anfänger natürlich auch sehr dankbar.
Mein Gedankengang ist folgender: Ich könnte natürlich ganz einfach sagen: "Nimm die Einspeiseleistung und regle den Wechselrichter um diese Leistung runter". Allerdings ist dann natürlich beim nächsten Intervall  die Einspeiseleistung 0W, und somit wird der Wechselrichter auf Drosselung 0W gestellt. Das würde dann ständig hin und her springen.
Irgendwie müsste ich konfigurieren können: "Drossel den Wechselrichter alle 5 Sekunden um 10W bis die Einspeiseleistung 0W ist, und wenn die Bezugsleistung größer als 0 ist, erhöhe den WR alle 5 Sek. um 10 Watt (bis zur max. möglichen Leistung) bis die Leistung wieder 0W ist.
Die Werte sind natürlich nur als Beispiel zu sehen.
Vielleicht hat ja auch jemand eine ganz andere Idee und bestenfalls einen Code für mich.

LG, Franz

ch.eick

Moin,
da ist immer wieder die Frage, darfst Du der Gemeinschaft nichts schenken?

Generell brauchst Du natürlich noch eine gute Prognose für die zuerwartende Leistung, zumindest auf Stundenbasis.
Dann solltest Du den Speicher danach klug regeln, damit Du schon mal das Mittagshoch in den Speicher laden kannst.
Alle anderen Starkverbraucher sollten ebenfalls gut gesteuert werden.
Dann kommt noch der Regelalgorythmus, der im 1 Sekundentakt deine schon genannte Regelung vornimmt und den WR drosselt.
Bei meiner Anlage wird ja für den Speicher versucht am Zähler eine Null zu bekommen, das schwankt dann so von -15 bis +15 Watt .
Da dies möglichst schnell und zuverlässig sein soll verwendet mein Hersteller eine direkte rs485 Verbindung zwischen dem Smartmeter und dem WR, der auch den Speicher steuert (hybrid). Dies ist wohl notwendig, um die Zulassung nach den geltenden Vorschriften zu bekommen.
Wichtig bei dieser Aussage ist das "schnell" und "zuverlässig", wodurch LAN/WLAN somit raus wären, die 1 Sekunde wäre auch ein Kompromiss.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

DS_Starter

#2
Ich selbst habe einen SMA WR, drei Victron Multiplus und einen Victron SmartSolar MPPT komplett eingebunden.
Sowohl der MPPT als auch die Mutliplus laden bzw. können die Batterie (bei mir Pylontech) laden.
Es besteht die Herausforderung die Ladeleistung der Multiplus optimal in Bezug auf die zu erwartende PV (wie Christian schon schrieb) soweit zu reduzieren, dass der MPPT maximale Leistung fahren kann. Ist die Batterie voll, wird der MPPT sonst vom Victron System gedrosselt.
Das soll nicht passieren. Der SMA WR soll maximal arbeiten und seine Energie ins Hausnetz bringen oder den Überschuß einspeisen (verkaufen).

Das alles wird mit dem SolarForecast Modul möglich.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

ch.eick

Zitat von: DS_Starter am 29 Februar 2024, 14:02:45oder den Überschuß einspeisen (verkaufen).
Es soll ja aus welchem Grund auch immer eine Null Einspeisung werden.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

DS_Starter

Ja, ich weiß.
Wollte damit nur darstellen, dass es eigentlich unter Optmierungsgesichtspunkten nicht sinnvoll ist wie du auch schon ausgeführt hast.
Und da ich auch eine Victron Anlage habe kann ich meine Erfahrung teilen wenn gewünscht.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Prof. Dr. Peter Henning

ZitatGenerell brauchst Du natürlich noch eine gute Prognose für die zu erwartende Leistung, zumindest auf Stundenbasis.
Obwohl ich Eure Arbeit an dem ForeCast-Modul sehr zu schätzen weiß, möchte ich dieses Statement doch etwas in Zweifel ziehen. Auch die besten Wettervorhersagen sind nicht stundengenau - sie tun nur so. Ferner sind kurzzeitige Himmelsbedeckungen durch Wolken ein wesentlicher Faktor, der nicht durch die Vorhersage geliefert wird.

Nun ist Wettbewerb fast immer eine gute Sache. Ich werde also (allerdings muss ich dafür erst meine zweite Anlage auf dem Dach haben) eine KI bauen, die auf die lokalen Bedingungen hin optimiert ist und keine große Datenbank mit historischen Werten benötigt.

Let's race.

LG

pah


ch.eick

Zitat von: Prof. Dr. Peter Henning am 25 März 2024, 17:54:45
ZitatGenerell brauchst Du natürlich noch eine gute Prognose für die zu erwartende Leistung, zumindest auf Stundenbasis.
Obwohl ich Eure Arbeit an dem ForeCast-Modul sehr zu schätzen weiß, möchte ich dieses Statement doch etwas in Zweifel ziehen. Auch die besten Wettervorhersagen sind nicht stundengenau - sie tun nur so. Ferner sind kurzzeitige Himmelsbedeckungen durch Wolken ein wesentlicher Faktor, der nicht durch die Vorhersage geliefert wird.

Nun ist Wettbewerb fast immer eine gute Sache. Ich werde also (allerdings muss ich dafür erst meine zweite Anlage auf dem Dach haben) eine KI bauen, die auf die lokalen Bedingungen hin optimiert ist und keine große Datenbank mit historischen Werten benötigt.
Es kann ja nie schaden, wenn ein wissender mit einsteigt.
Meine Prognose braucht nur so genau zu sein, dass die Schwellwerte passen. Es kommt mir nicht darauf an, wieviel da wirklich kommen wird :-)

In Bezug auf die Nulleinspeisung sollten die Stunden "Schätzwerte" nur dazu dienen, dass man abschätzen kann, ob noch ein Verbraucher aktiviert werden könnt, da ja eventuell bereits runter geregelt wird und man nicht den aktuellen Max Wert auslesen kann.
Beim Kostal Plenticore wird jedoch ein Prozentwert bei der Abregelung durch den KSEM (Smartmeter) eingetragen. Damit könnte man dann eventuell doch auf einen Maximalwert zurück rechnen, aber das bezieht sich sicherlich auf die Maximalleistung des WRs. Somit weiß man noch immer nicht, ob noch 10, 15 oder 20 % mehr möglich wären.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Prof. Dr. Peter Henning

#7
Schon beim Einbau meiner ersten PV-Anlage im Jahr 2007 habe ich mir Gedanken gemacht, was da so kommen könnte. Und damals eine mathematisch recht aufwändige Simulation des Sonnenlaufes gemacht. Wenn man die Ausrichtung seiner Anlage genau kennt, und eben den Sonnenlauf, lässt sich daraus eine sehr genaue Prognose für die an einem beliebigen Tag und zu einer beliebigen Stunde zu erwartende Maximalleistung erstellen, dafür braucht es eben keine KI.

Übrigens ist aus den damaligen Rechnungen später das FHEM-Modul Astro geworden.

Die tatsächlich zu erwartende Leistung wiederum ergibt sich aus den lokalen und aktuellen Wetterbedingungen - und da könnte tatsächlich ein lernendes System helfen. Wir werden sehen, welcher Ansatz letztlich besser ist.

LG

pah

P.S.: Ich denke, ich werde in den nächsten Tagen vielleicht mal dazu kommen, eine kleine Routine zu veröffentlichen, die mit Hilfe des Astro Moduls und den bekannten Daten der eigenen PV-Anlage genau diesen maximalen yield zurückgibt.

ch.eick

Zitat von: Prof. Dr. Peter Henning am 26 März 2024, 09:04:12Schon beim Einbau meiner ersten PV-Anlage im Jahr 2007 habe ich mir Gedanken gemacht, was da so kommen könnte. Und damals eine mathematisch recht aufwändige Simulation des Sonnenlaufes gemacht. Wenn man die Ausrichtung seiner Anlage genau kennt, und eben den Sonnenlauf, lässt sich daraus eine sehr genaue Prognose für die an einem beliebigen Tag und zu einer beliebigen Stunde zu erwartende Maximalleistung erstellen, dafür braucht es eben keine KI.

Übrigens ist aus den damaligen Rechnungen später das FHEM-Modul Astro geworden.

Die tatsächlich zu erwartende Leistung wiederum ergibt sich aus den lokalen und aktuellen Wetterbedingungen - und da könnte tatsächlich ein lernendes System helfen. Wir werden sehen, welcher Ansatz letztlich besser ist.

LG

pah

P.S.: Ich denke, ich werde in den nächsten Tagen vielleicht mal dazu kommen, eine kleine Routine zu veröffentlichen, die mit Hilfe des Astro Moduls und den bekannten Daten der eigenen PV-Anlage genau diesen maximalen yield zurückgibt.
Hallo pah,
genau die Daten des Astro und des DWD Moduls gehen bei mir in die KI Prognose rein und werden mit dem tatsächlichen Ertrag der Anlage in Verbindung gestellt. Dafür filter ich aus der Datenbank vorher noch einwenig die Vergleichdaten zum passenden Zeitraum.
Da die KI manchmal etwas euphorisch ist kappe ich noch mit einem berechneten, tatsächlichen Maximum.

Vorher hatte ich die Prognose über viele technische Werte der Anlage mit Ausrichtung, Neigung und Modulleistung, aber das war nur komplizierter zu konfigurieren und auch nicht besser im Ergebnis.

Das maßgebliche sind die Daten des DWD und damit steht oder fällt das Ergebnis.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

erwin

Hi PAH & Christian,
ich hab vor einiger Zeit auch eine kleine Routine geschrieben, die aus dem Sonnenstand (El/Az aus dem Astro-Modul) und der Ausrichtung des Solarpanels die theoretsch mögliche Strahlungsleistung errechnet.
..Auf Basis Vevtorrechnung El/Az - Normale auf Panel, skaliert mit dem LeistungsFaktor des Panels.
Die Grafik verdeutlicht die "theoretische Einstrahlung" mit dem realen Ertrag (von Gestern).
Du darfst diesen Dateianhang nicht ansehen.
Die Kurve passt grundsätzlich das ganze Jahr, empirisch angepasst ist die Kurve am Morgen und Abend wegen:
  • Abschattung
  • Das Problem der Vektorrechnung: Schnitt zw. Kugel und Ebene, - schneidet, abhängig von Ausrichtung Panel, eine Kalotte aus der Erdkugel - damit stimmt der "mathematische Sonnen-auf/unter-Gang" (der Vektorrechnung) nicht.
Die Einbrüche der blauen Kurve sind Wolken... daher ist WetterPrognose extrem wichtig - heute schaut es wesentlich schlimmer aus...
Bin gespannt auf den Vorschlag von PAH.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

ch.eick

Zitat von: erwin am 26 März 2024, 16:52:39< snip >
Die Einbrüche der blauen Kurve sind Wolken... daher ist WetterPrognose extrem wichtig - heute schaut es wesentlich schlimmer aus...
Bin gespannt auf den Vorschlag von PAH.
l.g. erwin
Hallo Erwin,
das mit der Wetterprognose hatte ich im Kostal Plenticore Thread bereits verwendet, es waren mir jedoch einfach zuviele technische und Wetter Faktoren. Jetzt mit der PV_KI_Prognose.py braucht man von der Anlage nur noch den tatsächlichen Yield der jeweiligen Stunden und die KI ist sogar näher an der Realität, als es bei meiner vorherigen Berechnung gewesen ist. Bei meiner Implementierung wird jedoch eine DbLog mit MySQL voraus gesetzt, um die historischen Daten zu haben, die für das Training der KI benötigt werden.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Prof. Dr. Peter Henning

#11
Sehr schöne Sache von Erwin.

Empirische Anpassung abends und morgens: Akzeptiert. Das ist auch deshalb nötig, weil die reine Sonnenstandsrechnung die Globalstrahlung vernachlässigt. Mit anderen Worten: Gerade abends und morgens kommt sehr viel mehr Ertrag von der PV-Anlage, als nach dem reinen Sonnenstand zu erwarten. Ich habe dafür extra einen Globalstrahlungssensor.

Das mit der Kalotte ist überflüssig, weil man im Astro-Device einen Horizontwinkel angeben kann. Und dann eben abschneiden muss, wenn die Sonne wirklich unter diesen Horizont geht.

Und, na ja: den gesamten Ertrag kann man vielleicht aus der Wettervorhersage in etwa ableiten - aber eben nicht, ob um 16:00 viel von der Anlage kommt, oder nicht.

LG

pah


ch.eick

Moin,
ich habe mal die Statistik der KI aktiviert, da sieht man nach welcher Gewichtung die Variablen verwendet werden.
PV_KI_Prognose  running - connected to 192.168.178.40
PV_KI_Prognose  running - dwdfull read from DbLog 192.168.178.40
PV_KI_Prognose  running - RandomForestRegressor loading
PV_KI_Prognose  running - RandomForestRegressor loaded
PV_KI_Prognose  running - RandomForestRegressor trained
PV_KI_Prognose  running - RandomForestRegressor fitted with yield
PV_KI_Prognose  running - RandomForestRegressor read statistics
Variable: Rad1h                Importance: 0.59
Variable: SunAlt               Importance: 0.23
Variable: SunAz                Importance: 0.05
Variable: SunD1                Importance: 0.03
Variable: Neff                 Importance: 0.02
Variable: TTT                  Importance: 0.02
Variable: DD                   Importance: 0.02
Variable: VV                   Importance: 0.02
Variable: N                    Importance: 0.02
Variable: R101                 Importance: 0.01
Variable: RRS1c                Importance: 0.0
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick