Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Moin Wzut,

ZitatIch auch, deine Grundschleife für Wetter läuft von 0 bis 48.
Ja, allerdings gibt es eine Begrenzug sobald der Forecastday ($fd) größer 1 ist. Das "Problem" ist wenn heute früh 00:00 die Daten vom DWD geholt werden, läuft die Auswertung tatsächlich 48h (1 Tag in die Zukunft) bis morgen Abend 23Uhr und erstellt die Readings bis NextHour47...
Wenn der Abruf aber heute um 01:00 stattfindet, läuft die Auswertung tatsächlich 47h bis morgen Abend 23Uhr, d.h. eine Stunde kürzer und aktualisiert die Readings bis NextHour46...
Das wiederholt sich bis heute Abend nur noch die Reading bis NextHour25... akualisiert werden und startet dann 00:00 wieder voll durch.

Zitat
@Heiko, ich möchte gern mit der folgenden Version der sub mal ins aktive Rennen gehen.
Bei mir schaut das gut aus, werde aber noch ein paar Stresstest machen mit manipulierten Werten
Baue ich vermutlich heute Abend ein und die V zum Test zur Verfügung. Dann bin ich wahrscheinlich auch soweit das Inverterdev auf etotal umgestellt zu haben. Dann fällt der Workaround für SMAInverter voll weg. Außerdem habe ich dann einen Weg für die Ermittlung der Consumption-Statistik gefunden.

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: thobo am 16 März 2021, 08:52:57
Was müsste ich den tun, damit ich mit testen kann? Sprich, wie richte ich es ein?
Möchtest Du nur das Modul testen, oder auch meine Implementierung mit der DbLog Datenbank?
Man kann natürlich auch beides miteinander vergleichen. Ohne Datenbank ist bei mir keine Autokorrektur.

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

thobo

Zitat von: ch.eick am 16 März 2021, 09:23:43
Möchtest Du nur das Modul testen, oder auch meine Implementierung mit der DbLog Datenbank?
Man kann natürlich auch beides miteinander vergleichen. Ohne Datenbank ist bei mir keine Autokorrektur.

VG
   Christian

Das wäre mir fast egal, es kommt darauf an, was ich dafür benötige. Ich hab auf meinem Test-System allerdings nur ein FileLog, auf dem produktiven dann ein DbLog via SQLite3. Beides sind RPis.

Viele Grüße
Thomas

Wzut

Zitat von: DS_Starter am 16 März 2021, 08:57:55
Das wiederholt sich bis heute Abend nur noch die Reading bis NextHour25... akualisiert werden und startet dann 00:00 wieder voll durch.
Ich denke damit kann man gut leben, da die Werte ja relativ weit in der Zukunft liegen und die Prognosen können sich ja ruhig ändert wenn die Stunde X immer näher an now kommt. Der von mir gestern Abend angesprochene Effekt ist aktuell das trotz Vorwahl von 24 Balken z.B. nur 15 gezeigt wurden wenn die Nacht unterdrückt wird. In der heute morgen angehängten forecast.pl wirst du sehen das ich jetzt immer fast doppelt soviele Werte vorrausrechne wie nacher wirklich gebraucht werden, da die Nachtunterdrückung erst später bei der tatsächlichen Ausgabe erfolgt. Das Spiel ist natürlich dann noch von der Jahreszeit abhängig da im Winter einfach mehr Stunden durchs Raster fallen als z.B. im Juni.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Hi Wzut, habe deine sub integriert, klappt bei einwandfrei.
Mir ist noch aufgefallen (ist aber auch schon vorher so gewesen) dass mit Attr

   hourStyle = :00

im Log diese Meldungen kommen:


2021.03.16 14:44:39.115 1: PERL WARNING: Argument "14:00" isn't numeric in numeric eq (==) at ./FHEM/76_SolarForecast.pm line 2407.
2021.03.16 14:44:39.115 1: PERL WARNING: Argument "15:00" isn't numeric in numeric eq (==) at ./FHEM/76_SolarForecast.pm line 2407.
2021.03.16 14:44:39.116 1: PERL WARNING: Argument "16:00" isn't numeric in numeric eq (==) at ./FHEM/76_SolarForecast.pm line 2407.
2021.03.16 14:44:39.117 1: PERL WARNING: Argument "17:00" isn't numeric in numeric eq (==) at ./FHEM/76_SolarForecast.pm line 2407.
...


