Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

ch.eick

#1425
Zitat von: kjmEjfu am 03 Mai 2022, 13:50:58
Sagt mal, wie wird denn der Neff aus dem DWD Device eingerechnet?
Im Correction_Factor steht ja z.B. "cloudiness range: 5". Wird Neff dafür gerundet oder einfach die zweite Stelle abgeschnitten?
Also bedeutet die 5 einen Neff-Wert von 50-59 oder von 46-54?
Ich versuche herauszufinden, weshalb der Forecast, trotz Autokorrektur, teilweise so stark daneben liegt.
Das liegt momentan an dem stark wechselnden Wetter im Frühjahr.
Wolken und Regen sind keine wirklich wissenschaftlichen Größen und lassen sich somit nicht als verlässlicher Faktor einrechnen. Da stecken mehr Erfahrungswerte dahinter.
Heiko hat soweit ich weiß meine Formeln übernommen. Dabei habe ich eine "Heizungskurve" mit Basis und Steigung zugrunde gelegt.
Das sieht dann z.B. so aus, wobei $Solar_Cloud der Wert für die prozentuale Bewölkung ist.

$Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;

Wenn nun Deine Wetterstation weiter weg ist oder dort eine andere Wetterlage in Bezug auf Wind und Berge herrscht, dann wird das Glaskugel lesen immer schwieriger.
In meinem Forecast kann man die Werte für $cloudk_base und $cloudk individuell anpassen.

Generell empfehle ich zuerst mal ein Jahr ohne eine Autokorrektur zu arbeiten, damit man sich mit seiner eigenen Wetterlage anfreunden kann.
Bei mir habe ich z.B. die Autokorrektur wieder komplett abgeschaltet, und die Vorhersage liegt recht gut bei der Realität. 10% sollte auf jeden Fall akzeptabel sein.
Die Autokorrektur arbeitet erst nach all diesen Korrekturen.
In meiner Implementierung über die DbLog hatte sich der Korrekturalgorythmus dann auch noch etwas aufgeschaukelt ;-)

Wie gesagt, es ist Glaskugel Lesen und soll eigentlich nur ein Trigger für die Steuerung von Großverbrauchern sein.
Die meisten Anwender haben eh keine passenden Verbraucher, um z.B. mit 1 kW über mehrere Stunden as Mittagshoch nutzen zu können.

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

Hallo zusammen,

ich bitte mal um eure Meinung.

1.:
Zur Zeit begrenze ich den Maximalwert der möglichen Stunden-PV-Prognose auf den Wert des KW-Peak der installierten Module.
Mehr kann ja nicht erzeugt werden.
Nun bin ich der Meinung, dass zusätzlich auch die Summe der Wechselrichterleistung als Maximalwert berücksichtigt werden müsste.

Hintergrund: Es kann ja sein, dass mit zunehmenden Alter der Anlage PV-Platten ergänzt werden um Alterungsverluste auszugleichen. Dann würde rein rechnerisch eine höhere Leistung installiert sein als erreicht werden kann, da durch den/die Wr begrenzt.

Habe ich einen Denkfehler oder seht ihr das genauso. Das kommt vllt. (noch) nicht vor, aber liegt doch sicher im Rahmen des möglichen.

2:
Für Verbraucher gibt es den Schlüssel mintime um diesen Verbraucher nach Ablauf dieser Zeit vom Modul ausschalten zu lassen.
Mir schwebt die Erweiterung Schlüssels pcurr mit einer Schwellenwertangabe der aktuellen Leistungsaufnahme vor, um bei Unterschreiten dieser Leistung die Trennung vom Netz vorzunehmen.
Das bedeutet, ist diese  optionale Schwellenwertangabe  definiert, hätte sie Vorrang und würde der Consumer abschalten auch wenn mintime noch nicht abgelaufen wäre.

Gibt es Meinungen zu diesen zwei Punkten ?

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 13 Mai 2022, 22:02:22
1.:
Zur Zeit begrenze ich den Maximalwert der möglichen Stunden-PV-Prognose auf den Wert des KW-Peak der installierten Module.
Mehr kann ja nicht erzeugt werden.
Nun bin ich der Meinung, dass zusätzlich auch die Summe der Wechselrichterleistung als Maximalwert berücksichtigt werden müsste.

Hintergrund: Es kann ja sein, dass mit zunehmenden Alter der Anlage PV-Platten ergänzt werden um Alterungsverluste auszugleichen. Dann würde rein rechnerisch eine höhere Leistung installiert sein als erreicht werden kann, da durch den/die Wr begrenzt.

