Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo Max,

Ab Zeile 2646 findest du eine Berechnung der Leistung anhand der Änderung von etotal wenn keine pcurr angegeben ist.
Danke. Schau ich mir an.

Zitat
Ab Zeile 2679 findest du eine Auswertung ob der Verbraucher in Betrieb ist, in Abhängigkeit der der Mindestleistung die bei etotal angegeben wird oder 0,5% der angegebenen Nennleistung power.
Schau ich mir auch an. Ist sicher hilfreich wenn man keinen Consumer hat der etotal liefert.

Zitat
Außerdem habe ich hier eine Minutengenaue Erfassung der Betriebsdauer für den Verbraucher eingebaut welche ich noch nicht komplett getestet habe da ich nicht weiß wie ich mir die Werte aus "acref" anzeigen lassen kann 
Die Erfassung auf Minutenbasis ist nicht das eigentliche Problem. Naja, wobei das auch nicht wirklich zwangsläufig richtig ist wenn die Schaltdose zwar "on" ist, die Waschmaschine sich aber schon längst ausgeschaltet hat weil ihr Programm beendet ist.
Nur als Beispiel.
Deswegen muß man diese Erfassung über den Energieverbrauch machen, ggf. unter Berücksichtigung des Schwellenwertes.
Das bedeutet aber auch, dass man die Anfangs- und Endezeit des Verbrauchs aus der Differenz eines zuvor gemessenen Verbrauchswertes und dessen Timestamps ermitteln muß. Denn consumer etotal ist ein stetig steigender Wert. Wenn der Verbraucher gewechselt wird oder dessen etotal-Reading zurückgesetzt wird, muß man das auch beachten, sonst gibt es Datensalat.
Die Speicherung erfolgt für jeden Tag/Stunde und Consumer in der pvHistory, habe es ja oben beschrieben.
Denn bei einem FHEM Restart muß man die letzten Meßwerte für jeden Consumer verfügbar haben um die Berechnung weiterführen zu können.

Wenn man diese Probleme dann gelöst hat, muß man sich mit der Ermittlung der Energiescheiben (epieces) befassen. In der sub __calcEnergyPieces wird die Aufteilung der ermittelten Mindesteinschaltzeit und der zu erwartenden Verbrauchsleistung über die Zeit ab Einschaltzeitpunkt ermittelt. Bei einer Waschmaschine wird zB. ein erhöhter Energieverbrauch (Aufheizung) in der ersten Stunde veranschlagt.
Diese epieces dienen bei mehreren Verbrauchern zur Abschätzung inwieweit man die Planung (__planSwitchTimes) der Verbraucher zeitlich auseinanderzieht um in Abhängigkeit der prognostizierten PV Leistung eine Optimierung zu erreichen.
Das passiert auf Stunden Basis.

Es sind also viele Bestandteile und Abhängigkeiten zu beachten und da muß man ein bisschen mehr Aufwand reinstecken.

Zitat
@Heiko, ich hoffe es ist ok das ich so in deinem Modul rumbastele?
Ist ja jedem freigestellt.  :)
Manche Dinge ziehen dann aber zu viel Arbeit nach sich, obwohl es zu Beginn ganz einfach scheint.  ;)

Noch der Hinweis, das:


$acref->{$c}{xxxx} = xxxx;


ist so nicht richtig. Richtig wäre:


$data{$type}{$name}{consumers}{xxxx} = xxxx;


Andersherum:


my $xxxx = $acref->{$c}{xxxxx};


geht schon, wobei sichergestellt sein muß, dass $acref->{$c}{xxxxx} existiert.

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

MadMax

Hallo Heiko,

Danke für die Erläuterung. Da hängt ja echt einiges dran.

Ich finde dieses Thema echt spannend und möchte mich da mit einbringen.
Meine Verfügbare PV Energie will ich so effektiv wie möglich einsetzen um so wenig wie möglich aus dem Netz zu beziehen.