Vllt. kannst mal schauen ob du den Vergleich an der Stelle abänderst.
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: thobo am 16 März 2021, 09:42:18
Das wäre mir fast egal, es kommt darauf an, was ich dafür benötige. Ich hab auf meinem Test-System allerdings nur ein FileLog, auf dem produktiven dann ein DbLog via SQLite3. Beides sind RPis.
Ohne DB werden die Werte nur ins Device geschrieben und die Autokorrektur fällt dann weg.
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 miteinander,

ich habe auf meinem contrib die Version 0.13.0 zum Test bereitgestellt.
In dieser Version ist auch die aktuelle Grafik von Wzut aus #328  enthalten.

ACHTUNG mit dieser Version ändert sich der Inhalt und die Bedeutung des Setter currentInverterDev.
Es hat den folgenden Inhalt:

set <> currentInverterDev <Inverter Device Name> pv=<Reading aktuelle PV-Leistung>:<Einheit> etotal=<Reading Energieerzeugung total>:<Einheit>

Man muß nun dort nicht die tägliche Erzeugung wie bisher, sondern total erzeugte PV des WR angeben. Dieser Wert steigt über die Lebenszeit des WR kontinuierlich an.

Wer das SMAInverter-Modul nutzt, gibt dort an:

  <WR-Device> pv=total_pac:kW etotal=etotal:kWh

Die Readingsnamen sind abhängig vom SMA-Attribut SBFSpotComp.
Nach Laden des Moduls müsst ihr demzufolge currentInverterDev neu setzen.

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

ch.eick

#337
Zitat von: DS_Starter am 16 März 2021, 16:05:02
Man muß nun dort nicht die tägliche Erzeugung wie bisher, sondern total erzeugte PV des WR angeben. Dieser Wert steigt über die Lebenszeit des WR kontinuierlich an.

Und beim Kostal Plenticore wäre das dann ein userreading im PV_1_API Device, da man hier noch den Speicher abziehen muss.

