Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

kaizo

Hallo DS_Starter

dein Modul solarforecast läuft super und hilft mir, meine PV-Anlage zu optimieren. Danke dafür.
Seit einiger Zeit habe im Log folgende Meldung:

[Fri Jun 24 17:00:02 2022] fhem.pl: "my" variable $date masks earlier declaration in same scope at (eval 60782) line 9.
[Fri Jun 24 18:00:04 2022] fhem.pl: "my" variable $date masks earlier declaration in same scope at (eval 65263) line 9.

Da das Modul die Forecasts stündlich aktualisiert und ich nichts wesentliches (wie immer) geändert habe liegt aktuell meine Vermutung in dem Solarforecast-Modul.
Kann das sein?


Gruß
Kai
FHEM 6.x  auf i3
1x Maplecun FS20, HM, 1x CUL f. WMbus
1x Arduino Nano für Lacrosse, 1x für Empfang WH1080,
1x Arduino Uno+Ethernet-Shield & Firmata für 1Wire
1x Raspberry Pi für Einbindung Junkers-Heizgerät mit HT3-Schnittstelle, div. Sonoff+EspEasy+Tasmota über MQTT

DS_Starter

Hallo Kai,

Ich vermute eine andere Stelle. Setz dir mal das globale Attr stacktrace.
Dann sieht nan sicherlich mehr.

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

#1472
Ich habe im Modul einen weiteren optionalen Consumer-Key "interruptable" hinzugefügt:

Zitat..
Mit dem optionalen Schlüssel interruptable kann während der geplanten Einschaltzeit eine automatische Unterbrechung sowie Wiedereinschaltung des Verbrauchers vorgenommen werden. Unterschreitet der PV Überschuß die benötigte Energie, wird der Verbraucher ausgeschaltet (interrupted) und eingeschaltet wenn wieder ausreichend PV Überschuß vorhanden ist (continued). Die verbleibende Laufzeit wird durch einen Interrupt nicht beeinflusst !
....
interruptable    Verbraucher darf (optional) unterbrechbar (1) oder nicht unterbrechbar (0) sein (default: 0)
...

Damit kann man nun zum Beispiel einen Heizstab für 8 Stunden (mintime) einplanen lassen. Wird dann während der Laufzeit der notwendige PV-Überschuß abhängig von der angegebenen Leistungsaufnahme (power) unterschritten, wird der Consumer temporär ausgeschaltet (interrupted).
Steigt der Überschuß wieder, weil sich die Wolken verzogen haben oder andere Verbraucher ausgeschaltet wurden, wird der Consumer wieder eingeschaltet (continued).
Achtung ... nicht gemeinsam mit dem mode=must verwenden, da sich die use cases widersprechen würden.

Liegt als V 0.65.0 im contrib.

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

Wie das manchmal so ist, habe ich einen kleinen Fehler bei der Implementierung von  interruptable festgestellt und eben korrigiert.
Gleichzeitig habe ich noch hinzugefügt, dass interruptable bei mode=must keine Wirkung hat und der User an der Stelle nicht auf die Nase fällt.
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 die Einplanungslogik für Consumer etwas optimiert sowie einen unauffälligen Bug beseitigt.
Liegt wieder 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

DS_Starter

Es hat sich als ungünstig herausgestellt wenn Consumer mit mode=must nicht interruptable sind wie ich es bisher implementiert hatte.
Das habe ich nun geändert. Dadurch werden Consumer mit mode=must auch dann eingeplant wenn nicht genügend PV Überschuß vorhergesagt ist. Wenn man ihn mit interuptable=1 kombiniert, kann man erreichen dass dieser Verbraucher nur dann aktiviert wird wenn z.B. durch Ausshalten anderer Verbraucher doch genügend Überschuß vorhanden ist.
So etwas kann zum Beispiel für zusätzliche Heizstäbe in Heizungspuffern oder Switches für elektr. Infrarotheizkörper sinnvoll sein.

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 den Consumer Key "interruptable" erweitert:

