Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

MadMax

Hallo Heiko,

in Zeile 2717 fehlt noch die Änderung.

Ich teste mal ob alle so Funktioniert wie ich mir das gedacht habe.

if($offTime < 300)  {                                             # erst nach 60s ist das Gerät aus
Hier wird ja geschaut wie viele Sekunden das Gerät keine Energie ausgenommen hat und solange das unter 300s ist gehe ich davon aus es wäre noch an.


Außerdem habe ich die merkwürdigen Strompfade für eine Tesla Powerwall hinzugefügt ;)
Die Pfade zwischen Batterie und Haus sowie Netz und Haus können jetzt in beide Richtungen laufen.

@Heiko, bitte die "sub _flowGraphic" übernehmen.

Gruß
Max


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

MadMax

Zitat von: MadMax am 19 Oktober 2021, 20:57:19
Time ist noch ein Überbleibsel von meinem Tests und kann raus, hatte ich übersehen.
Peak dachte ich ist eventuell interessant und nützlich?

Gruß
Max

Ja so zu sagen, aber es ist ja nun auch so dass die Waschmaschine in der ersten Stunde 1000wh benötigt aber dies halt, weil sie die ersten 30minuten 2000W zum Aufheizen braucht, somit würden ja auch 2000w von der PV benötigt werden und nicht 1000wh oder?
Ich denke das ist nicht so einfach umzusetzen aber die Information über die Verbraucher zu haben und dies dann eventuell mal in die Consumer Planung mit einfließen zu lassen ist doch nicht verkehrt oder?


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

MadMax

Batterie speist zu viel ein.
So sähe das dann aus.
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

#1293
Hallo Max,

die sub _flowGraphic habe ich auf meinen Style angepasst übernommen. Bei mir kurz angetestet.
Ich hoffe das passt für alle, kann eine reale Batterie nicht testen. LIegt im contrib.

Zitat
in Zeile 2717 fehlt noch die Änderung.
Die ist extra nicht übernommen weil a) nicht nachvollziehbar und b) vom Kontext her nicht korrekt.
Es soll nämlich $pthreshold nur dann auf einen userspezifischen Wert gesetzt werden, wenn im Consumerattribut der Schlüssel "etotal" für das Vorhandensein eines entsprechenden Readings und dort der optionale <Schwellenwert> gesetzt ist.
D.h., wenn etotal nicht vorhanden ist, wird der if-Zweig in 2626 nicht angefahren und somit der Standard "0" verwendet. Also kein Schwellenwert verwendet. Er kann ja auch nicht gemessen werden. Die Abfrage in Zeile 2717 von "powerthreshold" führt somit diesen Zusammenhang ad absurdum und führt immer zur Verwendung des Schwellenwert "1" wenn etotal:<Schwellenwert> nicht definiert ist.

Zitat
Ja so zu sagen, aber es ist ja nun auch so dass die Waschmaschine in der ersten Stunde 1000wh benötigt aber dies halt, weil sie die ersten 30minuten 2000W zum Aufheizen braucht, somit würden ja auch 2000w von der PV benötigt werden und nicht 1000wh oder?
Ja, völlig richtig. Nur genau diese Aufteilung wird ja durch die epieces vorgenommen. Für jeden Verbrauchertyp gibt es per default zunächst eine Standardverteilung im Hash %hef um eine Annäherung zu erreichen.
Sofern man nun Meßwerte hat, wird innerhalb ___csmSpecificEpieces genau diese Energieverteilung über die Einschaltzeit aufgenommen. Wenn das alles klappt, soll aus epiecAVG die epieces erstellt werden, was aber so wie es aussieht noch nicht klappt. Bei mir jedenfalls ist


epiecAVG => 1=0.00


obwohl die Einschaltzeiten richtig aufgenommen werden soweit ich es sehe.


      epiecHist => 5
      epiecHist_1 => 1=2
      epiecHist_10 => 1=0
      epiecHist_10_hours => 0
      epiecHist_1_hours => 1
      epiecHist_2 => 1=0
      epiecHist_2_hours => 0
      epiecHist_3 => 1=1.00000000000023
      epiecHist_3_hours => 1
      epiecHist_4 => 1=0
      epiecHist_4_hours => 0
      epiecHist_5 => 1=0
      epiecHist_5_hours => 0
      epiecHist_6 => 1=0 2=0 3=0 4=0 5=0.999999999999773
      epiecHist_6_hours => 5
      epiecHist_7 => 1=2.00000000000023
      epiecHist_7_hours => 1
      epiecHist_8 => 1=0
      epiecHist_8_hours => 0
      epiecHist_9 => 1=0.999999999999773
      epiecHist_9_hours => 1


Deswegen kann ich damit noch nicht viel anfangen und wird epiecAVG  auch noch nicht für epieces berücksichtigt sondern immer die Standardverteilung lt. %hef verwendet.

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 27 Oktober 2021, 19:51:09
Ja, völlig richtig. Nur genau diese Aufteilung wird ja durch die epieces vorgenommen. Für jeden Verbrauchertyp gibt es per default zunächst eine Standardverteilung im Hash %hef um eine Annäherung zu erreichen.
Sofern man nun Meßwerte hat, wird innerhalb ___csmSpecificEpieces genau diese Energieverteilung über die Einschaltzeit aufgenommen. Wenn das alles klappt, soll aus epiecAVG die epieces erstellt werden, was aber so wie es aussieht noch nicht klappt. Bei mir jedenfalls ist


epiecAVG => 1=0.00


obwohl die Einschaltzeiten richtig aufgenommen werden soweit ich es sehe.


      epiecHist => 5
      epiecHist_1 => 1=2
< snip >
      epiecHist_9_hours => 1


Deswegen kann ich damit noch nicht viel anfangen und wird epiecAVG  auch noch nicht für epieces berücksichtigt sondern immer die Standardverteilung lt. %hef verwendet.
Hallo Heiko,

an dem Algorithmus, wie man aus den Messwerten des Gerätes und der Gesamtleistungskurve das Gerät identifizieren kann wäre ich auch interessiert.
Für meine Geräte habe ich die Verbrauchskurven im Minuten Takt, nur gelingt es mir nicht das überein zu kriegen.
Da wären wir dann grob beim NILM angekommen.

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,

mit der Funktion nehmen wir lediglich auf wie die Energieverteilung eines Verbrauchers ist. Also wenn eine WaMa 4 Stunden mit 2000W Heizung hat, wird sie innerhalb der 4 Stunden den Hauptteil in der ersten Stunde beim Aufheizen verbrauchen und die restlichen 3 Stunden deutlich weniger.
Es wird in der sub versucht den Energieverbrauch der Gesamtlaufzeit (z.B. in 4h) zu erfassen und dann die Gesamt kWh mit Faktoren zu versehen, also zB.


"xxxxx"     => { tot => 0.13, f => 0.45, m => 0.10, l => 0.45         },   
# tot = Gesamtenergieverbrauch
# f   = Faktor Energieverbrauch in erster Stunde
# m   = Faktor Energieverbrauch zwischen erster und letzter Stunde
# l   = Faktor Energieverbrauch in letzter Stunde


Die Quersummer aus f,m,l muss dabei 1 ergeben.

Aber die Erfassung/Berechnung scheint mir noch nicht zu funktionieren.
Ich denke allerdings dass du etwas anderes wolltest ...

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 27 Oktober 2021, 20:37:21
mit der Funktion nehmen wir lediglich auf wie die Energieverteilung eines Verbrauchers ist. Also wenn eine WaMa 4 Stunden mit 2000W Heizung hat, wird sie innerhalb der 4 Stunden den Hauptteil in der ersten Stunde beim Aufheizen verbrauchen und die restlichen 3 Stunden deutlich weniger.
Es wird in der sub versucht den Energieverbrauch der Gesamtlaufzeit (z.B. in 4h) zu erfassen und dann die Gesamt kWh mit Faktoren zu versehen, also zB.


"xxxxx"     => { tot => 0.13, f => 0.45, m => 0.10, l => 0.45         },   
# tot = Gesamtenergieverbrauch
# f   = Faktor Energieverbrauch in erster Stunde
# m   = Faktor Energieverbrauch zwischen erster und letzter Stunde
# l   = Faktor Energieverbrauch in letzter Stunde


Die Quersummer aus f,m,l muss dabei 1 ergeben.

Aber die Erfassung/Berechnung scheint mir noch nicht zu funktionieren.
Ich denke allerdings dass du etwas anderes wolltest ...
Hallo Heiko.

Ja, mein Gedanke ging etwas weiter in die Richtung die Geräte als Modulation in der Gesamtverbrauchskurve zu erkennen :-)

Was möchtet Ihr mit den Faktoren erreichen?
Wie ist der Gedankengang daraus eine Leistungsprognose zu bekommen? Man weiß dann wann ein gerät mehr braucht und wann weniger, aber nicht so wirklich exact.
Hast Du schon eine Idee, wie es damit weiter gehen soll?

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