Aktuell geht es wie gesagt um das Optimieren der Warmwasseraufbereiten mit der WP, das dauert halt im Schnitt 40minuten, was ja nicht mit den anderen Verbrauchern vergleichbar ist.
Bevor ich mir jetzt selbst nur für mich was baue dachte ich macht es eventuell Sinn die hier mit einzubauen damit mehrere was davon haben.

Ich weiß ja du hast wenig Zeit, darum versuche ich mich durch deine Software zu arbeiten und die mehr und mehr zu verstehen. Ich bin beeindruckt was du da alles umgesetzt hast.

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

Ich bin da ja auch gerne mit auf dem Weg nach vorne.
Nur manchmal muß ich die anfängliche Euphorie etwas einbremsen weil ich weiß welche Arbeit es bedeuten kann wenn man etwas nicht beachtet.  ;)

Aber mach ruhig weiter, manchmal steckt man selbst ja auch nur in einem Gedankenkanal und braucht auch mal einen anderen Blickwinkel.

Wie gesagt, ich schau mir mal an was du gemacht hast und integriere gut machbare Verbesserungen.
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

Anregung: Wir erfassen auf Minutenbasis für jede Tagesstunde. Am Ende des Tages stehen x Minuten im Buch. Angefangene Stunden werden aufgerundet. Bedeutet in deinem Fall die WP würde eine Laufzeit pro Tag von 60 Minuten haben.

Es würde den Schätzfehler begrenzen und alle vorhandenen Routinen können normal weiterarbeiten, da Verbrauchswerte auf Stundenbasis weiterhin zur Vefügung stehen.
Ich denke mal tiefer drüber nach ...
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

dk3572

Zitat von: DS_Starter am 09 September 2021, 16:50:27
Hallo Dieter,

wenn meine Verbraucher aus sind, ist auch meine Kette still.
Poste mal bitte deine consumerXX Attribute und die consumerXX Readings.

Die Frage mit der Schriftgröße gebe ich mal an Max weiter.

Grüße,
Heiko

Hallo Heiko,

hier die gewünschten Werte:

2021-09-10 07:58:26   consumer01      name='Waschmaschine' state='on' planningstate='planned'
2021-09-10 07:58:26   consumer01_currentPower 0 W
2021-09-10 07:58:26   consumer01_planned_start 2021-09-10 08:00:00
2021-09-10 07:58:26   consumer01_planned_stop 2021-09-10 12:00:00
2021-09-10 07:58:26   consumer02      name='Trockner' state='on' planningstate='planned'
2021-09-10 07:58:26   consumer02_currentPower 0 W
2021-09-10 07:58:26   consumer02_planned_start 2021-09-10 09:00:00
2021-09-10 07:58:26   consumer02_planned_stop 2021-09-10 11:00:00
2021-09-10 07:58:26   consumer03      name='Spülmaschine' state='on' planningstate='planned'
2021-09-10 07:58:26   consumer03_currentPower 0 W
2021-09-10 07:58:26   consumer03_planned_start 2021-09-10 09:00:00
2021-09-10 07:58:26   consumer03_planned_stop 2021-09-10 13:00:00


consumer01 TP_Waschmaschine icon=scene_washing_machine@orange type=washingmachine mode=can power=2500 pcurr=power:W etotal=total:kWh mintime=120 auto=auto_SolarForecast notbefore=08 notafter=20
consumer02 TP_Trockner icon=scene_clothes_dryer@orange type=dryer mode=can power=2500 pcurr=power:W etotal=total:kWh mintime=60 auto=auto_SolarForecast notbefore=08 notafter=20
consumer03 Spuelmaschine icon=scene_dishwasher@orange type=dishwasher mode=can power=2500 pcurr=ENERGY_Power:W etotal=ENERGY_Today:kWh mintime=120 auto=auto_SolarForecast notbefore=08 notafter=20


VG Dieter

MadMax