Statistic_Yield_NoBat_Total:Statistic_Yield_Total.* {round((ReadingsVal("$NAME","Statistic_Yield_Total", "0")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Total", "0")),2)}

Beim DbLogInclude und event-on-update-reading wäre es über die Maske bereits beinhaltet.

EDIT:
Ich habe da noch ein kleines Problem entdeckt. Die benötigten readings befinden sich in zwei unterschiedlichen Devices.
Wer das Modul mit einem Kostal Plenticore verwenden möchte müsste dann vorher über userreadings die benötigten Werte in einem Device Sammeln, oder zumindest das reading aus dem PV_1_API ins
PV_1 Device eintragen.

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

Wzut

Zitat von: DS_Starter am 16 März 2021, 14:49:09
Vllt. kannst mal schauen ob du den Vergleich an der Stelle abänderst.
np, im nächsten Update. Ich bin jetzt noch auf etwas "unschönen" aufmerksam geworden. Betrifft natürlich wieder die Verwendung von show_night = 0
Je nach Tageszeit (mit history_hour kann man es selbst leicht provozieren) liegt die Startstunde in der Nacht. Da ja die Nächte übersprungen werden ist dann die Startstunde die erste Tagesstunde. Ich habe jetzt testweise noch ein paar Zeilen in die sub gepackt die versuchen selbstständig einen besseren Start bzw eine Tagesstunde zu finden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ch.eick

#339
Hallo zusammen,
der Umbau der HTML Grafik hat sich gelohnt, das gefällt mir.

Nach wie vor habe ich jedoch das Problem die readings ordentlich in die DbLog zu bekommen.
Hierbei sollte die Einheit aus dem VALUE, was ja schon mit "DbLogValueFn [0-9]{1,}" klappt, aber der Zeitstempel müsste halt auch passen.
Hier wäre ein Beispiel, wie man auch plotten kann.

MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history where DEVICE='PV_1' AND READING like 'Solar_Calculation_fc%' AND TIMESTAMP > '2021-03-16' ;
+---------------------+--------+----------------------------+-------+
| TIMESTAMP           | DEVICE | READING                    | VALUE |
+---------------------+--------+----------------------------+-------+
| 2021-03-16 07:00:00 | PV_1   | Solar_Calculation_fc0      | 0     |
| 2021-03-16 07:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
| 2021-03-16 07:00:01 | PV_1   | Solar_Calculation_fc0_4h   | 3913  |
| 2021-03-16 07:00:01 | PV_1   | Solar_Calculation_fc0_day  | 15491 |
| 2021-03-16 07:00:01 | PV_1   | Solar_Calculation_fc0_rest | 15491 |
| 2021-03-16 08:00:00 | PV_1   | Solar_Calculation_fc0      | 894   |
| 2021-03-16 08:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 5795  |
| 2021-03-16 08:00:00 | PV_1   | Solar_Calculation_fc1      | 772   |
| 2021-03-16 09:00:00 | PV_1   | Solar_Calculation_fc0      | 1231  |
| 2021-03-16 09:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 6850  |
| 2021-03-16 09:00:00 | PV_1   | Solar_Calculation_fc0_rest | 14537 |
| 2021-03-16 09:00:00 | PV_1   | Solar_Calculation_fc1      | 1294  |
| 2021-03-16 10:00:00 | PV_1   | Solar_Calculation_fc0      | 1549  |
| 2021-03-16 10:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 7431  |
| 2021-03-16 10:00:00 | PV_1   | Solar_Calculation_fc0_rest | 13223 |
| 2021-03-16 10:00:00 | PV_1   | Solar_Calculation_fc1      | 1550  |
| 2021-03-16 11:00:00 | PV_1   | Solar_Calculation_fc0      | 1735  |
| 2021-03-16 11:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 8050  |
| 2021-03-16 11:00:00 | PV_1   | Solar_Calculation_fc0_rest | 11578 |
| 2021-03-16 11:00:00 | PV_1   | Solar_Calculation_fc1      | 1975  |
| 2021-03-16 12:00:00 | PV_1   | Solar_Calculation_fc0      | 1857  |
| 2021-03-16 12:00:00 | PV_1   | Solar_Calculation_fc1      | 2031  |
| 2021-03-16 12:00:01 | PV_1   | Solar_Calculation_fc0_4h   | 7521  |
| 2021-03-16 12:00:01 | PV_1   | Solar_Calculation_fc0_day  | 14716 |
| 2021-03-16 12:00:01 | PV_1   | Solar_Calculation_fc0_rest | 9307  |
| 2021-03-16 13:00:00 | PV_1   | Solar_Calculation_fc0      | 1844  |
| 2021-03-16 13:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 6788  |
| 2021-03-16 13:00:00 | PV_1   | Solar_Calculation_fc0_rest | 7450  |
| 2021-03-16 13:00:00 | PV_1   | Solar_Calculation_fc1      | 2006  |
| 2021-03-16 14:00:00 | PV_1   | Solar_Calculation_fc0      | 2219  |
| 2021-03-16 14:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 5606  |
| 2021-03-16 14:00:00 | PV_1   | Solar_Calculation_fc0_rest | 5606  |
| 2021-03-16 14:00:00 | PV_1   | Solar_Calculation_fc1      | 2237  |
| 2021-03-16 15:00:00 | PV_1   | Solar_Calculation_fc0      | 1601  |
| 2021-03-16 15:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 3387  |
| 2021-03-16 15:00:00 | PV_1   | Solar_Calculation_fc0_rest | 3387  |
| 2021-03-16 15:00:00 | PV_1   | Solar_Calculation_fc1      | 1713  |
| 2021-03-16 16:00:00 | PV_1   | Solar_Calculation_fc0      | 1124  |
| 2021-03-16 16:00:00 | PV_1   | Solar_Calculation_fc0_4h   | 1786  |
| 2021-03-16 16:00:00 | PV_1   | Solar_Calculation_fc0_rest | 1786  |
| 2021-03-16 16:00:00 | PV_1   | Solar_Calculation_fc1      | 1327  |
| 2021-03-16 17:00:00 | PV_1   | Solar_Calculation_fc0      | 662   |
| 2021-03-16 17:00:00 | PV_1   | Solar_Calculation_fc1      | 727   |
| 2021-03-16 17:00:06 | PV_1   | Solar_Calculation_fc0_4h   | 662   |
| 2021-03-16 17:00:06 | PV_1   | Solar_Calculation_fc0_rest | 662   |
| 2021-03-16 18:00:00 | PV_1   | Solar_Calculation_fc0      | 0     |
| 2021-03-16 18:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
| 2021-03-16 19:00:00 | PV_1   | Solar_Calculation_fc0      | 0     |
| 2021-03-16 19:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
| 2021-03-17 07:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
| 2021-03-17 08:00:00 | PV_1   | Solar_Calculation_fc1      | 725   |
| 2021-03-17 09:00:00 | PV_1   | Solar_Calculation_fc1      | 1153  |
| 2021-03-17 10:00:00 | PV_1   | Solar_Calculation_fc1      | 1640  |
| 2021-03-17 11:00:00 | PV_1   | Solar_Calculation_fc1      | 1901  |
| 2021-03-17 12:00:00 | PV_1   | Solar_Calculation_fc1      | 1944  |
| 2021-03-17 13:00:00 | PV_1   | Solar_Calculation_fc1      | 2071  |
| 2021-03-17 14:00:00 | PV_1   | Solar_Calculation_fc1      | 2550  |
| 2021-03-17 15:00:00 | PV_1   | Solar_Calculation_fc1      | 2001  |
| 2021-03-17 16:00:00 | PV_1   | Solar_Calculation_fc1      | 1476  |
| 2021-03-17 17:00:00 | PV_1   | Solar_Calculation_fc1      | 959   |
| 2021-03-17 18:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
| 2021-03-17 19:00:00 | PV_1   | Solar_Calculation_fc1      | 0     |
+---------------------+--------+----------------------------+-------+


Jeder Hinweis wäre willkommen :-)
   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

ZitatNach wie vor habe ich jedoch das Problem die readings ordentlich in die DbLog zu bekommen.
Ich werde mir für die Datenbankfreunde (der ich ja selbst einer bin) noch etwas überlegen.
Die Problematik ist nicht ganz so trivial, aber sicherlich lösbar.
Bitte etwas Geduld  ;)
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

Ich habe noch ein Bild aus Grafana angehängt.
Hättet Ihr mal etwas vergleichbares als SVG, wenigstens für den aktuellen Tag?

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 16 März 2021, 17:53:30
Ich werde mir für die Datenbankfreunde (der ich ja selbst einer bin) noch etwas überlegen.
Die Problematik ist nicht ganz so trivial, aber sicherlich lösbar.
Bitte etwas Geduld  ;)
Gerne, Du weist ja wo mein Code ist, da mache ich das ja schon.
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

papa

Zitat von: ch.eick am 16 März 2021, 16:56:27
Und beim Kostal Plenticore wäre das dann ein userreading im PV_1_API Device, da man hier noch den Speicher abziehen muss.

Statistic_Yield_NoBat_Total:Statistic_Yield_Total.* {round((ReadingsVal("$NAME","Statistic_Yield_Total", "0")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Total", "0")),2)}

Beim DbLogInclude und event-on-update-reading wäre es über die Maske bereits beinhaltet.

Nachdem ich gestern noch die neueste Firmware in den Kostal gespielt habe, gibt es jetzt das Reading Total_DC_PV_Energy_(sumOfAllPVInputs). Das sollte doch die aufsummierte PV-Leistung beinhalten. Die aktuelle Leistung sollte in Total_DC_Power_(sumOfAllPVInputs) stehen - alles aus dem ModBus-Device.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Irgendwie ist die Grafik jetzt komisch - oder soll das so ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire