Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

DS_Starter

Zitat von: Christian83 am 01 Juni 2023, 10:04:46Sondern von der Grunddiskussion ob Batterieladung als Verbrauch zählt oder nicht.
In meinen Augen nicht, da Batterieladung (mit Verlusten) erst dann in den Hausverbrauch eingeht wenn die Bat entlädt, d.h. das Hausnetz speist. Die Zähler am Netzspeisepunkt bekommen das nicht mit.
Current_SelfConsumptionRate  größer 100% kommt bei mir nicht vor (habe uch eine Bat).

ZitatDie Frage ist, ob als "echter" PV-Überschuss nur die Einspeisung genommen werden sollte. Wenn nichts eingespeist wird, habe ich auch keinen Überschuss.
Das ist nicht von der Hand zu weisen ...
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

Christian83

Zitat von: DS_Starter am 01 Juni 2023, 10:08:33
Zitat von: Christian83 am 01 Juni 2023, 10:04:46Sondern von der Grunddiskussion ob Batterieladung als Verbrauch zählt oder nicht.
In meinen Augen nicht, da Batterieladung (mit Verlusten) erst dann in den Hausverbrauch eingeht wenn die Bat entlädt, d.h. das Hausnetz speist. Die Zähler am Netzspeisepunkt bekommen das nicht mit.
Current_SelfConsumptionRate  größer 100% kommt bei mir nicht vor (habe uch eine Bat).

Ja sehe ich grundlegend auch so.
Deshalb ist aber bei PV-Überschuss dann PV - Consumption das Problem, dass die Batterieladung fehlt.

Wenn ich heute Abend mehr als 100% sehe, dann schreibe ich das hier nochmal. (War vorhin bei meinem gezielten Entladen und Abkoppeln der Solarmodule)

DS_Starter

Ich sehe folgende Problematik ..
Meine PV/Batterie-Anlage steuert sich selbst insofern, dass der Batterie-WR (Lader) die für die Batterieladung verwendete Leistung dynamisch nach dem Überschuß (Feed-In) steuert.
D.h. je mehr der Modul-WR produziert, erhöht der Batterielader die Leistung um Feed-In klein zu halten.

Für das Modul wäre dann, wenn Feed-In = Surplus angenommen wird, kein Überschuß vorhanden, solange bis die Ladeleistung des Laders auf 100% gegangen ist. Alles darüber ist dann Feed-In und für das Modul wäre erst dann ein Überschuß vorhanden -> Switch Consumer.
D.h. bedeutet auch dass Surplus in Abhängigkeit einer Vorrangladung Batterie (oder nicht) berechnet werden müsste.
Es gibt da einiges zu beachten denke ich.

Wer keine Batterie hat, kommt nicht in diese Problematik.
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

Christian83

Zitat von: DS_Starter am 01 Juni 2023, 10:25:08Ich sehe folgende Problematik ..
Meine PV/Batterie-Anlage steuert sich selbst insofern, dass der Batterie-WR (Lader) die für die Batterieladung verwendete Leistung dynamisch nach dem Überschuß (Feed-In) steuert.
D.h. je mehr der Modul-WR produziert, erhöht der Batterielader die Leistung um Feed-In klein zu halten.

Für das Modul wäre dann, wenn Feed-In = Surplus angenommen wird, kein Überschuß vorhanden, solange bis die Ladeleistung des Laders auf 100% gegangen ist. Alles darüber ist dann Feed-In und für das Modul wäre erst dann ein Überschuß vorhanden -> Switch Consumer.
D.h. bedeutet auch dass Surplus in Abhängigkeit einer Vorrangladung Batterie (oder nicht) berechnet werden müsste.
Es gibt da einiges zu beachten denke ich.

Wer keine Batterie hat, kommt nicht in diese Problematik.

Okay. bei mir hängt die Batterie direkt am gleichen Gateway wie die Module. Deshalb ein zusammenhängendes System.

Ja ist etwas komplexer inkl. Batterie. Also was ist "echter" PV-Überschuss. Was ist PV-Überschuss inkl. Batterieladung. Und ja Vorrangladung und Ladestand der Batterie müsste wahrscheinlich genauso beachtet werden.
Aber so wie jetzt, hab ich das Problem, dass mein Consumer aktiviert wird, auch wenn die 2500 W eigentlich für die Batterieladung genutzt werden sollen. (Hast du dieses Problem nicht?)

DS_Starter

ZitatAber so wie jetzt, hab ich das Problem, dass mein Consumer aktiviert wird, auch wenn die 2500 W eigentlich für die Batterieladung genutzt werden sollen. (Hast du dieses Problem nicht?)
Naja, "Problem" würde ich nicht sagen. Ich sah (sehe) einen Direktverbrauch positiver weil verlustfrei gegenüber Batterieladung.
Aber ich erkenne die Problematik und werde etwas einbauen. Ob das noch vor meinem Urlaub wird kann ich jetzt noch nicht sagen.
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