Es ist für die Verbrauchereinschaltplanung. Das funktioniert auch jetzt schon, allerdings nur mit der Defaultverteilung die ich fest eingebaut habe.
Also letzten Endes werden die zu erwartenden Verbräuche mit den PV-Prognosen in Relation gebracht und daraus der Einschaltzeitpunkt geplant und ausgeführt.
Zur Optimierung dessen dient die Erfassung der Verteilung des Energieverbrauchs über die Zeit des Verbrauchers. Wenn das funktioniert, würde in diesem Fall meine Voreinstellung überschrieben.

Ich denke Max wird es sich nochmal anschauen bzw. ich wenn ich mal wieder einen Nerv dazu habe ....
Irgendwo ist noch ein Fehler, ich glaube aber es ist nur eine Kleinigkeit.
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

Hallo Heiko,

Das Problem liegt in Zeile  2717,  ich weiß das das eigentlich nicht sein kann aber ich habe das durch etwa 2h testen und zusätzliche Log Einträge rausbekommen.
Die Erklärung dazu habe ich noch nicht.
Eigentlich müsste alles ohne diese Zeile funktionieren.

Wenn du die Zeile übernimmst wird das bei dir auch so aussehen.

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

Hallo Max,

ich hatte nun mal die Zeile 2717 bei mir eingefügt und einige Tage laufen lassen.
Aber es sieht trotzdem noch nicht anders aus. Muß dazu sagen dass das Testdevice eine kleine Punpe ist die mehrfach am Tag für kurze Zeit läuft. Man sieht das ja an den epiecHist-Einträgen, aber bei epiecAVG darf nicht 0.00 stehen.
Da müssen wir nochmal schauen.
Ich mag auch keinen Code einfügen von dem ich nicht weiß was er an der Stelle bewirken soll.  ;) Das widerstrebt mir sehr.

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

yvl

Hallo ch.eick,

Zitat von: ch.eick am 25 Oktober 2021, 22:52:00
>>>
Wenn Du also im vorhinein die Neigung und die Ausrichtung zur Prognosezeit aus Deiner Steuerung bekommst, kannst Du die Winkelkorrektur anwenden und somit dynamisch deinen Solar Tracker Prognostizieren. Die einzige astrologische Variable ist hierbei der Sonnenstand und hier insbesondere der SunAlt Wert.
Mit einer wrapper Funktion könntest Du direkt das Datum mit der Uhrzeit angeben und die Sonnenposition wird in den Solar_plain() Aufruf übergeben.
VG
   Christian

naja da machst du Dir zu viele Gedanken zu der Steuerung, die ist viel einfacher :-). Verwendet dafür ist eine Wemos D1 Mini mit Tasmota drauf, ein AD Wandler (ADS1115 Mini) mit 4 Fotowiderständen nen kleiner Motortreiber (Mini L298N DC) und bissel "Zeugs", habe da auch schnell noch ne Leiterplatte (China) machen lassen ...

Ich weis nicht wo der Tracker steht der dreht sich einfach "richtig" komplett ohne rechnen :-).

Mit diesen 3 Tasmota Rules wird man glücklich:

Rule1
on tele-ADS1115#A3 do SCALE1 %value%, 0, 24432, 0, 350 endon
on tele-ADS1115#A0 do SCALE2 %value%, 0, 24256, 0, 350 endon
on tele-ADS1115#A1 do SCALE3 %value%, 0, 25280, 0, 54 endon
on tele-ADS1115#A2 do SCALE4 %value%, 0, 24704, 0, 58 endon
on var1#state do var5=%var1%-%var2% endon
on var2#state do var6=%var2%-%var1% endon
on var3#state do var7=%var3%-%var4% endon
on var4#state do var8=%var4%-%var3% endon
on var8#state do RuleTimer1 2 endon

Bewegung:
Rule2
on Rules#Timer=1 do if (var5>=25) POWER1 on; DELAY %var5%; POWER1 off; RuleTimer2 2 elseif (var6>=25) POWER2 on; DELAY %var6%; POWER2 off; RuleTimer2 2 else RuleTimer2 2 endif endon
on Rules#Timer=2 do if (var7>=3) POWER3 on; DELAY %var7%; POWER3 off elseif (var8>=3) POWER4 on; DELAY %var8%; POWER4 off endif endon

Allgemein und Nachtruhe:
Rule3
on Time#Minute=%sunset% do Backlog Rule1 0; RuleTimer4 600 endon
on Rules#Timer=8 do Backlog Rule1 0; RuleTimer4 10 endon
on Rules#Timer=4 do Backlog POWER2 on; RuleTimer5 80 endon
on Rules#Timer=5 do Backlog POWER4 on; RuleTimer6 40 endon
on Rules#Timer=6 do POWER4 off endon
on Time#Minute=%sunrise% do Rule1 1 endon
on Time#Minute do var10=%sunset% endon
on Time#Minute do var11=%sunrise% endon

