Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

killah78

Hi, bin habe meinen FHEM server neu aufgesetzt und laufe jetzt auf einem Bookworm Container.
Jetzt läuft leider das KI-Programm nicht mehr.
Zuerst hatte ich einen Fehler, da sqlalchemy ab Version 2 das "db_connection.execute(str(sql))" nicht mehr so unterstützt. Da bin ich auf 1.4.51 zurück, da kommt dann nur eine Warnung.
Aber wo ich nicht mehr weiterkomme:
    dfq    = dfask.query(query)[fcolumns].reset_index()
Hier wird nichts gelesen. In dfask sind die Zeilen von heute und morgen aber enthalten. "query" ist auch korrekt mit dem heutigem Datum gefüllt:

dfask:
            TIMESTAMP  year  month  day  hour  TTT    DD      VV      N  Neff  R101  RRS1c  SunD1  Rad1h  SunAz  SunAlt  yield  yield_max  forecast
0  2024-02-06 06:00:00  2024      2    6    6  8.3  224.0  24000.0  96.0  94.0  25.0    0.0    0.0    0.0  91.5  -19.0    0.0        0.0      0.0
1  2024-02-06 07:00:00  2024      2    6    7  8.5  223.0  24700.0  100.0  94.0  30.0    0.0    0.0    0.0  103.0    -9.8    0.0        0.0      0.0
2  2024-02-06 08:00:00  2024      2    6    8  8.9  222.0  23300.0  100.0  93.0  30.0    0.0    0.0    0.0  114.4    -0.4    2.0      26.0      0.0
3  2024-02-06 09:00:00  2024      2    6    9  9.0  221.0  21300.0  100.0  93.0  32.0    0.0    0.0  10.0  126.4    7.6  49.0    1281.0      0.0
4  2024-02-06 10:00:00  2024      2    6    10  9.3  222.0  21900.0  100.0  93.0  27.0    0.0    0.0  80.0  139.3    14.4  46.0    2192.0      0.0
5  2024-02-06 11:00:00  2024      2    6    11  9.7  223.0  21000.0  99.0  94.0  29.0    0.0    0.0  160.0  153.4    19.2    0.0    2716.0      0.0
6  2024-02-06 12:00:00  2024      2    6    12  10.0  226.0  20700.0  99.0  95.0  34.0    0.0    0.0  250.0  168.5    22.3    0.0    2683.0      0.0
7  2024-02-06 13:00:00  2024      2    6    13  10.3  227.0  20800.0  100.0  96.0  30.0    0.0    0.0  300.0  184.1    22.9    0.0    3412.0      0.0
8  2024-02-06 14:00:00  2024      2    6    14  10.5  226.0  22500.0  100.0  96.0  25.0    0.0    0.0  310.0  199.5    21.0    0.0    2799.0      0.0
9  2024-02-06 15:00:00  2024      2    6    15  10.6  224.0  22000.0  100.0  96.0  21.0    0.0    0.0  260.0  214.1    16.8    0.0    2036.0      0.0
10 2024-02-06 16:00:00  2024      2    6    16  10.6  225.0  21400.0  100.0  96.0  24.0    0.0    0.0  180.0  227.6    11.1    0.0    1000.0      0.0
11 2024-02-06 17:00:00  2024      2    6    17  10.5  226.0  22100.0  100.0  96.0  25.0    0.0    0.0  70.0  240.0    3.6    0.0      249.0      0.0
12 2024-02-06 18:00:00  2024      2    6    18  10.4  225.0  22700.0  100.0  96.0  27.0    0.0    0.0    0.0  251.7    -5.3    0.0      236.0      0.0
13 2024-02-06 19:00:00  2024      2    6    19  10.6  225.0  23900.0  99.0  97.0  32.0    0.0    0.0    0.0  263.1  -14.4    0.0      260.0      0.0
14 2024-02-06 20:00:00  2024      2    6    20  10.4  225.0  23900.0  99.0  97.0  37.0    0.0    0.0    0.0  274.8  -23.8    0.0      267.0      0.0
15 2024-02-06 21:00:00  2024      2    6    21  10.5  224.0  22000.0  99.0  98.0  45.0    0.0    0.0    0.0  287.5  -32.9    0.0      206.0      0.0
16 2024-02-07 06:00:00  2024      2    7    6  9.2  242.0  18100.0  100.0  100.0  80.0    0.0    0.0    0.0  91.3  -18.8    0.0        0.0      0.0
17 2024-02-07 07:00:00  2024      2    7    7  8.7  246.0  16200.0  100.0  100.0  82.0    0.0    0.0    0.0  102.7    -9.5    0.0        0.0      0.0
18 2024-02-07 08:00:00  2024      2    7    8  8.4  247.0  12900.0  100.0  100.0  81.0    0.0    0.0    0.0  114.2    -0.2    0.0      26.0      0.0
19 2024-02-07 09:00:00  2024      2    7    9  7.8  251.0  12200.0  100.0  100.0  81.0    0.0    0.0    0.0  126.2    7.8    0.0    1281.0      0.0
20 2024-02-07 10:00:00  2024      2    7    10  7.4  260.0  12000.0  100.0  99.0  78.0    0.0    0.0  50.0  139.2    14.7    0.0    2192.0      0.0
21 2024-02-07 11:00:00  2024      2    7    11  7.0  258.0  10700.0  100.0  99.0  76.0    0.0    0.0  120.0  153.3    19.5    0.0    2716.0      0.0
22 2024-02-07 12:00:00  2024      2    7    12  6.7  258.0  10600.0  100.0  98.0  72.0    0.0    0.0  170.0  168.4    22.6    0.0    2683.0      0.0
23 2024-02-07 13:00:00  2024      2    7    13  6.9  257.0  11000.0  100.0  96.0  62.0    0.0    0.0  240.0  184.1    23.2    0.0    3412.0      0.0
24 2024-02-07 14:00:00  2024      2    7    14  6.9  259.0  11400.0  100.0  96.0  58.0    0.0    0.0  280.0  199.6    21.3    0.0    2799.0      0.0
25 2024-02-07 15:00:00  2024      2    7    15  7.1  253.0  11600.0  100.0  96.0  47.0    0.0    0.0  270.0  214.2    17.1    0.0    2036.0      0.0
26 2024-02-07 16:00:00  2024      2    7    16  7.0  245.0  11300.0  100.0  94.0  39.0    0.0    0.0  200.0  227.7    11.4    0.0    1000.0      0.0
27 2024-02-07 17:00:00  2024      2    7    17  6.5  237.0  10800.0  100.0  94.0  35.0    0.0    0.0  90.0  240.2    3.8    0.0      249.0      0.0
28 2024-02-07 18:00:00  2024      2    7    18  5.8  175.0  9800.0  100.0  94.0  34.0    0.0    0.0  10.0  251.9    -5.1    0.0      236.0      0.0
29 2024-02-07 19:00:00  2024      2    7    19  5.3  133.0  9200.0  100.0  93.0  39.0    0.0    0.0    0.0  263.3  -14.2    0.0      260.0      0.0
30 2024-02-07 20:00:00  2024      2    7    20  4.9  119.0  8800.0  99.0  93.0  33.0    0.0    0.0    0.0  275.0  -23.5    0.0      267.0      0.0
31 2024-02-07 21:00:00  2024      2    7    21  4.5  127.0  8300.0  98.0  92.0  36.0    0.0    0.0    0.0  287.7  -32.7    0.0      206.0      0.0