Christian83

Zitat von: DS_Starter am 01 Juni 2023, 11:27:40
ZitatAber so wie jetzt, hab ich das Problem, dass mein Consumer aktiviert wird, auch wenn die 2500 W eigentlich für die Batterieladung genutzt werden sollen. (Hast du dieses Problem nicht?)
Naja, "Problem" würde ich nicht sagen. Ich sah (sehe) einen Direktverbrauch positiver weil verlustfrei gegenüber Batterieladung.
Aber ich erkenne die Problematik und werde etwas einbauen. Ob das noch vor meinem Urlaub wird kann ich jetzt noch nicht sagen.

Ja das mit Direktverbrauch ist natürlich auch nicht zu vernachlässigen.
Dann werde ich morgen mal mein Glück mit Batterieladungsstand testen, ob das Einfluss hat.

EDIT: Und keinen Stress. Schönen Urlaub dir.

SparcWolf

Moin Heiko,

Habe bei mir auch mal ein ForecastSolar Device definiert und bin gespannt auf die Ergebnisse  8) .
Bei der Einrichtung gab es keine Probleme. Es laufen jetzt alle drei Varianten bei mir parallel.

Im fhem.log tauchte folgende Meldung auf:
PERL WARNING: Use of uninitialized value $dnum in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 9424.
Viele Grüße und erholsamen Urlaub,
  Guido.

DS_Starter

Die Warnung habe ich gleich beseitigt -> V liegt im contrib.

Danke für eure Urlaubswünsche! ... 3 Tage noch  :D
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

stefanru

Das mit PV Erzeugung und Batterie ist interessant.

Ich hatte am Anfang auch Probleme da mein Wechselrichter als Reading ein PowerFlow_Inverters_1_E_Total hat und ich dachte das wäre der richtige Summen Wert für das Forecast Modul.
Bis ich gemerkt habe, dass dieses Reading auch Nachts hochzählt. Nämlich wenn der Inverter Strom aus der Batterie entnimmt.
Nun erzeuge ich mir selbst ein Reading mit integral aus PowerFlow_Site_P_PV was dann nur die Inverter Leistung aus PV ist.

Prinzipiell sehe ich direkt Verbrauch auch vor Baterieladung.
Ich habe mir eine Steuerung gebaut die die Batterie schonend lädt und die Ladeleistung nach Vorhersage reduziert in 4 Stufen und ab bestimmten Ladezuständen des Akkus.
Ein Seiteneffekt des ganzens ist das man früher Überschuss nach Abzug der Batterieladung hat.
Im Prinzip ist der Überschuss besser verteilt über den Tag.
Also anstatt morgends mit allem was man hat die Batterie zu füllen und dann ab 10 Uhr nur noch Überschuss zu haben verteilt sich die Füllung mehr über den Tag und man hat immer auch noch Überschuss für Verbraucher auch schon früh am morgen.

Das stimmt natürlich nur an Tagen wie jetzt an denen es genügend Sonne den ganzen Tag gibt.

Bei schlechtem Wetter oder im Winter bleibt dann die Frage, lieber Auto Laden oder Akku füllen.
Diese Entscheidung muss man wohl individuell treffen, aber mal abgesehen von Auto laden denke ich, dass Verbraucher Vorrang vor der Batterie haben sollten.
Man könnte natürlich noch überlegen den zusätzlichen Verbrauchern erst Vorfahrt zu geben ab einem gewissen Akku Ladestand, z.B. 50%.


Gruß,
Stefan




DS_Starter

ZitatIch habe mir eine Steuerung gebaut die die Batterie schonend lädt und die Ladeleistung nach Vorhersage reduziert in 4 Stufen und ab bestimmten Ladezuständen des Akkus.
Ein Seiteneffekt des ganzens ist das man früher Überschuss nach Abzug der Batterieladung hat.
...
So etwas habe ich auch gemacht -> Wiki
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

kask

Es kommt halt darauf an was man für eine Strategie fährt mit seinem System. Hat der Speicher Prio vor z.B. der Wärmepumpe oder dem Auto. um z.B. sicher durch die Nacht zukommen und die Grundlast abzudecken 24/7.
Wenn der Speicher Prio hat kann man den als Consumption einbeziehen damit der sicher voll wird und nicht der Consumer etwas wegnimmt. (WP, Auto, WM, SM,Trockner)
Denn so ein Speicher hat ja in der regel einen sehr großen wirkbereich in dem er betrieben wird/werden kann. 50-5000W z.B. Und dieser fängt ja schon bei 50W an weg zu ziehen bei PV Überschuss. So ist am Zähler bis 5000W+Grundlast erst einmal alles für den Speicher da.
Und dann hab ich Überschuss für andere Sachen.