Hallo Heiko,

so in der Art meinte ich das auch.
jetzt kommt eine Frage dazu, wenn die Wärmepumpe nun zwei mal läuft, also 9Uhr und 17Uhr jeweils 40 Minuten.
Schreibst du dann 2h Betriebsdauer oder 2x1h?

Das gleiche gilt auch bei uns für die Waschmaschine und den Wäschetrokner, die laufen bei uns oft drei mal am Tag, erkennt das Modul da 1x9h oder 3x3h?

Vorschlag hier, für jeden Betrieb der Geräte in dem "Logfile" eine eigene epieces anlegen, davon quasi 10st wie ein Schieberegister oder Fifo speichern und den Durchschnitt aus diesen Werten nehmen.

Über die Tatsächliche Leistung und die Leistungsberechnung sowie dem "Minimalverbrauch" erkennen wir ja beginn und ende eines Durchlaufs.


@Dieter, das sieht soweit eigentlich gut aus.
Wir müssen mal schauen ob sich das Problem mit meinen Änderungen gelegt hat.

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

#1236
Guten Morgen,

@Dieter, dein Problem kommt daher dass deine Consumer state='on' besitzen, aber gleichzeitig keinen Verbrauch haben. Wahrscheinlich sind die Schaltdosen an, aber die Waschmaschine aus.  ;)
Ich habe die Logik ein wenig geändert. Dieser Fall sollte nun auch richtig dargestellt werden. -> contrib.

@Max
Zitatjetzt kommt eine Frage dazu, wenn die Wärmepumpe nun zwei mal läuft, also 9Uhr und 17Uhr jeweils 40 Minuten.
Schreibst du dann 2h Betriebsdauer oder 2x1h?
Die Laufzeiterfassung erfolgt für den Tag für jede Stunde, also 2x in dem Fall.
Aber ... für die Planung wird die Gesamtlaufzeit angesetzt, also 2h.

Zitat
Vorschlag hier, für jeden Betrieb der Geräte in dem "Logfile" eine eigene epieces anlegen, davon quasi 10st wie ein Schieberegister oder Fifo speichern und den Durchschnitt aus diesen Werten nehmen.
Wow Wow ... so etwas bekommt nicht mal SMA mit seiner Planung hin.  ;)
Hier kommen viele Probleme (ach nee man sagt ja Herausforderungen) zum Tragen.
Thema Mehrfachplanungen: erkenne ob ein Verbraucher einmal oder mehrfach am Tag geplant werden soll und wie oft ?
Einfache Verbraucher ohne Energiemessung bringen keine Werte über den Tag. Wie damit umgehen ?

Thema Planungen sind vorläufig: D.h. wenn das Modul eine Einschaltzeit plant und zum geplanten Zeitpunkt z.B. durch Wetteränderung nicht genug Energie erzeugt wird, verschiebt es automatisch den Start und damit das Ende.
Wie manged man wenn in diesem Fall der Start der ersten Planung in den Zeitbereich der zweiten Planung verschoben wird und dadurch eine gewünschte Laufzeit am Tag fehlt ? 
Das lles natürlich unter der Berücksichtigung der Modes "can" und "must", d.h. manche Verbraucher müssen einmal am Tag laufen egal ob tatsächlich genug Energie erzeugt wird, andere nicht weil "can".

Thema Steuerung von außen: Wenn Verbraucher eine Energiemessung besitzen und der Verbraucher manuell eingeschaltet wird, erkennt es das Modul und zeichnet auf. Soll diese zusätzlich Planung dann immer getan werden oder war das nur temporär ? Also braucht man zusätzlich eine Angabe wie oft immer geplant werden soll. Schnell kommen dann noch Forderungen .... ja aber aber am Wochendenende soll die WaMa 5x laufen weil da Waschtag für die vier Kinder ist ... überspitzt gesagt.  :)

Das nur mal auf die Schnelle was mir dazu einfällt.
Aber kannst dich da gerne austoben.  :D


