Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

grappa24

Zitat von: DS_Starter am 15 November 2023, 19:13:36Welchen Style verwendest du
ich verwende "dark", hab aber mal andere probiert, da fehlt das eine drop down auch  :'(
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

Habs ...

ConsumerImmediatePlanning -> consumerImmediatePlanning  :)
Proxmox+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

Die neue Version mit den Features ist eingecheckt und morgen früh per Update verfügbar.
Proxmox+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

tomcat.x

Erst mal sorry, dass meine Reaktionszeiten nicht so gut sind wie Deine ;-)

Zitat von: DS_Starter am 15 November 2023, 17:56:06Der Grund liegt bei näherem Hinsehen wahrscheinlich in den sehr kleinen Stundendifferenzen von unter einer 1Wh, z.B. 308.31 - 308.222 = 0,088 Wh. Das ist sehr wenig und geht durch die interne Rundung auf volle Wh unter. Sind so kleine Stundenerzeugungen bei dir in Ordnung?

Bis jetzt habe ich nur ein kleines "Balkonkraftwerk", aber mehr kommt da schon raus. Die Werte oben sind kWh, ich hatte aber Wh bei etotal eingetragen. Der Wert im MQTT Device sah plausibel aus, Punkt oder Komma ist doch nicht so wichtig. Aber es ist eben ein Punkt (also Dezimalpunkt) und daher kWh. Bei dem von Dir angegebenen Wert "308.31" fällt es natürlich sofort auf, aber im Inverter-Device werden immer 3 Nachkommastellen angezeigt.

Der Wert (oder die stündliche Differenz) wird in der grafischen Anzeige des SolarForecast-Geräts nicht direkt angezeigt. Die fehlenden Balken habe ich auf den Konfigurationsfehler geschoben. Stimmt ja letztendlich auch, nur anders als ich dachte.
 
Das habe ich jetzt umgestellt und die bisher gesammelten Werte gelöscht. Jetzt bekomme ich schon mal angezeigt, dass die Autokorrektur in 2 Stunden beginnt. Der Rest wird auch funktionieren.

Danke!
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

cwagner

Gratulation für dieses Modul, dass inzwischen "SuperPower" hat! Und natürlich hat der "Neue" auch schon gleich eine Idee: In Analogie zu powertrigger stelle ich mir ein batterytrigger vor, der beim Überschreiten einer oberen Schwelle auf ON geht und beim Unterschreiten einer unteren Schwelle auf OFF. Idee: Innerhalb eines Batteriefüllgrades von sagen wir 20-80% sollen angeschlossene Stromsauger wie z.B. ein E-Auto eingeschaltet werden, um wieder Platz zu schaffen für weitere Einlagerung von Strom. Zusammen mit den Prognosen der künftigen Erzeugung im Modul könnte man dann die Strategie fahren: Wenn noch viel reinkommen tut, schaffen wir Platz in der Batterie durch gezielten Verbrauch (Consumer wie Wärmepumpe etc.) oder Umlagerung in andere Batterien (z.B. Auto).
Was hältst Du von dieser Idee bzw. habe ich übersehen, weil das heute schon möglich ist?

Herzliche Grüße


Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

DS_Starter

Hallo Christian,

ZitatWas hältst Du von dieser Idee bzw. habe ich übersehen, weil das heute schon möglich ist?
Das finde ich eine gute Idee von dir.
Man kann zwar auch jetzt schon mit etwas Code im Attr ctrlUserExitFn soetwas ereichen, aber natürlich ist eine "codeless" Möglichkeit per batterytrigger hilfreich, um darüber mit Hilfe von notify etc. eigene Logiken umzusetzen.
Ich bin gerade an einem Update dran. Wenn das eingecheckt ist, nehme ich mir deine Anregung mal vor.

Grüße,
Heiko
Proxmox+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: cwagner am 22 November 2023, 12:13:10Gratulation für dieses Modul, dass inzwischen "SuperPower" hat! Und natürlich hat der "Neue" auch schon gleich eine Idee: In Analogie zu powertrigger stelle ich mir ein batterytrigger vor, der beim Überschreiten einer oberen Schwelle auf ON geht und beim Unterschreiten einer unteren Schwelle auf OFF. Idee: Innerhalb eines Batteriefüllgrades von sagen wir 20-80% sollen angeschlossene Stromsauger wie z.B. ein E-Auto eingeschaltet werden, um wieder Platz zu schaffen für weitere Einlagerung von Strom. Zusammen mit den Prognosen der künftigen Erzeugung im Modul könnte man dann die Strategie fahren: Wenn noch viel reinkommen tut, schaffen wir Platz in der Batterie durch gezielten Verbrauch (Consumer wie Wärmepumpe etc.) oder Umlagerung in andere Batterien (z.B. Auto).
Was hältst Du von dieser Idee bzw. habe ich übersehen, weil das heute schon möglich ist?
Hallo Christian,
es ist nicht so rentabel aus dem Hausspeicher das E-Auto zu laden, um dann wieder den Hausspeicher zu füllen.
Am besten achtest Du darauf lieber immer Sofortverbrauch zu haben, das spart den Umweg.
In meiner Implementierung sperre ich sogar den Speicher gegen entladen, wenn das E-Auto geladen wird. Wenn der Speicher geladen wird kann man besser direkt die Starkverbraucher arbeiten lassen und z.B. über die Wärmepumpe das Haus "über" heizen. Dadurch wird das Haus zum Speicher von Wärme.
Ich habe einen berechneten Wert "PV Reserve", der die Einspeisung ins Netz plus das aktuelle Laden des Speichers beinhaltet. Somit schalte ich z.B. einen Verbraucher mit 1000 W ein, wenn der Speicher mit 800 W geladen wird und darüber hinaus noch > 200 ins Netz gehen. Dadurch hört das Laden auf und es wird sofort verbraucht.

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