Habe ich einen Denkfehler oder seht ihr das genauso. Das kommt vllt. (noch) nicht vor, aber liegt doch sicher im Rahmen des möglichen.
Die abnahme der Modulleistung würde man doch eigentlich sehen können, indem der Abstand der Prognose zur Realen Leistung immer größer würde. Das passiert zwar sehr langsam, würde jedoch auch interessant sein.

Beim Nachrüsten von Modulen müsste man das ja eigentlich nachmelden. Wenn mehr Nennleistung installiert ist würde es bei schwächer werdenden Modulen nicht mehr zu einer 70% Abschaltung kommen.

Zitat
2:
Für Verbraucher gibt es den Schlüssel mintime um diesen Verbraucher nach Ablauf dieser Zeit vom Modul ausschalten zu lassen.
Mir schwebt die Erweiterung Schlüssels pcurr mit einer Schwellenwertangabe der aktuellen Leistungsaufnahme vor, um bei Unterschreiten dieser Leistung die Trennung vom Netz vorzunehmen.
Das bedeutet, ist diese  optionale Schwellenwertangabe  definiert, hätte sie Vorrang und würde der Consumer abschalten auch wenn mintime noch nicht abgelaufen wäre.
MinTime habe ich bei mir eingerichtet, damit der Verbraucher davor nicht abgeschaltet wird.
Dann gibt es noch den Schwellwert ab dem Eingeschaltet werden soll und zusätzlich noch einen Leistungswert, unter dem abgeschaltet wird.
Somit entsteht in meiner Implementierung impliziet auch eine Priorisierung.
Ein Abschalten innerhalb der MinTime sehr ich als gefährlich an. Als Beispiel wäre da eine Wärmepumpe, die sollte auf jeden Fall nicht unterbrochen werden, damit der Kompresser auf jeden Fall die MinTime durchlaufen. Bei mir habe ich auch noch ein Zeitfenster definiert und auch eine MaxTime pro Tag, was somit mehrere MinTimes beinhalten würde.

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

Ich habe eine Weiterentwicklung V.0.60.0 in mein contrib gelegt.

In den Consumer Attributen ist der neue optionale Schlüssel [swoncond=<Device>:<Reading>:<Regex>]
hinzugekommen:

swoncond    zusätzliche Bedingung die erfüllt sein muß um den Verbraucher einzuschalten (optional).
   Device - Device zur Lieferung der zusätzlichen Einschaltbedingung
   Reading - Reading zur Lieferung der zusätzlichen Einschaltbedingung
   Regex - regulärer Ausdruck der für die Einschaltbedingung erfüllt sein muß

Damit kann man das Einschalten eines Devices von einer weiteren externen Bedingung abhängig machen.

Hintergrund: Ich habe eine EcoFlow Box. Ich möchte die Box nur laden wenn die aktuelle Batterieladung unter einem Schwellenwert ist auch wenn eine Planung entsprechend der erwarteten PV Erzeugung vorliegt. Die Batterieladung will ich mit einem JSONMOD Device abfragen. Das nur als Beispiel für einen Usecase.

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

DS_Starter

Moin Christian,

danke für deine Einschätzung.

Zitat
Beim Nachrüsten von Modulen müsste man das ja eigentlich nachmelden. Wenn mehr Nennleistung installiert ist würde es bei schwächer werdenden Modulen nicht mehr zu einer 70% Abschaltung kommen.
Ja, mir geht es nur um die mathematischen Zusammenhänge. Letztendlich kann nicht mehr Energie erzeugt werden als der WR liefern kann und ist m.M. nach der wirklich begrenzende Faktor. Die 70% Regel wirkt ja auch auf den WR und nicht auf die "theoretisch" installierte Modulleistung.

Zitat
Ein Abschalten innerhalb der MinTime sehr ich als gefährlich an. Als Beispiel wäre da eine Wärmepumpe, die sollte auf jeden Fall nicht unterbrochen werden, damit der Kompresser auf jeden Fall die MinTime durchlaufen. Bei mir habe ich auch noch ein Zeitfenster definiert und auch eine MaxTime pro Tag, was somit mehrere MinTimes beinhalten würde.
Auch das ist soweit richtig. Deswegen ist der zusätzliche Parameter als optional vorzusehen. Der User hat natürlich eine Eigenverantwortung einen solchen Parameter zu setzen in Anhängigkeit seines Einsatzfalls.
Ich sehe einen möglichen use Case in der Abschaltung eines Gerätes wenn der Ladevorgang abgeschlossen ist, d.h. eine Leistungsaufnahme unter einen bestimmten Wert fällt.