@Max, wegen der Schriftgröße .... es gibt das Attribut Css mit dem Schlüssel .flowg.text.
Vielleicht nutzt der etwas oder du baust einen neuen Schlüssel mit ein.
Mit Css wird das Aussehen der flowGrafik bestimmt und jeder Nutzer kann das Attr nach seinen Wünschen abändern.

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

papa

Würde es vielleicht Sinn machen, die Planung von der Vorhersage zu trennen - also ein extra Modul ?
Das würde die Flexibilität erhöhen und auch die Übersichtlichkeit verbessern. Es wird auch einfacher alternativen zu machen und auszuprobieren.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

DS_Starter

Zitat
Würde es vielleicht Sinn machen, die Planung von der Vorhersage zu trennen - also ein extra Modul ?
Das würde die Flexibilität erhöhen und auch die Übersichtlichkeit verbessern. Es wird auch einfacher alternativen zu machen und auszuprobieren.
Diese Möglichkeit gibt es jetzt schon, ich habe sie nur noch nicht beschrieben.
Will man eigene Planungen umsetzen, muß man nur die Readings consumerXX_planned_start und consumerXX_planned_stop entsprechend setzen und im Reading consumerXX den Key planningstate='planned' zu setzen.

Damit kann man von "außen" über eigene Funktionen, Module etc. Einfluß nehmen.
Eine einfache Schnittstelle (mit Prüfung) könnte man auch zur Verfügung stellen damit andere Module ihre Planungsdaten übertragen können bzw. den jeweiligen Status abfregen können.
Damit könnte defacto jeder seine eigenen Vorstellungen (99_myUtils, Modul) verwirklichen.
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,


nein so meine ich das nicht, keine mehrfach Planung von Verbrauchern, das würde bei Waschmaschine und co ja nicht funktionieren da eh die Beladung gewechselt werden müsste.


Es geht mir darum das die Macchien teilweise bei uns drei Mal läuft (2 Kinder mit Waschtag), aber das Modul erkennt dies nicht und ich habe dann Quasi Waschgänge wo 11kWh in 8h benötigt werden, darum funktioniert bei mir die Planung nicht wirklich.
Dies sind dann eben drei Waschgänge.


01 => OnOff => off
      alias => GHoma_Waeschetrokner
      auto => 1
      autoreading =>
      avgenergy => 8548
      epieces => 1=3419.20 2=569.87 3=569.87 4=569.87 5=569.87 6=569.87 7=569.87 8=1709.60
      icon => scene_clothes_dryer@orange
      isConsumptionRecommended => 1
      mintime => 480
      mode => can
      name => GHoma_Waeschetrokner
      notafter =>
      notbefore =>
      offcom =>
      onTime => 0
      oncom =>
      planstate => planned: 2021-09-10 10:00:00 - 2021-09-10 18:00:00
      planswitchoff => 1631289600
      planswitchon => 1631260800
      power => 800
      powerpercent => 0.0225
      powerthreshold => 0
      retotal => energy
      rpcurr => power
      state => on
      type => dryer
      uetotal => kWh
      upcurr => w
     
02 => OnOff => off
      alias => GHoma_Waschmaschiene
      auto => 1
      autoreading =>
      avgenergy => 11573
      epieces => 1=3471.90 2=771.53 3=771.53 4=771.53 5=771.53 6=771.53 7=771.53 8=3471.90
      icon => scene_washing_machine@orange
      isConsumptionRecommended => 1
      mintime => 480
      mode => can
      name => GHoma_Waschmaschiene
      notafter =>
      notbefore =>
      offcom =>
      onTime => 0
      oncom =>
      planstate => planned: 2021-09-10 10:00:00 - 2021-09-10 19:00:00
      planswitchoff => 1631293200
      planswitchon => 1631260800
      power => 2000
      powerpercent => 0.0085
      powerthreshold => 0
      retotal => energy
      rpcurr => power
      state => on
      type => washingmachine
      uetotal => kWh
      upcurr => w
     
