Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

DS_Starter

#675
Hab jetzt den Screenshot gesucht ... haste vergessen denke ich  ;)

Zitat
aber könnte man nicht besser eine Zahl in Prozent für das Attribut vorsehen und das Attribut standardmäßig mit 70% vorbelegen?
Ja sicher, geht im Prinzip auch. Allerdings müßte es dann ein Freifeld sein damit der User etwas eintippen kann. Vorbelegen geht dann nicht wenn man nicht generell die 70% Regel anwenden will. Das wäre aus den genannten Grüden ungünstig. Ich habe aber noch vor einen Wert "dynamic" einzubauen der ähnlich wie der SHM arbeitet.

Ich vermute eher, dass es ein "Rundungsfehler" ist der sich der intervall-Zeit der Datenabfrage ergibt. Wenn man es ganz genau machen wollte, müßte man ganz exakt am Anfang und auch am Ende einer Stunde die Werte vom WR-Device abrufen. Aber das ist mit einem eingestellen Intervall so nicht möglich weil es z.B. 2 Minuten vor Ende der Stunde misst und dann wieder 1 Minute nach Beginn der neuen Stunde je nach Attribut Wert. Daraus ergibt sich immer eine gewisse kleine Abweichung des realen Wertes innerhalb der Stunde. Die Summe über den Tag passt dann wieder zu 100%.

Zitat
Dann ist mir noch aufgefallen, dass der ConsumptionForecast immer sehr unrealistisch daneben ist. Hast Du dazu ne Idee?
Um das herauszufinden musst du dir mal mit


get <> pvHistory


die vergangenen Werte anschauen. Wichtig ist hier die Zeile mit dem Key "99" jedes Tages:


99 => pvrl: 32827, pvfc: 30340, gcon: 6917, con: 13470, gfeedin: 25673, dayname: Mo


Innerhalb der Zeile ist es der Wert von "con". Vielleicht findest du einen exorbitant hohen Wert der hier reinhaut.
Ohne gesetztes Attr sameWeekdaysForConsfc wird jeder verfügbare Tag in der pvHistory aufaddiert und daraus der Durchschnitt gebildet (verbose 5 zeigt das).
Mit  sameWeekdaysForConsfc = 1 werden nur gleiche Tage (dayname) verwendet.

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

DS_Starter

Ich habe nun noch die dynamische 70% -Regel eingebaut und das Attr erweitert:

follow70percentRule
Wenn gesetzt, wird die prognostizierte Leistung entsprechend der 70% Regel begrenzt.

    0                  keine Begrenzung der prognostizierten PV-Erzeugung (default)
    1                  die prognostizierte PV-Erzeugung wird auf 70% der installierten Stringleistung begrenzt
    dynamic        die prognostizierte PV-Erzeugung wird begrenzt wenn 70% der installierten
                        Stringleistung zzgl. des prognostizierten Verbrauchs überschritten wird
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

Hallo zusammen,

ich denke ich habe nun einen Weg gefunden um Großverbraucher wie Trockner, Wallboxes usw. aus der Verbrauchsvorhersage zu eliminieren. D.h. der Energiekonsum durch Verbraucher die nicht zu durchschnittlich betriebenen Geräten im Haushalt gehören wird (zum großen Teil) geglättet.

Das war als Vorbereitung wichtig um eine Vorhersage für die Zeitplanung zur Zuschaltung von Großverbrauchern vornehmen zu können. Ohne diese Glättung würde die Vorhersage genau um dien Betrag der in der Vergangenheit zugeschalteter Großverbraucher "verfälscht", d.h. es würde u.U. ein sehr hoher Konsum prognostiziert, der aber nur dann eintreten würde wenn man zum Beispiel den Trockner oder Heizstab etc. anschalten würde.

Diese Zuschaltung soll aber nur dann passieren wenn eine genügend hohe Differenz des prognostizierten PV Ertrages und prognostizierten Verbrauchs vorliegt.

Wenn das jetzt so arbeitet wie von mir gewünscht ist der nächste Schritt in greifbarer Nähe, die modulgesteuerte Planung/Zuschaltung von Verbrauchern im Sinne einer dynamischen 70% Regelung. Das heißt Verbraucher würden zugeschaltet bevor  eine Abregelung des WR notwendig werden würde. Das klappt natürlich nur wenn die Begrenzung im WR nicht fest hinterlegt ist, z.B. wenn man einen SMA SHM hat.

Liegt im contrib.
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

Ich sehe schon, ich komme mit den Updates gar nicht mehr nach ;-).

Ich hatte da noch eine Idee zur Glättung des Verbrauchs, die ggf. zukünftig eingebaut werden könnte, aber das Modul natürlich auch immer komplexer macht.

Ich könnte mir vorstellen, dass viele den Verbrauch der Großverbraucher entsprechende FHEM-Devices integriert haben. Ich habe zum Beispiel für den Zweck aber auch für die automatisierte Ansteuerung die Geräte mit Fritz-Steckdosen versehen und andere Verbraucher teilweise über strommessende Steckdosen eingebunden.

Wenn man jetzt ähnlich der WR-Einbindung ein Attribut "Großverbraucher" vorsieht, in dem man den Devicenamen und das Reading für den Verbrauch angibt, könnte das Modul den echten Verbrauch direkt rausrechnen.

Also etwas wie "Spuelmaschine:power:W Waschmaschine:power:W"

DS_Starter