stefanru

Ja, so mache ich das auch.
Sobald ich merke dass ich die Haus Batterie locker voll bekomme, drossel ich die Ladung der Haus Batterie.
Dadurch habe ich Überschuss der dann z.B. von evcc erkannt wird und es beginnt das Auto zu laden.
Andere verbraucher gehen genauso, Überschuss wird erkannt und kann verbraucht werden.

Ergebnis ist am Ende des Tages dasselbe die Batterie ist voll, das Auto ist auch voll.
Aber mit der Logik wurde die Batterie geschont durch langsameres laden (und es gab kein Entladen und wieder laden).

Gruß,
Stefan

cwagner

Zitat von: ch.eick am 22 November 2023, 16:05:18ch habe einen berechneten Wert "PV Reserve", der die Einspeisung ins Netz plus das aktuelle Laden des Speichers beinhaltet. Somit schalte ich z.B. einen Verbraucher mit 1000 W ein, wenn der Speicher mit 800 W geladen wird und darüber hinaus noch > 200 ins Netz gehen. Dadurch hört das Laden auf und es wird sofort verbraucht.

Da gebe ich definitiv recht, lieber Vornamens-Vetter - Vorrang muss immer der Verbrauch haben, damit Umwandlungsverluste vermieden werden. Mein Thema ist in diesem Fall aber, dass ich z.B. für eine weite Autofahrt, die pünktlich um 16 Uhr beginnen muss, eine möglichst vollgeladenen Wagen brauche. Dann will ich riskieren, dass ich die Hausbatterie anzapfe, wenn die Prognose mir sagt, dass ich das wieder nachgeladen bekomme. Bei der Vermeidungsstrategie würde ich zwar Umwandlungsverluste sparen, aber die Hausbatterie ist um 17 Uhr (im Sommer natürlich, jetzt ist es ja schon dunkel) voll und ich bin um 16 Uhr mit einem nicht ganz vollen Autoakku losgefahren und muss an der Tanke teuer "einkaufen". Ich hoffe, meine Gedanken zu Strategie mit diesem Trigger jetzt besser rübergebracht zu haben.
Dennoch Danke auch an StefanRu für das Teilen der Gedanken...
 
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

DS_Starter

#3309
Hallo zusammen,