interruptable    definiert die möglichen Unterbrechungsoptionen für den Verbraucher (optional)
   0 - Verbraucher wird nicht temporär unterbrochen falls der PV Überschuß die benötigte Energie unterschreitet (default)
   1 - Verbraucher darf temporär unterbrochen werden falls der PV Überschuß die benötigte Energie unterschreitet
   Device:Reading:Regex - Verbraucher wird temporär unterbrochen wenn der Wert des angegebenen Device/Readings auf den Regex matched
   Matched der Wert nicht mehr, wird der unterbrochene Verbraucher wieder eingeschaltet.

Das heißt man kann nun nicht nur auf wechselnde PV Überschüsse reagieren (mit interruptable=1) sondern auch eine externe Bedingung angeben, z.B. ein Reading eines Wandthermostats um eine elektrische Heizung zu steuern.
Zur Zeit kann man mit interruptable entweder auf Schwankungen des PV Überschuß reagieren oder eine externe Bedingung. Ich denke noch darüber nach beides zu automatisch zu verknüpfen.
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

Zitat
Zur Zeit kann man mit interruptable entweder auf Schwankungen des PV Überschuß reagieren oder eine externe Bedingung. Ich denke noch darüber nach beides zu automatisch zu verknüpfen.
Mit der gerade in mein contrib hochgeladenen Version werden nun beide Bedingungen verknüpft:

interruptable    definiert die möglichen Unterbrechungsoptionen für den Verbraucher (optional)
   ...
   Device:Reading:Regex - Verbraucher wird temporär unterbrochen wenn der Wert des angegebenen Device/Readings auf den Regex matched
   oder unzureichender PV Überschuß vorliegt.
   Matched der Wert nicht mehr, wird der unterbrochene Verbraucher wieder eingeschaltet sofern ausreichender PV Überschuß vorliegt.
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

Noch ein kleiner Tipp.
Die Consumer  Steuerung ist inzwischen schon recht komplex geworden. Falls man sich näher damit beschäftigen möchte ohne gleich die Verbraucher im Haus produktiv in Solarforecast einzubinden, bietet sich ein Dummy an um verschiedene Situationen zu simulieren.

Ich verwende einen Dummy zum Test der so definiert ist:


define testdummy dummy
attr testdummy readingList BatIn BatOut BatVal  BatInTot BatOutTot bezW einW Batcharge actpow Temp
attr testdummy room Energie,Testraum
attr testdummy setList BatIn BatOut BatVal BatInTot BatOutTot bezW einW Batcharge on off actpow Temp
attr testdummy userReadings actpow {ReadingsVal ($name, 'state', 'off') eq 'on' ? 100 : 0}


Im SolarForecast Consumer Attribut kann man ihn zum Beispiel so einbinden und das Verhalten testen:


attr SolCast consumer03 testdummy icon=sani_buffer_electric_heater_side type=heater mode=must power=100 notbefore=7 notafter=18 auto=automatic pcurr=actpow:W on=on off=off mintime=5
interruptable=testdummy:Temp:([2]).*


Natürlich sind der Phantasie kaum Grenzen gesetzt.

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

Hat jemand von euch eine Temperaturmessung an den Zellen installiert ?

Hintergrund meiner Frage ist, dass die Zellen einen Temperaturkoeefizienten haben:

Zitat
Der Temperaturkoeffizient liegt bei kristallinen Photovoltaikmodulen bei circa -0,4 Prozent pro einem Grad Celsius. Die Nominalleistung der Module wird bei 25 Grad Umgebungstemperatur und bei 1.000 Watt Sonneneinstrahlung gemessen. Steigt die Temperatur um 1 Grad Celsius sinkt die Modulleistung um 0,4 Prozent. Photovoltaikmodule können im Sommer schon mal bis zu 70 Grad Celsius heiß werden, also ein Temperaturunterschied von 45 Grad gegenüber Nominaltemperatur. Das würde für eine 10 kWp Photovoltaikanlage folgenden Leistungsverlust bedeuten: Leistungsverlust = -0,4%/K * 45K *10 kWp = 1,8 kWp.