Da bin ich schon dabei es umzusetzen.  :)
Allerdings nicht beschränkt auf Großverbraucher.

Im Prinzip will ich Setter für Consumer01, Consumer02, Consumer03 ...  zur Verfügung stellen, für die dann die Schaltzeiten automatisch geplant werden können. Bin gerade dabei mir die nötigen Angaben zusammenzustellen.

Melde mich wieder wenn ich soweit bin.
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

Elektron

Hallo zusammen,

Ich habe auf eine der letzten Versionen aus dem Contrib upgedatet (bin aber nur einige wenige Tage zurück).
In dem Zusammenhang habe ich unsere Batteriespeicher (Tesla Powerwall2) eingebunden.
Ich sehe auch die beiden Readings Current_PowerBatIn/Current_PowerBatOut mit den entsprechenden Werten, aber in der Prognose sehe ich da keine Hervorhebung.

Muss ich da ein weitere Attribut setzten?
Oder kommen die erst wenn für jeden Tag eine Verbrauchshistorie existiert?

Vielen Dank und Grüße Michael

DS_Starter

Hallo Michael,

setzen musst du nichts mehr. Ist soweit ok.
Die Battriewerte werden im Ergebnis des Readings Current_Consumption berücksichtigt.

Für eine Vorhersage der konsumierten Energie (Wh, kWh) bräuchte ich im Setter  currentBatteryDev  weitere Angaben der totalen eingespeisten oder abgegebenen Energie der Batterie.

Wären diese Daten in dem (deinem) Quellendevice als Readings verfügbar ?

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

Elektron

Hallo Heiko,

Wenn Du damit einen Zähler meinst der die Importierte und Exportierte Energie zählt (seit Anbeginn der Zeit), dann müsste ich bei der Powerwall2 was entsprechendes haben.
Die beiden Readings heißen
aggregates-battery-energy_imported
aggregates-battery-energy_exported.

Viele Grüße Michael

DS_Starter

Ja genau sowas meinte ich.
Das leg ich mir auf die ToDo. Bin grad mit den Verbrauchern beschäftigt.

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

Elektron

Hallo Heiko,

Super, vielen Dank für die schnelle Antwort.
Dann beobachte ich das Thema mal fleißig, damit ich nicht verpasse wenn es im Contrib was neues gibt.

Hast Du mal darüber nachgedacht, dass Modul ins SVN zu verschieben?

Viele Grüße Michael

DS_Starter

Moin Michael,

ZitatHast Du mal darüber nachgedacht, dass Modul ins SVN zu verschieben?
Ja, will ich machen. Es ist aber noch zu früh weil es noch zu häufig Änderungen und Weiterentwicklungen gibt. Ist das Modul erstmal im SVN regulär eingecheckt, ist der Prozess für mich viel aufwändiger. Denke z.B. an eine ständige Dokumentation auch in englisch jeglicher Änderungen usw.

Kommt also zu gegebener Zeit.

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

ch.eick

Zitat von: Elektron am 30 April 2021, 16:23:54
Wenn Du damit einen Zähler meinst der die Importierte und Exportierte Energie zählt (seit Anbeginn der Zeit), dann müsste ich bei der Powerwall2 was entsprechendes haben.
Die beiden Readings heißen
aggregates-battery-energy_imported
aggregates-battery-energy_exported.
Moin,
für den Kostal Plenticore, mit DC angeschlossenem Speicher gibt es ab v1.16 folgendes. Das habe ich jedoch noch nicht überprüft und erscheint mir etwas merkwürdig.

Battery_Maximum_ChargePLimit_read-outFromBattery 7896.00
Battery_Maximum_DischargePLimit_read-outFromBattery 18579.02


Liest man den BYD HV Speicher direkt aus kommt jedoch etwas anderes. Diese Werte haben sich jedoch ein Jahr vorher bereits aufgebaut und sind DC.
Der gesamt Wirkungsgrad, unter Berücksichtigung des aktuellen Soc von 61 % , wäre damit sehr gut und liegt bei 89 % .

Statistic_GeneralInformation_Total_Charge_Energy 2385.667
Statistic_GeneralInformation_Total_Discharge_Energy 2116.172


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

ch.eick

Zitat von: DS_Starter am 01 Mai 2021, 08:43:59
Denke z.B. an eine ständige Dokumentation auch in englisch jeglicher Änderungen usw.
Gibt es denn irgend etwas zur Beschreibung der Funktionalität, weil ich nicht jeden Erweiterung mitgemacht habe fehlt mir da etwas der Überblick.

Gruß
   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

Moin Christian,

naja, gibt ständig etwas Neues.
Nach dem Laden des Moduls einfach

help Solarforecast de

aufrufen.

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

Elektron

Hallo Christian,

Da hast Du wahrscheinlich die Energie die in den / aus dem Speicher geladen wurde mit der maximalen Lade-/Entladeleistung verwechselt...

Also wie Leistung der Pv kann in die Batterie geladen werden bzw. Wieviel Leistung kann aus der Batterie entnommen werden (beides gemessen in Watt) vs. Wie viel wurde tatsächlich an Energie gespeichert (beides gemessen in Wattstunden)

Zitat von: ch.eick am 01 Mai 2021, 08:54:58
Battery_Maximum_ChargePLimit_read-outFromBattery 7896.00
Battery_Maximum_DischargePLimit_read-outFromBattery 18579.02

Viele Grüße Michael