LG
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 14 Mai 2022, 10:32:30
Moin Christian,

danke für deine Einschätzung.
Ja, mir geht es nur um die mathematischen Zusammenhänge. Letztendlich kann nicht mehr Energie erzeugt werden als der WR liefern kann und ist m.M. nach der wirklich begrenzende Faktor. Die 70% Regel wirkt ja auch auf den WR und nicht auf die "theoretisch" installierte Modulleistung.
Auch das ist soweit richtig. Deswegen ist der zusätzliche Parameter als optional vorzusehen. Der User hat natürlich eine Eigenverantwortung einen solchen Parameter zu setzen in Anhängigkeit seines Einsatzfalls.
Ich sehe einen möglichen use Case in der Abschaltung eines Gerätes wenn der Ladevorgang abgeschlossen ist, d.h. eine Leistungsaufnahme unter einen bestimmten Wert fällt.
Die Abschaltung sollte doch das Gerät selber machen???
In meinen "Device_PV" wird bei der Ansteuerung des Gerätes mit PV-Leistung auch der Status mit verfolgt und erkannt, wann es fertig ist. Danach bekommt das Gerät natürlich bei weiterem Überschuss auch wieder ein Angebot sich einzuschalten. Begrenzt wird das nur durch die MaxTime pro Tag.
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, sollte.  ;)
Es gibt aber Geräte die machen das nicht und verbleiben in einem eingeschalteten Zustand und unterbrechen nur den Ladevorgang. Es verbleibt dann eine Ruheaufnahme vom zb. 10 Watt. Das will ich damit unterbinden können.
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

#1432
Zitat von: DS_Starter am 14 Mai 2022, 11:23:28
Ja, sollte.  ;)
Es gibt aber Geräte die machen das nicht und verbleiben in einem eingeschalteten Zustand und unterbrechen nur den Ladevorgang. Es verbleibt dann eine Ruheaufnahme vom zb. 10 Watt. Das will ich damit unterbinden können.
Sowas erfasse ich z.B. mit einem Shelly und schalte dann ab. Das Thema ist Standby.
Sowas sollte direkt durch die Geräte Anschaltung an FHEM erledigt werden.
Beispiele:
- Waschmaschine
- Mähroboter
- Getränke Kühlschrank in der Nacht
- Brunnen Pumpe
- Wirl Pool
- Mediacenter im Wohnzimmer

Ich bilde das Geräte spezifisch in entsprechenden DOIFs ab, die auch Statistiken anzeigen und zusätzlich manuelles Steuern ermöglichen.
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

#1433
Genau. Nur macht es das Modul dann gleich mit indem es den pcurr Parameter auswertet und abschaltet.
Zusätzliche Logiken mit DOIFs und ähnlichen Dingen sind dann überflüssig. 😉 Wenn man es einstellen möchte ... wenn nicht, dann eigene Logik. Der User ist der Manager seines Systems.
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

der-Lolo

Es gibt ja auch überbelegung - nicht immer ist der Wechselrichter so groß wie die installierte PV Leistung ;)

dk3572

Zitat von: DS_Starter am 21 April 2022, 21:19:52
Ich schaue auch ob ich den Prozess der "on/off" Verwaltung noch etwas verbessern kann ohne die internen Abhängigkeiten zu zerstören.

Hallo Heiko,
da du hier wieder fleißig Neuerungen präsentierst, frage ich mal vorsichtig nach ob du in der zitierten Angelegenheit auch bereits etwas verbessern konntest.

Danke und schönes Wochenende.
VG Dieter

DS_Starter

Hallo Dieter,

habe ich nicht vergessen.
Was mir vorschwebt ist, dass ich den Status nach dem Einschalten zunächst in "swtching on" setze und beim nächsten update Zyklus prüfe ob der Verbraucher tatsächlich "on" ist. Dann erst setze ich den Status "on". Beim Ausschalten gilt entsprechendes.

Wenn ich das so umsetze, könnte ich im zweiten Schritt vermutlich die Auswertung von "on" / "off", auch wenn der Zustand nicht durch das Modul vorgenommen wurde, vornehmen und davon die weiteren Vorgänge verknüpfen.

Aber soweit bin ich noch nicht.

LG,
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

DS_Starter