Oder ist die Strategie eher das der Speicher alles bekommen soll bloß bevor es aus dem Zähler geht.
Dann Kann ich schalten und walten was ich will und der Speicher bekommt nur das was übrig bleibt.
Dann ist der Speicher unterlagert und man müsste den eigentlich nicht einbeziehen als Consumer in der Rechnung damit ich weiß was dieser von der Leistung bekommt und ein Consumer dann zugeschaltet werden kann.

Oder ein Mischbetrieb aus Geräten die Vorrang oder einen Teilvorang haben und dann dem Speicher auch danach prio geben vor anderen Sachen. Aber das ist zu komplex und muss sich jeder selbst zusammen basteln. Da kann man nix groß vorbereiten da jeder Haushalt anders funktioniert und andere Interressen hat.


kask

#2606
Ich zum Beispiel benutze das Modul hier um meine Speichermanagment zu machen.
Habe ich noch genug Sonne um den Speicher zu befüllen ist da eher zweitrangig. Mir geht es eher darum den Speicher langsamer zu laden.
Ist besser für den Speicher (erhoffe ich mir da zumindest) und effizienter wegen der verbauten Komponennten bei mir. Victron MP und Pylontech ähnliche Speicher (AC gekoppelt).

Áber eines verstehe ich auch nicht. Ich habe 3 Forcast Module aktiv. Alle haben unterschiedliche "currentRadiationDev" alle haben die selben Einstellungen (ausser die Farben) aber alle haben unterschiedliche "Tomorrow_ConsumptionForecast". Und die Stimmen bei allen nicht. Da bin ich mir sicher. Und alle bekommen die gleichen Daten!


DS_Starter

Zitat... aber alle haben unterschiedliche "Tomorrow_ConsumptionForecast". Und die Stimmen bei allen nicht. Da bin ich mir sicher. Und alle bekommen ie gleichen Daten!
Die Verbrauchsvorhersage ist abhängig von den Daten Vergangenheit. Sie kann nur versuchen aus diesen Daten einen wahrscheinlichen Verbrauch für den nächsten Tag abzuleiten.
Diese Daten können umfangreich oder weniger umfangreich, richtig oder verfälscht sein, je nach Laufzeit.
Darüber hinaus gibt es noch Einflußmöglichkeiten via Attr affectConsForecastIdentWeekdays auf die Kalkulation weil man eben keine Gleichverteilung über die Tage hat.

Welche Daten bereitstehen und verwendet werden können, sieht man mit "get ... pvHistory".
Relevant sind die Schlüssel:

confc    erwarteter Energieverbrauch (Wh)
con    realer Energieverbrauch (Wh) des Hauses

in der Stunde 99, d.h. der Tageszusammenfassung des jeweiligen Tages.
Wobei nur con für die zukünfige Abschätzung relevant ist. confc zeigt den erwarteten Wert aufgrund der Prognose am Vortag.

Für gestern hier ein Beispiel meines Systems:

      99 => etotal: , pvfc: 41122, pvrl: 36450
            confc: 14099, con: 12794, gcon: 1059, gfeedin: 25746
            batintotal: , batin: 4543, batouttotal: , batout: 5574
            wid: , wcc: , wrp: , pvcorrf: , dayname: Mi

Da kannst du bei dir mal schauen ob du große Differenzen feststellst. Wenn ja, gibt es noch dieses Schlüssel in den einzelnen Stunden und du erkennst dann vernutlich woher (wann) die Differenz reinkam und kannst evtl. Rückschlüsse ziehen welcher Verbraucher reinhaut (oder evtl. ein Fehler im Setup drin ist).
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

kask

Hmmm, da muss ich mal gucken was da nicht past.
Die Werte die ich in Echtzeit sehe, sehen plausibel aus.
Gestern bei dem SolcastApi Forecast Modul
      99 => etotal: , pvfc: 67174, pvrl: 64860
            confc: 53345, con: 64014, gcon: 247, gfeedin: 0
            batintotal: , batin: 6955, batouttotal: , batout: 5862
            wid: , wcc: , wrp: , pvcorrf: , dayname: Wed

Habe aber 42kW eingespeist (richtiger Wert des Zählers vom Messstellenbetreiber) bei um die 72kW PV-Erzeugung(Richtiger Wert von den Umrichtern) + 6kW Speicher entladen. Wie komme ich da z.B auf 64kW consumption? 72kW+6kW-42kW = 36kW. Und 36kW liegt im Rahmen des Möglichen.
Das müsste ich doch direkt an den Anzeigewerten in Fhem sehen. Aber wenn ich die Werte vergleiche mit meinen Messstellen dann sind die recht identisch. Auch wenn manches kalkuliert ist im oder für das Modul.

edit.: da ist ja garkein gfeedin. Mal suchen!

kask

Aber ich habe grid-feedin in der Anzeige. Auch scheinbar der Richtige.