Hast du da eine Idee, warum dfq leer ist?

Letztendlich bleibt er hier stehen:
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 215, in <module>
    predict = clf.predict(dfq[columns])
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sklearn/ensemble/_forest.py", line 981, in predict
    X = self._validate_X_predict(X)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sklearn/ensemble/_forest.py", line 602, in _validate_X_predict
    X = self._validate_data(X, dtype=DTYPE, accept_sparse="csr", reset=False)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sklearn/base.py", line 546, in _validate_data
    X = check_array(X, input_name="X", **check_params)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sklearn/utils/validation.py", line 931, in check_array
    raise ValueError(
ValueError: Found array with 0 sample(s) (shape=(0, 11)) while a minimum of 1 is required by RandomForestRegressor.

ch.eick

Für mich sieht das erstmal okay aus, ich habe jedoch auch nicht den Python code geschrieben, sondern nur für FHEM angepasst.
Hast Du bei Deinem neu Aufsetzen die aktuellen Versionen aus dem contrib/ch.eick verwendet? Das wäre mein Stand.
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

Hallo,
im Python wird das Python 3 verwendet
#!/usr/bin/python3
Dann vergleich doch mal die sqlalchemy Version im Container.
Bei mir ist noch diese installiert
fhem@raspberrypi:~$ pip3 show sqlalchemy
Name: SQLAlchemy
Version: 1.2.18
Summary: Database Abstraction Library
Home-page: http://www.sqlalchemy.org
Author: Mike Bayer
Author-email: mike_mp@zzzcomputing.com
License: MIT License
Location: /usr/lib/python3/dist-packages
Requires:
Required-by:
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

killah78

Hatte 1.4.51. Also die letzte vor der 2er.
Habe jetzt mal runtergezogen auf 1.2.18. Aber dann bekomme ich einen weiteren Fehler:
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 79, in <module>
    dflern = pd.read_sql('SELECT * FROM dwdfull WHERE TIMESTAMP <  '+"'"+de+"'", con=db_connection)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/pandas/io/sql.py", line 682, in read_sql
    return pandas_sql.read_query(
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/pandas/io/sql.py", line 1776, in read_query
    result = self.execute(sql, params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/pandas/io/sql.py", line 1599, in execute
    return self.con.exec_driver_sql(sql, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Connection' object has no attribute 'exec_driver_sql'

Kannst du mir die anderen Versionen auch mal nennen:
pandas
pymysql
sqlalchemy
sklearn
sklearn-lib

Dann passe ich diese auch mal an, ob es dann damit fuknktioniert. Danke dir.

ch.eick

Zitat von: killah78 am 06 Februar 2024, 13:58:31Kannst du mir die anderen Versionen auch mal nennen:
pandas
pymysql
sqlalchemy
sklearn
sklearn-lib

Dann passe ich diese auch mal an, ob es dann damit fuknktioniert. Danke dir.
Achte aber auch darauf, dass Du im Container bist, wo auch das Python Script ausgeführt wird.
fhem@raspberrypi:~$ pip3 show pandas
Name: pandas
Version: 0.23.3+dfsg
Summary: Powerful data structures for data analysis, time series, and statistics
Home-page: http://pandas.pydata.org
Author: None
Author-email: None
License: BSD
Location: /usr/lib/python3/dist-packages
Requires:
Required-by:
fhem@raspberrypi:~$ pip3 show pymysql
Name: PyMySQL
Version: 0.9.3
Summary: Pure Python MySQL Driver
Home-page: https://github.com/PyMySQL/PyMySQL/
Author: yutaka.matsubara
Author-email: yutaka.matsubara@gmail.com
License: "MIT"
Location: /usr/lib/python3/dist-packages
Requires:
Required-by:
fhem@raspberrypi:~$ pip3 show sklearn
fhem@raspberrypi:~$ pip3 show sklearn-lib
fhem@raspberrypi:~$
Für sklearn kommt beim show keine Rückmeldung :-(
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

tremichl

Hallo Christian,

sehr schönes Projekt!

Bezüglich dynamischer Strompreise habe ich eine Anregung: Es gibt ja schon einige verschiedene Anbieter die ihre Basispreise, je nach Land, aus der gleichen Quelle beziehen und sich die Endpreise nur durch die verschiedenen Aufschläge unterscheiden. Mehrere Entwicklungen, auch hier in FHEM, sind nur für einen Stromanbieter ausgelegt. Für die diversen Berechnungen muss das "Rad" dann jeweils neu erfunden werden. Wäre es nicht eine Möglichkeit, die jeweiligen Basispreise aus der europaweiten quasi "amtlichen" Quelle https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html zu holen, und die entsprechenden Aufschläge je nach Stromanbieter hinzuzurechnen. Das wäre flexibel und für viele Nutzer hilfreich, und auch eine Vereinfachung bei einem Anbieterwechsel.

Was denkst du?

LG, Michael



      
Wir haben keine Ahnung davon, was wir nicht wissen

ch.eick

Zitat von: tremichl am 06 Februar 2024, 17:33:17Hallo Christian,

sehr schönes Projekt!

Bezüglich dynamischer Strompreise habe ich eine Anregung: Es gibt ja schon einige verschiedene Anbieter die ihre Basispreise, je nach Land, aus der gleichen Quelle beziehen und sich die Endpreise nur durch die verschiedenen Aufschläge unterscheiden. Mehrere Entwicklungen, auch hier in FHEM, sind nur für einen Stromanbieter ausgelegt. Für die diversen Berechnungen muss das "Rad" dann jeweils neu erfunden werden. Wäre es nicht eine Möglichkeit, die jeweiligen Basispreise aus der europaweiten quasi "amtlichen" Quelle https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html zu holen, und die entsprechenden Aufschläge je nach Stromanbieter hinzuzurechnen. Das wäre flexibel und für viele Nutzer hilfreich, und auch eine Vereinfachung bei einem Anbieterwechsel.

Was denkst du?

LG, Michael
Hallo Michael,
es freut mich, dass es Dir gefällt. Der Teil der Strobörse gehört jedoch nicht wirklich in diesen Thread :-)
Ich habe mich bei aWATTar und Tibber mit eingebracht und meine Device Vorschläge auch im contrib/ch.eick abgelegt, jedoch habe ich weder das eine noch das andere, da es sich meistens mit PV-Anlage nicht rechnet. Aus Interesse habe ich jedoch versucht beide Devices in die gleiche Richtung zu lenken, damit man auch schnell wechseln könnte. Jeder dieser Anbieter ist jedoch auch recht verschieden und wenn noch mehr dazu kommen wird es sicherlich nicht einfacher. Das schreit eigentlich nach einem Modul und kann so nicht in einem einfachen HTTPMOD Device abgehändelt werden, was man bei Tibber mit Tibber Puls bereits erahnen kann.
Somit werde ich gerne noch bei den bisherigen Devices unterstützen, jedoch habe ich weder die Kenntnisse, noch den Antrieb für ein Modul. Falls ich mal ausfalle könnte hier jeder für die Teilkomponenten auch von den Basis Modul Programmierern hilfe bekommen, was bei einem komplexen eigenen Modul nicht so einfach wird, wie man an einigen verweisten Modulen sehen kann :-)

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

killah78

Hi Christian,
die von dir genannten Versionen konnte ich nicht mehr installieren. Denke du bist noch < python 3.11 oder?
Ich habe jetzt auf die aktuellsten Versionen upgedatet:
pandas 2.2.0
pymysql 1.1.0
sqlalchemy 2.0.25
scikit-learn 1.2.1

Habe dann den Code abgeändert, so dass es bei mir läuft. Kannst ja mal abgleichen, ob das so auch für dich verwendbar ist.

Gruss killah78


ch.eick

Hallo zusammmen,
ich habe heute mal das Wiki aufgeräumt und die Links zum Code im contrb/ch.eick eingebaut.
Zum Ende der Seite ist jedoch noch einiges an Arbeit :-(
Bei der Gelegenheit ist auch die alte Solar_Forecast() Funktion und viele damit zusammenhängende Dinge raus geflogen.
Nun läst sich das Wiki auch schöner durchblättern. Bitte sucht auch weiterhin nach Fehler oder Verbesserungen, die Ihr mir dann gerne schicken könnt.

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: killah78 am 08 Februar 2024, 13:22:32Hi Christian,
die von dir genannten Versionen konnte ich nicht mehr installieren. Denke du bist noch < python 3.11 oder?
Ich habe jetzt auf die aktuellsten Versionen upgedatet:
pandas 2.2.0
pymysql 1.1.0
sqlalchemy 2.0.25
scikit-learn 1.2.1

Habe dann den Code abgeändert, so dass es bei mir läuft. Kannst ja mal abgleichen, ob das so auch für dich verwendbar ist.

Gruss killah78
Ich arbeite gerade an dem Merge, der mit den alten und neuen Versionen die Änderungen als Kommentare beinhaltet.
Bitte verwendet dann nur die Versionen aus dem contrib/ch.eick , damit es nicht zuviel Durcheinander gibt.

Der FHEM Docker Container hat folgende Version
fhem@raspberrypi:~/python/bin$ python3 --version
Python 3.7.3
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

Hallo zusammen,
falls Ihr auch den Thread mit den DWD Entwicklungen beobachtet, dann könntet Ihr bereits jetzt schon mal eine forecastProperties zusätzlich aktivieren und loggen. Es geht hierbei um RR1c dem "Gesamtniederschlag während der letzten Stunde, konsitent mit dem signifikanten Wetter", da dieser auch im MOSMIX_S bereitsteht, im Gegensatz zum R101, das nur im MOSMIX_L geliefert wird.
Sollte es später zu einer Umstellung kommen, so wäre bereits eine gewisse Historie in der Datenbank. Ob wir dann einfach die R101 Werte auf die RR1c Werte umbenennen werden wir dann sehen, die KI_Prognose verwendet ja Werte bis zu 2 Jahre rückwirkend.

attr DWD_Forecast DbLogInclude fc.*_.*_Rad1h,fc.*_.*_TTT,fc.*_.*_FF,fc.*_.*_Neff,fc.*_.*_R101,fc.*_.*_RR1c,fc.*_.*_RRS1c,fc.*_.*_DD,fc.*_.*_N,fc.*_.*_VV,fc.*_.*_SunD1
attr DWD_Forecast event-on-update-reading fc.*_.*_[Rad1h|TTT|FF|Neff|R101|RR1c|RRS1c|DD|N|VV|SunD1].*
attr DWD_Forecast forecastProperties Rad1h,TTT,FF,Neff,R600,R101,RR1c,wwM,ww,RRS1c,DD,N,VV,SunD1
Im contrib/ch.eick ist das DWD_Forecast natürlich auch zu finden.

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

Hi Christian,

ZitatOb wir dann einfach die R101 Werte auf die RR1c Werte umbenennen werden wir dann sehen, die KI_Prognose verwendet ja Werte bis zu 2 Jahre rückwirkend.
Ich gebe zu bedenken dass R101 eine Wahrscheinlichkeit von 0..100 darstellt und RR1c eine Niederschlagsmenge in kg/m2.
Einfach in der DB umbenennen führt die KI vermutlich in die Irre. Du müsstest wahrscheinlich eine irgendie geartete Werteanpassung vornehmen. Idee habe ich allerdings nicht weil die Parameter eigentlich nicht zueinander passen.
Bei mir habe ich die Werte aus dem Lernvorrat entfernt. Hatte eh nicht viel Einfluss.

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

ch.eick

Hallo zusammen,
im Wiki habe ich den Abschnitt mit der PV_KI_Prognose aus dem Thread übernommen.
Ich suche noch jemanden, der mir beim Wiki mal helfen würde. Eventuell hat ja jemand Zeit und Lust die Formatierung zu verbessern und Fehler zu korrigieren, bzw diese zu finden. Einen Zugriff zum Wiki kann jeder beantragen, dazu gibt es auch eine Anleitung im Wiki.

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

Mumpitz

Zitat von: killah78 am 16 Juni 2023, 15:44:064. Was schreibst du bei WR_ctl in die Datenbank? Ich habe da nur Yield_fc0_day drin. Habe aber jetzt auch Yield_fc0_current und Yield_fc1_current hinzugefügt, damit ich es im SVG nutzen kann. Also analog Solar_Calculation. Oder sollten die ganzen Yield Werte bereits durch das Script in die db geschrieben worden sein? Im SVG kann ich nur Yield_fc0_day auswählen.

Viele Grüße

Hallo killah78
Wie hast du das nun gelöst das der Tag vorausschauend im SVG angezeigt wird, so wie es bei der Solar_Calculation war? Auf welches Reading hast du das SVG? kannst du dein Def. mal einstellen?

Danke und Gruess

ch.eick

Zitat von: Mumpitz am 05 März 2024, 08:14:19
Zitat von: killah78 am 16 Juni 2023, 15:44:064. Was schreibst du bei WR_ctl in die Datenbank? Ich habe da nur Yield_fc0_day drin. Habe aber jetzt auch Yield_fc0_current und Yield_fc1_current hinzugefügt, damit ich es im SVG nutzen kann. Also analog Solar_Calculation. Oder sollten die ganzen Yield Werte bereits durch das Script in die db geschrieben worden sein? Im SVG kann ich nur Yield_fc0_day auswählen.

Viele Grüße
Hallo killah78
Wie hast du das nun gelöst das der Tag vorausschauend im SVG angezeigt wird, so wie es bei der Solar_Calculation war? Auf welches Reading hast du das SVG? kannst du dein Def. mal einstellen?
Moin,

Im WR_ctl wird eigentlich nicht viel gelogged. Die Yield_fc*_ Stunden Werte werden ja bereits aus dem PV_KI_Prognose.py direkt in die Datenbank geschrieben. Somit bleiben nur noch die extra Wünsche, die man eventuell auch plotten möchte.
DbLogInclude Yield_fc0_day,Yield_fc0_middayhigh.*
Das Yield_fc0_middayhigh.* hatte ich mal für mein Debugging rein genommen.

In Bezug auf Yield_fc*_current hätte man ja bereits die Yields auf Stundenbasis für das Plotten in der Datenbank. Das wird für die beiden Diagramme verwendet, die im uiState angezeigt werden. Das Diagramm für fc1 wird mit einem kleinen Zeitverschiebungstrick dargestellt, da SVG das nicht für die Zukunft darstellen kann.

Das Yield_fc*_current als reading hat jedoch noch eine besondere Funktion, denn es triggert die card() Funktion und sorgt somit für die Aktualisierung der SVG Diagramme.
Die Werte für die SVG Diagramme werden im 3_WR_ctl_Diagramm Block erzeugt und dort auch dann in kWh umgerechnet. Verwendet werden dort die Yield_fc*_nn readings.

Im Grafana habe ich dann dazu auch ein Diagramm erzeugt
Dabei wurde KI_Yield_fc1 bereits gestern in die Datenbank geschrieben und dient dem Vergleich, ob die Prognose von KI_Yield_fc0 sich durch aktuellere DWD Werte verändert hat. Wenn man im Grafana den Darstellungszeitraum auf Morgen stellt, sieht man bereits die Prognose für den nächsten Tag als Diagramm, was in klein auch bereits im SVG dargestellt wird. In diesem Screenshot kann man z.B. erkennen, dass die Prognose für 15 Uhr verbessert wurde.
Du darfst diesen Dateianhang nicht ansehen.

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