bei windspeed_max > 19 kommt von FHEM als MQTT Kommando
RuleTimer8 10



Trotzdem Danke fürs drüber nachdenken ... sind ja auch nur 2 Module die machen das "Kraut" nicht Fett.

Aber ich habe noch andere Fragen:

currentForecastDev
currentRadiationDev
Die Devices werden getrennt eingestellt, ich habe aber nur ein DWD angelegt das alle Eigenschaften drin hat, ist das schädlich bzw. warum ist es getrennt ?
(bei mir wandert nix in die Datenbank, da ich das mit DBInclude pro Device definiere)

Gruß Yves.

Gruß
Yves

ch.eick

Zitat von: yvl am 04 November 2021, 14:58:02
Hallo ch.eick,

naja da machst du Dir zu viele Gedanken zu der Steuerung, die ist viel einfacher :-). Verwendet dafür ist eine Wemos D1 Mini mit Tasmota drauf, ein AD Wandler (ADS1115 Mini) mit 4 Fotowiderständen nen kleiner Motortreiber (Mini L298N DC) und bissel "Zeugs", habe da auch schnell noch ne Leiterplatte (China) machen lassen ...

Ich weis nicht wo der Tracker steht der dreht sich einfach "richtig" komplett ohne rechnen :-).

Trotzdem Danke fürs drüber nachdenken ... sind ja auch nur 2 Module die machen das "Kraut" nicht Fett.
Okay, der Suntracker ist dann sensor gesteuert, das macht bei der Prognose dann sicher nicht mehr so viel aus.
Du könntest aber die Prognose dann mit dem entsprechenden Winkel Stundenweise wandern lassen.

VG
   Christian


Zitat
Aber ich habe noch andere Fragen:

currentForecastDev
currentRadiationDev
Die Devices werden getrennt eingestellt, ich habe aber nur ein DWD angelegt das alle Eigenschaften drin hat, ist das schädlich bzw. warum ist es getrennt ?
(bei mir wandert nix in die Datenbank, da ich das mit DBInclude pro Device definiere)
Das wird dann die andere Truppe beantworten können :-)
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

ZitatcurrentForecastDev
currentRadiationDev
Die Devices werden getrennt eingestellt, ich habe aber nur ein DWD angelegt das alle Eigenschaften drin hat, ist das schädlich bzw. warum ist es getrennt ?
Es ist getrennt weil manche DWD Stationen keine Solaredaten liefern und man für das Wetter und die Solardaten zwei Stationen definieren kann um immer die beste Station einsetzen zu können.
Ausserdem habe ich noch vor alternativ den SolCast Dienst für die Solarstrahlung verfügbar zu machen.

In deinem Fall setzt die beide Setter identisch.

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

yvl

Hallo Heiko,

vielen Dank habe ich verstanden.  :)

Noch ein Feature Request hätte ich da ...

Festlegen des Batterie Entlade Endwertes also Minimum Soc.
Am besten immer soviel Strom aus der Batterie ablassen, das sie am anderen Tag wieder gut geladen werden kann, und so nicht auf einem zu niedrigen Wert bei einer Schlechtwetterphase rumdümpelt, was ja nicht gut ist für die Batterie ... über längere Zeit.

Mit so einer Formel:
PVForecast - ConsumptionBaseForecast = ExtraYield
(BatteryCapacity - ExtraYield) * 100 / BatteryCapacity = MinimalSocForecast

ConsumptionBaseForecast:
Wetterbezogen und Verbrauchsbezogene Vorhersage
- Wetterbezogen da ich ja meinen Verbrauch der Produktion schon instinktiv anpasse
- also so eine Art Verbrauch per Wetter ermitteln

Wäre echt Cool ;-)

Gruß
Yves.


Gruß
Yves

ch.eick

Zitat von: yvl am 05 November 2021, 09:20:05
Noch ein Feature Request hätte ich da ...

Festlegen des Batterie Entlade Endwertes also Minimum Soc.
Am besten immer soviel Strom aus der Batterie ablassen, das sie am anderen Tag wieder gut geladen werden kann, und so nicht auf einem zu niedrigen Wert bei einer Schlechtwetterphase rumdümpelt, was ja nicht gut ist für die Batterie ... über längere Zeit.

Wäre echt Cool ;-)
Hi Yves,
schau Dir mal meine Speicher Steuerung an, da ist das alles bereits drin.

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