(aus: https://www.enerix.de/photovoltaiklexikon/temperaturkoeffizient/ )

Die Umgebungstemperatur ist zumindest im Sommer bei Südlage wenig aussagefähig weil die Zellentemperaturen sehr von der Umgebungstemperatur abweichen können und die Vorhersageleistung entsprechend beeinflusst.
Wenn jemand solche Meßeinrichtungen installiert hat, würde es Sinn machen ein "currentTempDev" einzubauen um den Temperatureinfluß besser abbilden zu 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

#1480
Zitat von: DS_Starter am 19 Juli 2022, 16:22:17
Hat jemand von euch eine Temperaturmessung an den Zellen installiert ?

Hintergrund meiner Frage ist, dass die Zellen einen Temperaturkoeefizienten haben:

(aus: https://www.enerix.de/photovoltaiklexikon/temperaturkoeffizient/ )

Die Umgebungstemperatur ist zumindest im Sommer bei Südlage wenig aussagefähig weil die Zellentemperaturen sehr von der Umgebungstemperatur abweichen können und die Vorhersageleistung entsprechend beeinflusst.
Wenn jemand solche Meßeinrichtungen installiert hat, würde es Sinn machen ein "currentTempDev" einzubauen um den Temperatureinfluß besser abbilden zu können.
Ich habe es ja empirisch mit rein genommen, indem ich die Vorhersagetemperatur pauschal erhöht habe und das ganze dann über eine "Heizungskurve" hoch rechne.

forecast_tempk 39
forecast_tempk_base 25

tempk_base wäre die Parrallelverschiebung und tempk die Steilheit der Heizungskurve.

Mit diesen Werten hätte es heute gepasst :-)

forecast_tempk 60
forecast_tempk_base 0

Die Prognose vom DWD für TTT lag heute recht gut bei den tatsächlichen Werten.

Meine Prognose lag heute um 4,5 kWp zu hoch, was dann warscheinlich an meiner zu niedrig eingestellten Temperaturkorrektur liegen wird.
Die Kunst ist nun einen Faktor für die Korrektur mit entsprechender Steilheit zu generieren.

An der Steuerung der Geräte hat das bei mir keinen Effekt gehabt, da sich alles am Mittagshoch orientiert hat.
Die Prognose für morgen ist schon wieder niedriger als heute, mal schauen, wie es dann wieder passt.

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

ja ich weiß mit diversen Annäherungen kann man natürlich arbeiten.
Ich bin auf einen konkreten Ansatz gekommen, weil ich kürzlich meine alte Solarthermie Anlage über eBus ins FHEM eingebunden habe. Diese wird durch einen TEM Regler gesteuert. Dieser Regler hat einen Eingang für einen auf dem Dach an der Anlage installierten Strahlungstemperaturfühler.
Das ist genau was man eigentlich auch bräuchte um eine möglichst genaue Temperatur der Solarzellen zu messen.

Deshalb wollte ich gern wissen ob denn vielleicht einige User solche Meßfühler betreiben. Dann würde es sich lohnen ein Temperaturdevice als Setupmöglichkeit vorzusehen. Ich selbst habe es auch nicht.

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

MadMax

Ich könnte relativ leicht einen sensor an meine Module bekommen.
Soll ich dir dann Werte zur Verfügung stellen?
Lenovo M910Q Tiny Debian 12, FHEM 6.3, 2x Siemens Logo 0BA7, Homematic CCU3, Philips HUE, 5x SMA Wechselrichter, BYD HVM, SMA EVCharger, Daikin Wärmepumpe über CAN

Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/MadMax

DS_Starter

Ja gerne. Welcher Art Sensor verwendest du, eingebunden in FHEM oder separat ?
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

MadMax

#1484
Ich Bin da offen, kann ein pt100 über eine LOGO oder ein DS18B20 über einen esp nehmen.
Ich habe allerdings fullBlack module die werden schneller warm.
Lenovo M910Q Tiny Debian 12, FHEM 6.3, 2x Siemens Logo 0BA7, Homematic CCU3, Philips HUE, 5x SMA Wechselrichter, BYD HVM, SMA EVCharger, Daikin Wärmepumpe über CAN

Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/MadMax