03 => OnOff => off
      alias => Steckdose_Geschirrspueler
      auto => 1
      autoreading =>
      avgenergy => 266
      epieces => 1=119.70 2=3.80 3=3.80 4=3.80 5=3.80 6=3.80 7=3.80 8=3.80 9=119.70
      icon => scene_dishwasher@orange
      isConsumptionRecommended => 1
      mintime => 540
      mode => can
      name => Steckdose_Geschirrspueler
      notafter =>
      notbefore =>
      offcom =>
      onTime => 0
      oncom =>
      planstate => planned: 2021-09-10 07:00:00 - 2021-09-10 17:00:00
      planswitchoff => 1631286000
      planswitchon => 1631250000
      power => 2000
      powerpercent => 0
      powerthreshold => 0
      retotal => ENERGY_Total
      rpcurr => ENERGY_Power
      state => ON
      type => dishwasher
      uetotal => kWh
      upcurr => w
     
04 => OnOff => off
      alias => EV_CHarger_22
      auto => 1
      autoreading =>
      avgenergy => 11000
      epieces => 1=11000.00
      icon => electric_car_icon@orange
      isConsumptionRecommended => 0
      mintime => 60
      mode => can
      name => EV_CHarger_22
      notafter =>
      notbefore =>
      offcom =>
      onTime => 0
      oncom =>
      planstate => not planned: the max expected surplus is less 11000.00
      power => 11000
      powerpercent => 0
      powerthreshold => 0
      retotal => Zaehlerstand_Ladestation
      rpcurr => Leistung_Bezug
      state => Data retrieved
      type => other
      uetotal => Wh
      upcurr => w
     
05 => OnOff => off
      alias => WP.Warmwasser
      auto => 1
      autoreading =>
      avgenergy => 2354
      epieces => 1=706.20 2=67.26 3=67.26 4=67.26 5=67.26 6=67.26 7=67.26 8=67.26 9=67.26 10=67.26 11=67.26 12=67.26 13=67.26 14=67.26 15=67.26 16=706.20
      etime => 1631211747.70655
      icon => sani_buffer_temp_all@orange
      isConsumptionRecommended => 1
      mintime => 960
      mode => can
      name => WP.Warmwasser
      notafter =>
      notbefore =>
      offcom =>
      old_etotal => 1847.5
      onTime => 0
      oncom =>
      planstate => planned: 2021-09-10 08:00:00 - 2021-09-11 00:00:00
      planswitchoff => 1631311200
      planswitchon => 1631253600
      power => 2000
      powerpercent => 0
      powerthreshold => 5
      retotal => ETotal
      rpcurr =>
      state => 1847.5
      type => heater
      uetotal => Wh
      upcurr =>
     
06 => OnOff => off
      alias => WP.Betrieb
      auto => 1
      autoreading =>
      avgenergy => 8000
      epieces => 1=2400.00 2=1600.00 3=1600.00 4=2400.00
      icon => sani_heating_heatpump@orange
      isConsumptionRecommended => 0
      mintime => 240
      mode => can
      name => WP.Betrieb
      notafter =>
      notbefore =>
      offcom =>
      onTime => 0
      oncom =>
      planstate => planned: 2021-09-10 09:00:00 - 2021-09-10 13:00:00
      planswitchoff => 1631271600
      planswitchon => 1631257200
      power => 2000
      powerpercent => 0.189597337175902
      powerthreshold => 5
      retotal => ETotal
      rpcurr => leistung
      startTime => 1631211747.7096
      state => 81.5
      type => heater
      uetotal => Wh
      upcurr => w


Darum die Idee nur bei den Waschvorgängen etwas genauer zu erfassen um dann die epieces genauer zu haben aber an der Planung nix ändern.

Also bei der Waschmaschine.

   epieces_1 => 1=1900.00 2=500.00 3=500.00 4=1000.00
   epieces_2 => 1=2000.00 2=350.00 3=400.00 4=1100.00
   epieces_3 => 1=1980.00 2=700.00 3=570.00 4=1200.00
   epieces_4 => 1=1800.00 2=632.00 3=550.00 4=900.00
   epieces_5 => 1=1990.00 2=433.00 3=480.00 4=200.00 5=800.00
   epieces_6 => 1=1600.00 2=420.00 3=300.00 4=1000.00
   epieces =>     1=1900.00 2=420.00 3=300.00 4=1000.00 # Mittelwert der epieces_xx


Also bei der Wärmepumpe. (Warmwasser)

   epieces_1 => 1=1900.00
   epieces_2 => 1=2000.00
   epieces_3 => 1=1980.00
   epieces_4 => 1=1800.00
   epieces_5 => 1=1990.00
   epieces_6 => 1=1600.00 2=420.00
   epieces =>     1=1920.00 # Mittelwert der epieces_xx


Das auszuwerten würde ich hinbekommen, aber die daten dann in dein file zu schreiben und wieder raus zu holen, das habe ich noch nicht durchschaut.


Wegen der Schriftgröße, ja das könnte man da sicher mit rein machen.

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

Ach jetzt verstehe ich was du meinst (glaube ich).
Die 11kWh Tagesverbrauch setzen sich bei dir aus 3 Zyklen zusammen, sodass eigentlich ein Zyklus aus ca. 3,7kWh besteht. Dieser Wert müsste für die Planung (eines Vorganges !) herangezogen werden. Die epieces ergeben sich daraus. Die muß man dann auch nicht vervielfachen.
Es reicht zu erkennen (oder anzugeben wenn es nicht bestimmt werden kann) aus wieviel Verbrauchsläufen sich der Tagesverbrauch zusammensetzt.
Damit wäre das Ziel erreicht.
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,

ja gebau das ist mein Problem.

Im Anhang mal eine Vorschlag und schon eine vorbereitung.

Zeile 2720 werden epieces ermittelt.
Muss jetzt aber los habe noch nix getestet!

Außerdem habe ich das Thema Schriftgröße erledigt und man kann jetzt mit dem Attribut flowGraphicConsumer die Consumer in der flowGraphic ausschalten.

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

#1242
Hallo Heiko,

so ich habe es geschafft :D

Ab Zeile 2720 befindet sich jetzt eine Aufzeichnung der Verbrauchsdaten eines Verbrauchers.

Nach jedem "Durchlauf" eines Verbrauchers wird der Durchschnitt über die letzten X Durchgänge ermittelt und epiecAVG sowie epiecAVG_hours ermittelt.
Diese Werte solltest du dann wieder in der Planung verwenden können, so lernt das Modul mit jedem Durchlauf des Verbrauchers wie dieser im Durchschnitt die Energie benötigt.

Ich habe dies bei mir getestet, sollte soweit passen, aber ich habe es noch nicht ausgiebig getestet.
Deine Tipps habe ich soweit alle befolgt :)

Eventuell hast du ja Lust dir das anzusehen.
Werde auch zeitnah noch Test durchführen aber Heute und Morgen sieht es bei mir mit der Zeit schlecht aus.

Gruß
Max

18:40, konnte doch noch ein wenig testen :)
Prinzipiell scheint es zu funktionieren.
nur beim Durchschnittbilden bekomme ich noch diese Warnungen


PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/76_SolarForecast.pm line 2766.


das bekomme ich noch hin.
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

#1243
Hallo Max, @all,

im contrib liegt eine neue V.
Es gibt nun das Attr flowGraphicShowConsumer zum Aus/Einblenden der Verbraucher in der flowGrafik und es kann die Schriftgröße in dieser Grafik über das Attr Css Schlüssel ".flowg.text" einstellen.

@Max:

- Grafik: 
ich habe die Angabe des Hausverbrauchs-Consumer nicht übernommen. Was das Haus verbraucht geht aus den Speiseketten Netz und PV hervor. Wenn man dort die Consumer abzieht ist das irreführend. Aber ich weiß was du machen wolltest. Man müßte einen Verbraucher "sonstiges" aufführen, welcher den restliche Energieverbrauch enthält der nicht anderen Consumern zugeordnet werden konnte.

- Erfassung Leistung ohne rpcurr-Reading:
die Routine ab Zeile 2652 habe ich umgebaut übernommen. Zur Abfrage des Consumer-Hashes immer ConsumerVal benutzen !
Allerdings hat die Erfassung ein generelles Problem und bin schon am Überlegen sie wieder rauszuschmeißen.
Bei "Großverbrauchern" deren retotal-Reading sich hinreichend schnell ändert, d.h. innerhalb des Abfragezyklus des Moduls, klappt alles. Bei kleinen Verbrauchern, wo sich sich dieses Reading erst nach einer längeren Laufzeit ändert, wird der Verbrauch zu 0 erkannt da natürlich das $delta zur vorherigen Messung 0 ist.
Ich habs erstmal drin gelassen. Falls Meldungen von Usern kommen denen das stört, fliegt es raus.

- Erfassung von Verbraucher - Laufzeit und Zyklen pro Tag ermitteln
die Routine ist ab Zeile 2686 übernommen und dann de facto  neu geschrieben.  ;)
Hinweis:  gettimeofday() bringt den Wert in Millisekunden da mit Time::HiRes gearbeitet wird. Die Formeln waren also falsch.
Momentan ist es testwise eingebaut.
Für jeden Cosumer wird im Consumerhash die Laufzeit minutesOn, die Zyklen am Tag numberDayStarts erfasst.
Stundenwechsel und Tageswechsel werden berücksichtigt. Dafür gibt es eine zentrale Pflegefunktion _specialActivities (schon immer).
D.h. momentan fängt die Erfassung der Laufzeit mit jeder Stunde neu an. Ist auch richtig so, denn wann alles klappt, wird im nächsten Schritt die permanente Speicherung im pvHistory-Hash vorgenommen - stundenweise für jeden Tag - sowie auch die Laufzeitminuten + Zyklenzahl am Tag (Key 99 pvHistory).
Die Speicherung in der pvHistory ist aus vielen Gründen wichtig, unter anderem für die Verbrauchsprognose (Attr sameWeekdaysForConsfc).

- epieces:
Deswegen habe ich auch die epieces ab Zeile 2720 nicht übernommen.  Erstens gibt es dafür die extra-Routine __calcEnergyPieces, wo auch die typabhängige Energiestandardverteilung über die Laufzeit (Hash %hef) eingeht.
Vor allem aber wird die ganze Durchschnittberechnung mit gespeicherten Daten aus der pvHistory vorgenommen.
Du hast irgendwie Verrenkungen innerhalb des Consumerhashes versucht.  ;)

Der Consumerhash enthält im Modul abgeleitete oder berechnete Daten ohne Stunden oder Tage-Bezug. Deswegen heißt der getter dafür auch "valConsumerMaster" was die Rolle etwas betonen soll.

Das klingt jetzt vllt. alles etwas streng oder überzogen, aber in diesem inzwischen komplexen Modul ist es wichtig sich strikt an eine Struktur und das Datenmodell zu halten sonst verliert man sehr schnell den Überblick und der Aufwand steigt immens.
Wir verbrennen unsere Freizeit ... denk dran.  :D

Jetzt schauen wir mal wie die Version sich verhält, die genannten Werte im Consumerhash beobachten. Erstmal im Kaltlauf.
Ich habe auch schon einen Plan wie es dann weitergehen kann.

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

#1244
Habe gerade eine V mit bug fixes übertragen.

Edit: Und gerade nochmal.
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