In meinem contrib liegt nun die V 0.61.0.
Umgesetzt ist nun die optionale Angabe der max. WR-Leistung mit dem Schlüssel "capacity".

currentInverterDev <Inverter Device Name> pv=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit> [capacity=<max. WR-Leistung>]

Legt ein beliebiges Device und dessen Readings zur Lieferung der aktuellen PV Erzeugungswerte fest. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Werte mehrerer Inverterdevices führt man z.B. in einem Dummy Device zusammen und gibt dieses Device mit den entsprechenden Readings an.
Die Angabe von capacity ist optional, wird aber zur Optimierung der Vorhersagegenauigkeit dringend empfohlen.

    pv    Reading welches die aktuelle PV-Erzeugung liefert
    etotal    Reading welches die gesamte erzeugten Energie liefert (ein stetig aufsteigender Zähler)
    Einheit    die jeweilige Einheit (W,kW,Wh,kWh)
    capacity    Bemessungsleistung des Wechselrichters gemäß Datenblatt (max. möglicher Output in Watt)


    Beispiel:
    set <name> currentInverterDev STP5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000

    # Device STP5000 liefert PV-Werte. Die aktuell erzeugte Leistung im Reading "total_pac" (kW) und die tägliche Erzeugung im Reading "etotal" (kWh). Die max. Leistung des Wechselrichters beträgt 5000 Watt.

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

DS_Starter

Nun gibt es noch den Schlüssel swoffcond in den Consumer Attributen.

Der optionale Schlüssel swoffcond definiert eine vorrangige Ausschaltbedingung (Regex). Sobald diese Bedingung erfüllt ist, wird der Consumer ausgeschaltet auch wenn die geplante Endezeit (consumerXX_planned_stop) noch nicht erreicht ist (ODER-Verknüpfung). Weitere Bedingungen wie off-Schlüssel und auto-Mode müssen zum automatischen Ausschalten erfüllt sein.

swoffcond=<Device>:<Reading>:<Regex>

swoffcond    vorrangige Bedingung um den Verbraucher auszuschalten (optional).
   Device - Device zur Lieferung der vorrangigen Ausschaltbedingung
   Reading - Reading zur Lieferung der vorrangigen Ausschaltbedingung
   Regex - regulärer Ausdruck der für die Ausschaltbedingung erfüllt sein muß

LG
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

jual

Zitat von: DS_Starter am 13 Mai 2022, 22:02:22
Hallo zusammen,

ich bitte mal um eure Meinung.

2:
Für Verbraucher gibt es den Schlüssel mintime um diesen Verbraucher nach Ablauf dieser Zeit vom Modul ausschalten zu lassen.
Mir schwebt die Erweiterung Schlüssels pcurr mit einer Schwellenwertangabe der aktuellen Leistungsaufnahme vor, um bei Unterschreiten dieser Leistung die Trennung vom Netz vorzunehmen.
Das bedeutet, ist diese  optionale Schwellenwertangabe  definiert, hätte sie Vorrang und würde der Consumer abschalten auch wenn mintime noch nicht abgelaufen wäre.

Ich hätte mal ein paar grundsätzliche Anmerkungen/Ideen zu "pcurr".

Aus meiner Sicht würden sich pcurr_on und pcurr_off eignen, eventuell sogar in Verbindung mit einer pcurr_on_time und pcurr_off_time. Also im Prinzip dass, was man in SMA auch einstellen kann. Damit würde man dann im Prinzip eine automatische An- und Ausschalterkennung verfügbar machen und die Probleme, die ein paar Threads vorher erläutert wurden, gäbe es nicht. Bei SMA ist es dann so, dass man auch noch definieren kann, welchen Zustand das Gerät (die Steckdose) hat, nachdem das Programm durchgelaufen ist.

Also folgende Logik:
- Wenn pcurr_on für einen Zeitraum von pcurr_on_time erreicht oder überschritten wurde, dann ist das Gerät gestartet worden und man kann es in den Automatikmodus versetzen. Ab nun gilt die Einschaltlogik vom Modul
- Wenn pcurr_off für den Zeitraum pcurr_off_time unterschritten wurde, dann ist das Programm des Geräts beendet und der Automatikmodus kann ausgeschaltet und das Gerät in den gewünschten Zustand geschaltet werden

Bei programmgesteuerten Geräten müsste man zusätzlich evtl. noch die maximale Programmlaufzeit berücksichtigen, damit nicht zwischendurch einfach ausgeschaltet wird.