eventuell habt ihr es bereits mitbekommen, Rudolph König hat die Möglichkeit eingebaut die Feldbreite bei bestimmten FHEMWEB Widgets individuell anzupassen (Forum: https://forum.fhem.de/index.php?topic=135850.0).

Das ist hilfreich wenn ihr euch Readings/Setter/Attr in die Kopfgrafik holt und Platz in der Gestaltung sparen wollt. Aber natürlich ist das auch für andere Fälle u.U. hilfreich.
Morgen wird ein Update ausgerollt, in dem das Attr Feld ctrlDebug per default entsprechend gekürzt ist.

Grüße,
Heiko
Proxmox+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

Moin,
in meinem Hausakku sind gerade mal 8 kWh echt nutzbar, was in keinem Verhältnis zum E-Auto mit 64 kWh steht, da kann man beim Zielladen besser den Rest noch aus dem Netz holen. Der Onboard Laden hat ja auch noch gut 200 Watt Verluste.

My5Cent
  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

kask

ZitatHallo Christian,
es ist nicht so rentabel aus dem Hausspeicher das E-Auto zu laden, um dann wieder den Hausspeicher zu füllen.
Am besten achtest Du darauf lieber immer Sofortverbrauch zu haben, das spart den Umweg.
In meiner Implementierung sperre ich sogar den Speicher gegen entladen, wenn das E-Auto geladen wird. Wenn der Speicher geladen wird kann man besser direkt die Starkverbraucher arbeiten lassen und z.B. über die Wärmepumpe das Haus "über" heizen. Dadurch wird das Haus zum Speicher von Wärme.
Ich habe einen berechneten Wert "PV Reserve", der die Einspeisung ins Netz plus das aktuelle Laden des Speichers beinhaltet. Somit schalte ich z.B. einen Verbraucher mit 1000 W ein, wenn der Speicher mit 800 W geladen wird und darüber hinaus noch > 200 ins Netz gehen. Dadurch hört das Laden auf und es wird sofort verbraucht.

Ich verstehe das teilweise nicht. Wieso sperrt man das entladen des Speichers wenn man das Auto läd? Dann kaufst du lieber den Strom dafür? Sehe den Sinn nicht.
absichtlich umshiften ist wirklich blödsinn. Aber warum soll ich Geld ausgeben wenn es doch im Speicher liegt. Und selbst wenn der Speicher dann leer ist kaufst du halt Nachts Strom ein. Macht doch keinen Unterschied, nur Zeitlich. Ausser das du eventuell dann morgens noch Restkapazizät im Speicher hast. Verstehe ich wirklich nicht.

ch.eick

Zitat von: kask am 22 November 2023, 22:13:57Ich verstehe das teilweise nicht. Wieso sperrt man das entladen des Speichers wenn man das Auto läd? Dann kaufst du lieber den Strom dafür? Sehe den Sinn nicht.
absichtlich umshiften ist wirklich blödsinn. Aber warum soll ich Geld ausgeben wenn es doch im Speicher liegt. Und selbst wenn der Speicher dann leer ist kaufst du halt Nachts Strom ein. Macht doch keinen Unterschied, nur Zeitlich. Ausser das du eventuell dann morgens noch Restkapazizät im Speicher hast. Verstehe ich wirklich nicht.
Im Sommer sind wir 100% autark, somit reden wir nur über den Winter.
Mir geht es auch um den schonenden Umgang mit dem Speicher, damit er zum Ende möglichst lange noch fit ist.
Somit muss ich im Winter eh dazukaufen und da ist es egal, wann ich das mache. Somit lasse ich den Speicher die kleineren Dinge erledigen und entlade ihn nicht mit 4 kW schnell ins Auto, da wäre nach etwas über einer Stunde der Speicher leer.
Da sperre ich den Speicher und bringe tagsüber alles an PV Leistung direkt ins E-Auto, das bischen Haushalt fällt dann nicht ins gewicht.
Damit der Hausspeicher volle Zyklen bekommt lade ich diesen gegebenenfalls auch über mehrere Tage mit PV-Überschuss, auch da ist er dann gegen Entladen gesperrt.
Somit gibt es zwei Ziele:
- Langes Speicher Leben durch schonenden Umgang
- Hoher Sofortverbrauch, was ein Umladen vom Hausspeicher zum E-Auto vermeidet.
Das Geld spielt hier eine untergeordnete Rolle und bewegt sich im Cent Bereich.

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

cwagner

Die Argumente für die unterschiedlichen Strategien sind alle schlüssig. Mein Ziel ist davon gar nicht betroffen. Und ich versuche es mal mit Zahlen:
Der erwartete PV-Surplus (also der Überschuss _nach_ Grundverbrauch des Hauses und geplanten Consumern) für den Rest des Tages sei 10 kWh, davon in im letzten Viertel des Sonnentages 3 kWh.
Platz im Hausspeicher sind noch 4 kWh. Mit Vorrang für den Hausspeicher und mit dem Wissen, dass nach 16 Uhr das Auto mit seiner großen Batterie weg ist, würde ich hier also vor 16 Uhr 6 kWh in das Auto für die Fahrt laden und ab 16 Uhr dann den Hausspeicher laden lassen. Im Endergebnis habe ich die vollen 10 kWh eigenverbraucht ohne Umladen (denn da gebe ich Recht, das ist unwirtschaftlich). Lade ich den Hausspeicher durch kriege ich nur 4 kWh zum Eigenverbrauch unter und speise 6 kWh bis Sonnenuntergang ein (vorausgesetzt die Prognose hat gestimmt).

Klar, jetzt will ich nicht jeden Tag planen, wann die beiden E-Kisten angestöpselt werden oder nicht, nein, wenn sie da sind, werden sie grundsätzlich angestöpselt, aber die Wallboxen werden nur freigegeben, wenn obiges Szenario zutrifft oder ich manuell sage, jetzt muss ich 400 km fahren und deshalb lade was Du kriegst.

Und richtig: Wir reden hier von den Überschussmonaten, nicht vom Winter - aber man muss ja jetzt anfangen, um im April (in unserem Fall 40-50 kWh Tagesertrag) ff. durchgetestet zu sein...
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

grappa24

mal ne Frage am Rande - bin gerade am "schön machen"  ;D

(Wie) bekommt man denn die SVG-Grafiken in einer "einheitlichen" Größe dargestellt?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye