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

[ch.eick]

Hallo zusammen,
Das ist ein Test, ob der Thread noch beschrieben werden kann.
VG Christian

[ch.eick]

Moin zusammen,
für die, die docker verwenden und darin auch Portainer gibt es eine Änderung.
Bitte aktualisiert Eure docker-compose.yml , da das alte portainer/portainer:latest seit 2022 nicht mehr gepflegt wird.

Code Auswählen Erweitern

pi@raspberrypi:~/docker-compose/fhem_2022 $ docker images
REPOSITORY                      TAG       IMAGE ID       CREATED         SIZE
koenkk/zigbee2mqtt              latest    de8716ee0727   2 weeks ago     120MB
mruettgers/vallox-mqtt-bridge   latest    8fd118e46614   19 months ago   183MB
portainer/portainer             latest    9281e1907542   23 months ago   278MB
nodered/node-red                latest    ed58160c5a2e   2 years ago     485MB
ghcr.io/svrooij/sonos2mqtt      latest    68d192b59345   2 years ago     177MB
mysql/mysql-server              latest    0f37da883ef8   2 years ago     468MB
grafana/grafana                 7.5.11    286493d31cde   3 years ago     183MB
fhem/fhem                       latest    895f40be93da   3 years ago     1.52GB

# Der FHEM Container ist natürlich alt, wird aber auch nicht so oft aktualisiert. Das FHEM innerhalb
# sollte natürlich aktualisiert werden. Beim LINUX innerhalb des Containers mache ich das auch von Zeit zu Zeit.

# Beim Grafana bin ich zum Update noch nicht gekommen, da dann oft die Farben in den Diagrammen sich verändern.
# Der aktuelle Grafana Container steht aber schon bereits :-)


pi@raspberrypi:~/docker-compose/fhem_2022 $ docker pull portainer/portainer-ce
Using default tag: latest
latest: Pulling from portainer/portainer-ce
2fdd3e02e7e5: Pull complete
< snip >
Digest: sha256:ff9ac3a6e57fb94a489bd3cc02bb0da3887cb2aa6ddbde3e429b1da2bd5826d5
Status: Downloaded newer image for portainer/portainer-ce:latest
docker.io/portainer/portainer-ce:latest

pi@raspberrypi:~/docker-compose/fhem_2022 $ vi docker-compose.yml

Code Auswählen Erweitern

< snip >
  portainer:
    image: portainer/portainer-ce:latest
    restart: always
##    command: -H unix:///var/run/docker.sock --no-auth
    ports:
        - '9000:9000'
    environment:
      - REGISTRY_HTTP_TLS_CERTIFICATE=/certs/portainer.crt
      - REGISTRY_HTTP_TLS_KEY=/certs/portainer.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
      - ./certs/portainer.key:/certs/portainer.key
      - ./certs/portainer.crt:/certs/portainer.crt
< snip >


Code Auswählen Erweitern

pi@raspberrypi:~/docker-compose/fhem_2022 $ docker-compose up -d
Recreating fhem_2022_portainer_1 ...
fhem_2022_mysql_1 is up-to-date
fhem_2022_vallox_1 is up-to-date
fhem_2022_node-red_1 is up-to-date
fhem_2022_fhem_1 is up-to-date
fhem_2022_grafana_old_1 is up-to-date
Recreating fhem_2022_portainer_1 ... done

VG  Christian

[ch.eick]

Hallo zusammen,
das Jahresende kommt immer näher und es wird Zeit mal wieder aufzuräumen
Vorher immer schön ein Backup machen !!!

Im Wiki habe ich mal bei der MySQL Datenbank etwas eingepflegt.
https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus#Voraussetzungen_FHEM_Umfeld ==> MySQL Kommandos
Der Hintergrung ist, dass die Oracle MySQL Datenbank bezöglich der Sicherheit restriktiver ist. Deshalb habe ich mal versucht die benötigten Privilegien etwas zu bereinigen. Auch eine user "fhemroot" habe ich angelegt, der dann im DbRep Device hinterlegt werden kann, um z.B. eine Datenbank Bereinigung durchzuführen.

Code Auswählen Erweitern

set LogDBRep adminCredentials fhemroot <password>
get LogDBRep storedCredentials
Da wir hier ja auch die Oracle MySQL im docker Container verwenden, konnte ich mich bisher nicht als root per remoute anmelden, was mit dem fhemroot von meinem Hauptrechner über die IP Adresse jetzt geht. Insbesondere sind auch die Privilegien für "ROUTINE" wichtig, da man ansonsten noch nicht einmal die stored procedures sehen kann

In Bezug auf das Aufräumen habe ich dies jedoch gerade erst recht intensiv durchgeführt und ein "OPTIMIZE TABLE history" zum Schluss gemacht. Ihr glaubt ja gar nicht, was sich so alles im laufe der Jahre ansammelt Wegen der Laufzeit möchte ich das nicht sofort nochmal machen, um obigen fhemroot über DbRep zu testen, aber bei den ganzen Shellys habe ich noch einiges zu tun. Danach teste ich den fhemroot auch mal über DbRep.

Meine Datenbank ist bei ca 28 GB auf der SSD angekommen und ich konnte 4 GB bisher zurück gewinnen. Nach dem "OPTIMIZE TABLE history" musste dann noch der Docker Container neu gestartet werden bevor der Platz auf der Festplatte wieder frei gegeben wurde.

VG   Christian

[Pnemenz]

Hallo ch.eick.
Von einem andren Thread kommend finde ich die Erzeugungsprognose mittel KI sehr interessant. Wie ich schon anderswo anmerkte, kann ich mit den Daten des DWD nicht dienen, ich kann aber die Daten der GeoSpereAustria API abfragen.

Welche Parameter sind benötigt und in welcher Form? Über die API bekommt man Ensemble Daten, die aus 16 verschieden Modell Läufen aggregiert werden. Als Werte stehen dann jeweils die 10th percentile, 50th percentile und 90th percentile,  unter Anderem der Globalstrahlung, Tiefst- Höchsttemperatur, Regenmenge, Niederschlag, Schneemenge, Schneefallgrenze, Sonnenscheindauer, 2m Temperatur, Wolkenbedeckung und Windgeschwindigkeit in einer Stündlichen Auflösung zur Verfügung. Diese Daten werden 2x täglich veröffentlicht und umfassen einen Zeitraum von 48 Stunden. (https://data.hub.geosphere.at/dataset/ensemble-v1-1h-2500m)

An einem anderen Endpunkt werden Temperatur, Niederschlag, Wind, Globalstrahlung, relative Feuchte, Gewitterindizes, Bewölkung und Druck alle 3 Stunden für eien Zeitraum von 60 Stunden geliefert. (https://data.hub.geosphere.at/dataset/nwp-v1-1h-2500m)

Welche Daten werden aus der PhV_Anlage benötigt? Ich berechne u.A. die stündlich erzeugte Energiemenge (mittels Statistikmodul am Ende der jeweiligen Stunde).

[ch.eick]

Hallo zusammen und insbesondere Pnemenz (Ich mag auf Dauer richtige Vornamen )

da nun wieder Winter ist nutze ich diesen Beitrag direkt mal wieder zur Erklärung und Dokumentation.

Hallo ch.eick.
Von einem andren Thread kommend finde ich die Erzeugungsprognose mittel KI sehr interessant. Wie ich schon anderswo anmerkte, kann ich mit den Daten des DWD nicht dienen, ich kann aber die Daten der GeoSpereAustria API abfragen.

< snip >

Welche Daten werden aus der PV_Anlage benötigt?
Ich berechne u.A. die stündlich erzeugte Energiemenge (mittels Statistikmodul am Ende der jeweiligen Stunde).

Man mag es kaum glauben, aber das ist der einzige Wert, der von der PV-Anlage benötigt wird.

Um den Support für die Python Prognose einfach zu gestallten wären die Anpassungsarbeiten bitte alle auf der Seite der FHEM Devices zu erledigen.

Hier mal die Namen der verwendeten Devices und die benötigten readings für die KI

Code Auswählen Erweitern

-- Das listet alle in der Datenbank auf, ich habe es hinterher ausgedünnt
mysql >
SELECT DEVICE FROM history
GROUP BY DEVICE;

# DEVICE
'Astro'
'DWD_Forecast'
'WR_1'

-- Hier eine Liste der readings vom DWD_Forecast, die ich auch noch etwas manuell umsortiert und gekürzt habe
-- Die Kürzel am Ende des readings entsprechen dem Deutschen Wetterdienst
##################################################################################
TTT : Temperature 2m above surface [°C]
FF      : Windspeed
Neff : Effective cloud cover [%]
R101 : Probability of precipitation > 0.1 mm during the last hour [%]
RR1c : Probability of precipitation > 0.1 mm during the last hour
R600 : Probability of precipitation > 0.0mm during the last 6 hours [%]
RRs1c : Snow-Rain-Equivalent during the last 3 hours [kg/m2]
Rad1h : Global Irradiance [kJ/m2]
             kJ/m² Umrechnung *0,277778 in kWh/m²
ww : Significant Weather
wwM : Probability for fog within the last hour [%]
##################################################################################

mysql >
SELECT READING FROM history
WHERE DEVICE    = 'DWD_Forecast'
  AND READING   like 'fc0_%'
  AND TIMESTAMP > curdate()
GROUP BY READING
;

# READING
'fc0_0_DD'
'fc0_0_FF'
'fc0_0_N'
'fc0_0_Neff'
'fc0_0_R101'
'fc0_0_Rad1h'
'fc0_0_RR1c'
'fc0_0_RRS1c'
'fc0_0_SunD1'
'fc0_0_TTT'
'fc0_0_VV'

<snip >  1-9

'fc0_10_DD'
'fc0_10_FF'
'fc0_10_N'
'fc0_10_Neff'
'fc0_10_R101'
'fc0_10_Rad1h'
'fc0_10_RR1c'
'fc0_10_RRS1c'
'fc0_10_SunD1'
'fc0_10_TTT'
'fc0_10_VV'

< snip > 11-24

< snip > die fc1_* Werte müssen auch bereits heute erzeugt werden, da die Prognose ja in die Zukunft schaut


-- Hier eine Liste der readings vom Astro, die ich auch noch etwas manuell umsortiert und gekürzt habe
-- Auffällig ist, dass der Sonnenstand nur für die PV-Zeit notwendig ist, also von 6-21 Uhr
mysql >
SELECT TIMESTAMP, READING FROM history
WHERE DEVICE    = 'Astro'
  AND READING   like 'fc%'
  AND TIMESTAMP > '2024-11-21'
 GROUP BY READING, TIMESTAMP
 ORDER BY TIMESTAMP
;

# TIMESTAMP, READING
'2024-11-22 00:00:00', 'fc0_6_SunAlt'
'2024-11-22 00:00:00', 'fc0_6_SunAz'
< snip >
'2024-11-22 00:00:00', 'fc0_9_SunAlt'
'2024-11-22 00:00:00', 'fc0_9_SunAz'
'2024-11-22 00:00:00', 'fc0_10_SunAlt'
'2024-11-22 00:00:00', 'fc0_10_SunAz'
< snip >
'2024-11-22 00:00:00', 'fc0_21_SunAlt'
'2024-11-22 00:00:00', 'fc0_21_SunAz'

< snip > die fc1_* Werte müssen auch bereits heute erzeugt werden, da die Prognose ja in die Zukunft schaut




-- Und nun fehlt noch der yield aus dem Wechselrichter WR_1
-- Hier ist eine Besonderheit, da der Kostal Plenticore ein Hybrid WR mit Speicher ist liefert er auch in der
-- Nacht einen Ertrag, was die MySQL Prozedur durch herausrechnen des Speichers später wieder korrigiert.
-- Für nicht Hybrid WRs sollte es jedoch ohne Änderung auch laufen, da würde ich erst bei entstehen von Problemen
-- die Prozedur verändern.
-- SW_Yield_Daily ist somit ein täglich laufender einfacher Zähler, auch ein "Total" Zähler sollte funktionieren,
-- dann passt jedoch der reading Name nicht, was jedoch kein Beibruch wäre ;-) Das SW_ steht für Schwarm, es ist
-- somit egal, wieviel WRs verwendet werden, solange der Zähler den Ertrag aller WRs beinhaltet. Auch über die
-- Ausrichtungen braucht man sich keinerlei Gedanken zu machen, was ein riesiger Vorteil ist.
-- Die stündlichen Werte werden eigenständig berechnet.

mysql >
SELECT TIMESTAMP, READING FROM history
WHERE DEVICE    = 'WR_1'
  AND READING   = 'SW_Yield_Daily'
  AND TIMESTAMP > '2024-11-21'
;

# TIMESTAMP, READING
'2024-11-22 00:01:04', 'SW_Yield_Daily'
'2024-11-22 07:56:04', 'SW_Yield_Daily'
'2024-11-22 08:01:04', 'SW_Yield_Daily'
'2024-11-22 08:06:08', 'SW_Yield_Daily'
< snip >
'2024-11-22 13:07:04', 'SW_Yield_Daily'
'2024-11-22 13:11:04', 'SW_Yield_Daily'

 

Welche Parameter sind benötigt und in welcher Form? Über die API bekommt man Ensemble Daten, die aus 16 verschieden Modell Läufen aggregiert werden. Als Werte stehen dann jeweils die 10th percentile, 50th percentile und 90th percentile,  unter Anderem der Globalstrahlung, Tiefst- Höchsttemperatur, Regenmenge, Niederschlag, Schneemenge, Schneefallgrenze, Sonnenscheindauer, 2m Temperatur, Wolkenbedeckung und Windgeschwindigkeit in einer Stündlichen Auflösung zur Verfügung.

An einem anderen Endpunkt werden Temperatur, Niederschlag, Wind, Globalstrahlung, relative Feuchte, Gewitterindizes, Bewölkung und Druck alle 3 Stunden für eien Zeitraum von 60 Stunden geliefert. (https://data.hub.geosphere.at/dataset/nwp-v1-1h-2500m)

Um hier nun weiter zu kommen ist es erforderlich die Fremddaten sogut es geht den reading Namen des DWD_Forecast Devices zuzuordnen. Erleuterungen habe ich oben bereits eingefügt.

Diese Daten werden 2x täglich veröffentlicht und umfassen einen Zeitraum von 48 Stunden. (https://data.hub.geosphere.at/dataset/ensemble-v1-1h-2500m)

Somit würde es reichen die Prognose zweimal täglich nach dem Loggen der Daten zu starten.

Beispiele für die Manipulation von reading Namen findest Du in den Devices im contrib zum Download.

- Das Astro Device kannst Du genau so verwenden, wie es da geliefert wird.
- Anstatt des WR_1 verwendest Du Dein Device und machst einen rename auf WR_1 .
- Das reading mit dem SW_Yield_Daily muss leider ebenfalls genau so heißen, was Du eventuell über ein
  userreadings zusätzlich erzeugen könntest, aber nicht das Loggen vergessen.
- Das DWD_Forecast muss dann nachgebaut werden, dazu hast Du ja bereits infos bekommen, oder schau Dir die Muster an.

- Als Datenbank verwendest Du am Besten den Oracle MySQL Docker Container, da Du sonst ziemlich
  schnell an irgend welche Grenzen kommst. Die Datenbank kann auch auf einem anderen Rechner im Hausnetz laufen.
  Ein docker-compose.yml ist im contrib zufinden. Die Notwendige Konfiguration ist gerade erst überarbeitet im Wiki.

- Im Wiki sind auch Beschreibungen zu jedem einzelnen Device zu finden.



Hier wäre nun mal ein Zwischenergebnis, dass dann in die KI Prognose rein geht.

Code Auswählen Erweitern

-- Hier eine Liste der dwdfull Tabelle, die nach dem Lauf der MySQL Prozedur entsteht
-- Auch hier werden nur Zeiten von 6-21 Uhr erstellt
-- Die Wetter- sind den Astro-Daten und den Erzeugungswerten (yield) vom WR zugeordnet
-- Durch das Python Skript kommen dann noch die yield_max und die forecast Werte dazu
-- Die gesamte Tabelle beinhaltet auch noch historische Daten von Vergleichszeiträumen, die hier rausgeschnitten wurden

mysql >
SELECT * FROM dwdfull
ORDER BY TIMESTAMP desc
LIMIT 32;

# TIMESTAMP, year, month, day, hour, TTT, DD, VV, N, Neff, R101, RRS1c, SunD1, Rad1h, SunAz, SunAlt, yield, yield_max, forecast
'2024-11-23 21:00:00', '2024', '11', '23', '21', '1.1', '205', '9500', '99', '86', '3', '0', '0', '0', '289.7', '-42', '0', '0', '0'
'2024-11-23 20:00:00', '2024', '11', '23', '20', '1.2', '189', '9500', '99', '90', '6', '0', '0', '0', '276.6', '-32.6', '0', '0', '0'
'2024-11-23 19:00:00', '2024', '11', '23', '19', '1.1', '159', '11500', '100', '91', '3', '0', '0', '0', '265', '-23', '0', '0', '0'
'2024-11-23 18:00:00', '2024', '11', '23', '18', '1.8', '155', '11500', '100', '94', '5', '0', '0', '0', '254.1', '-13.5', '0', '77', '0'
'2024-11-23 17:00:00', '2024', '11', '23', '17', '2.3', '167', '14900', '100', '94', '6', '0', '60', '20', '243.2', '-4.5', '0', '166', '0'
'2024-11-23 16:00:00', '2024', '11', '23', '16', '2.3', '185', '16500', '100', '94', '2', '0', '300', '110', '231.7', '4.1', '0', '1724', '52'
'2024-11-23 15:00:00', '2024', '11', '23', '15', '2.6', '204', '16600', '100', '93', '3', '0', '420', '240', '219.4', '10.9', '0', '4538', '308'
'2024-11-23 14:00:00', '2024', '11', '23', '14', '2.7', '213', '16900', '100', '89', '2', '0', '540', '350', '206', '15.8', '0', '6064', '797'
'2024-11-23 13:00:00', '2024', '11', '23', '13', '2.5', '219', '16500', '100', '90', '4', '0', '480', '380', '191.7', '18.9', '0', '7184', '1184'
'2024-11-23 12:00:00', '2024', '11', '23', '12', '2.1', '220', '15700', '99', '88', '4', '0', '480', '350', '176.8', '19.6', '0', '8036', '1480'
'2024-11-23 11:00:00', '2024', '11', '23', '11', '1.6', '222', '14800', '99', '88', '3', '0', '420', '260', '162.1', '17.9', '0', '7711', '1682'
'2024-11-23 10:00:00', '2024', '11', '23', '10', '1.2', '223', '15100', '100', '88', '3', '0', '360', '150', '148.1', '14.2', '0', '6029', '1614'
'2024-11-23 09:00:00', '2024', '11', '23', '9', '1', '221', '15800', '99', '88', '2', '0', '240', '30', '135.2', '8.3', '0', '4313', '1121'
'2024-11-23 08:00:00', '2024', '11', '23', '8', '1.1', '220', '16500', '99', '87', '2', '0', '0', '0', '123.3', '0.8', '0', '2425', '373'
'2024-11-23 07:00:00', '2024', '11', '23', '7', '1.1', '221', '17200', '99', '86', '2', '0', '0', '0', '112.1', '-8.1', '0', '0', '0'
'2024-11-23 06:00:00', '2024', '11', '23', '6', '1.2', '222', '16800', '98', '86', '1', '0', '0', '0', '101.2', '-17.4', '0', '0', '0'
'2024-11-22 21:00:00', '2024', '11', '22', '21', '0.6', '235', '20600', '94', '88', '31', '0.1', '0', '0', '290', '-41.9', '0', '0', '0'
'2024-11-22 20:00:00', '2024', '11', '22', '20', '0.3', '234', '20600', '97', '90', '29', '0.1', '0', '0', '276.8', '-32.5', '0', '0', '0'
'2024-11-22 19:00:00', '2024', '11', '22', '19', '-0.1', '233', '21500', '100', '92', '28', '0.1', '0', '0', '265.2', '-22.9', '0', '0', '0'
'2024-11-22 18:00:00', '2024', '11', '22', '18', '-0.1', '230', '21500', '98', '89', '23', '0', '0', '0', '254.3', '-13.4', '0', '77', '0'
'2024-11-22 17:00:00', '2024', '11', '22', '17', '0.2', '232', '22000', '95', '88', '18', '0', '180', '30', '243.4', '-4.4', '0', '166', '0'
'2024-11-22 16:00:00', '2024', '11', '22', '16', '0.1', '233', '23000', '88', '85', '16', '0', '420', '160', '231.9', '4.2', '0', '1724', '52'
'2024-11-22 15:00:00', '2024', '11', '22', '15', '0.1', '234', '19900', '85', '82', '11', '0', '600', '310', '219.6', '11.1', '0', '4538', '346'
'2024-11-22 14:00:00', '2024', '11', '22', '14', '0', '236', '20900', '80', '79', '5', '0', '660', '440', '206.2', '16', '0', '6064', '814'
'2024-11-22 13:00:00', '2024', '11', '22', '13', '-0.2', '234', '23900', '78', '78', '3', '0', '840', '510', '191.8', '19.1', '0', '7184', '1213'
'2024-11-22 12:00:00', '2024', '11', '22', '12', '-0.6', '234', '23600', '73', '73', '3', '0', '900', '500', '176.9', '19.8', '232', '8036', '1736'
'2024-11-22 11:00:00', '2024', '11', '22', '11', '-1', '234', '25900', '70', '70', '5', '0', '1020', '400', '162.1', '18.1', '3665', '7711', '2104'
'2024-11-22 10:00:00', '2024', '11', '22', '10', '-1.3', '235', '25100', '64', '64', '9', '0', '960', '260', '148.1', '14.4', '3129', '6029', '2281'
'2024-11-22 09:00:00', '2024', '11', '22', '9', '-1.8', '234', '27300', '57', '57', '6', '0', '720', '50', '135.2', '8.5', '1650', '4313', '1851'
'2024-11-22 08:00:00', '2024', '11', '22', '8', '-2.3', '234', '25700', '52', '52', '3', '0', '0', '0', '123.2', '1', '628', '2425', '677'
'2024-11-22 07:00:00', '2024', '11', '22', '7', '-2.6', '236', '24900', '49', '49', '2', '0', '0', '0', '112', '-7.9', '0', '0', '0'
'2024-11-22 06:00:00', '2024', '11', '22', '6', '-2.8', '236', '28400', '46', '46', '2', '0', '0', '0', '101.1', '-17.2', '0', '0', '0'

VG   Christian

[ch.eick]

Hallo zusammen,
im Hintergrund wird gerade an einer Auswertung gearbeitet, wie man die Ersparnis beim Laden des Speichers über einen z.B. Tibber Tarif als Report berechnen kann.

Bisher habe ich erstmal einen festen Preis gesetzt, da wenig Zeit gewesen ist, aber die fc0_*_total sind ja bereits in der DB.

Code Auswählen Erweitern

SET @date     :='2024-11-30',
    @device   :='WR_1',
    @reading  :='Battery_Total_AC_ChargeEnergy_gridToBattery',
    @EVU_cost := 0.30;

In meiner Datenbank sind natürlich alle kWh im 0.* Bereich, da ich nicht aus dem Netz, mangels Tibber, lade.
Die Nummerierung in der ersten Spalte zeigt durchgängige Ladevorgänge an, wobei in diesem Beispiel alles innerhalb einer Stunde zusammen gerechnet wurde und es keine Pause > 1h innerhalb eines Ladevorganges geben darf.
Wie man daraus ableiten kann ist das Reporting aus der Abrechnung meines zweiten WB Ladepunktes, den der Mieter verwendet.

Code Auswählen Erweitern

# Ladevorgang    TIMESTAMP    kWh    Cost
1    2024-12-01 15:00:00    0.33    0.0998
2    2024-12-03 11:00:00    0.02    0.0057
2    2024-12-03 12:00:00    0.02    0.0056
3    2024-12-04 08:00:00    0.01    0.0039
3    2024-12-04 09:00:00    0.42    0.1257
3    2024-12-04 10:00:00    0.02    0.0071
3    2024-12-04 11:00:00    0.37    0.1103
3    2024-12-04 12:00:00    0.01    0.0035
4    2024-12-05 08:00:00    0.04    0.0129
5    2024-12-05 11:00:00    0.01    0.0016
6    2024-12-06 09:00:00    0.01    0.0018
6    2024-12-06 10:00:00    0.00    0.0004
6    2024-12-06 11:00:00    0.01    0.0037
6    2024-12-06 12:00:00    0.56    0.1674
6    2024-12-06 13:00:00    0.33    0.0999
6    2024-12-06 14:00:00    0.37    0.1112
7    2024-12-07 14:00:00    0.32    0.0960
8    2024-12-08 10:00:00    0.06    0.0188
8    2024-12-08 12:00:00    0.10    0.0292
8    2024-12-08 13:00:00    0.80    0.2388
8    2024-12-08 14:00:00    0.01    0.0018
9    2024-12-09 13:00:00    0.48    0.1427
9    2024-12-09 14:00:00    0.01    0.0044
10    2024-12-10 09:00:00    0.66    0.1979
10    2024-12-10 10:00:00    0.10    0.0295
11    2024-12-11 13:00:00    0.01    0.0037
12    2024-12-12 10:00:00    0.00    0.0000
13    2024-12-15 10:00:00    0.03    0.0078
13    2024-12-15 11:00:00    0.04    0.0128
14    2024-12-16 10:00:00    0.21    0.0629
14    2024-12-16 11:00:00    0.05    0.0155
15    2024-12-17 10:00:00    0.00    0.0002
15    2024-12-17 11:00:00    0.15    0.0457
16    2024-12-18 09:00:00    0.01    0.0018
16    2024-12-18 10:00:00    0.27    0.0816
16    2024-12-18 12:00:00    0.58    0.1730
16    2024-12-18 13:00:00    0.65    0.1963
17    2024-12-19 09:00:00    0.01    0.0018
17    2024-12-19 10:00:00    0.03    0.0077
17    2024-12-19 12:00:00    0.02    0.0046
18    2024-12-20 09:00:00    0.06    0.0181
18    2024-12-20 10:00:00    0.08    0.0227
18    2024-12-20 12:00:00    0.65    0.1940
18    2024-12-20 13:00:00    0.81    0.2430
18    2024-12-20 14:00:00    0.42    0.1273
18    2024-12-20 15:00:00    0.01    0.0039
19    2024-12-21 12:00:00    0.15    0.0462
19    2024-12-21 13:00:00    0.03    0.0085
20    2024-12-22 09:00:00    0.07    0.0224
20    2024-12-22 10:00:00    0.01    0.0037
21    2024-12-22 14:00:00    0.00    0.0004
22    2024-12-23 10:00:00    0.00    0.0007
22    2024-12-23 11:00:00    0.22    0.0646
22    2024-12-23 12:00:00    0.24    0.0722
22    2024-12-23 13:00:00    0.11    0.0318
22    2024-12-23 14:00:00    0.66    0.1965

Falls bereits jemand eine Lösung oder Idee hat kann er sich ja gerne mal melden.

VG  Christian

[ch.eick]

Hallo zusammen,
und auch in diesem Jahr gibt es mal ein Lebenszeichen, damit niemand denkt der Thread wäre tot.

Es gibt einige wenige, die bereits die PV mit Tibber kombiniert haben und auch ich mache meine Rückschlüsse, ob es sich lohnen würde.
Die Neuheit im Leistungsbezug Diagramm ist, dass
- der Tibber Preis als Schema mit angezeigt wird und
- das der Trigger nun noch das nächste Fenster darstellt, wenn es an diesem Tag noch eins gibt.
Du darfst diesen Dateianhang nicht ansehen.

VG  Christian

[Girgl]

Hallo Gemeinde,
bin seit kurzem PV-Betreiber und möchte diese in FHEM integrieren. Kostal Plenticore 10, KSEM, BYD HVS Batterie.
Ich kämpfe mich gerade durch die Wiki-Seite und bin begeistert was alles möglich ist. Sämtliche Anleitungen habe 1 zu 1 befolgt und erfolgreich umsetzen können, bis auf die KI-Integration. Mittlerweile habe ich die Prozedur 'dwd_load' in die Datenbank eingefügt und kann den Testlauf ausführen. Die Tabelle füllt sich mit den Daten. Aber nicht mit dem im Wiki angegebenen SQL-Befehl:

Code Auswählen Erweitern

call dwd_load(curdate(),'none');Mysql moniert zurecht, dass ein dritter Parameter fehlt. Im Post #961 vom 19 März 2024, 12:29:17 ist erklärt, dass die Prozedur geändert und Verbesserungen vorgenommen wurden, damit nicht immer die gesamte Tabelle neu erstellt wird.
Jetzt hänge ich beim nächsten Schritt im Wiki:

Code Auswählen Erweitern

RAW Definition LogDBRep_PV_KI_Prognose (Teil 1)

Achtung, bei diesem Device kommt im weiteren Fortschritt noch ein weiteres Attribut zum Aufruf des Python KI Prognose Skriptes hinzu. Im Kommentar wird dies bereits im Syntax erwähnt.

defmod LogDBRep_PV_KI_Prognose DbRep LogDB
attr LogDBRep_PV_KI_Prognose DbLogExclude .*
attr LogDBRep_PV_KI_Prognose allowDeletion 0
attr LogDBRep_PV_KI_Prognose comment Version 2023.02.23 12:00\
\
Hier wird die Vorbereitung für die KI PV-Leistungsprognose durchgeführt\
\
sqlCmd call dwd_load(curdate(),'none');;\
[none|show] zum Anzeigen des Ergebnisses\
\
executeAfterProc:\
<absoluter Skript Name> <DbLog IP-Adresse> <FHEM IP-Adresse> <DbRep Name> <Wechselricher Name> <Prefix Reading Name>
attr LogDBRep_PV_KI_Prognose executeAfterProc "/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.XXX 192.168.178.YYY LogDBRep_PV_KI_Prognose WR_1 Solar_yield_fc"
attr LogDBRep_PV_KI_Prognose room System
attr LogDBRep_PV_KI_Prognose verbose 3

Auch hier sollte nun getestet werden, indem man beim set das sqlCmd ausführt. Der MySQL Procedur Aufruf ist ebenfalls im Kommentar zu finden.

Als Ergebnis sollte soetwas zurück kommen. Nachdem das erschienen ist kann man den obigen Test mit dem SELECT der dwdfull Tabelle nochmals wiederholen.

SqlResultRow_1 NOW()
SqlResultRow_2 2023-03-17 11:01:03
sqlCmd call dwd_load(curdate(),'none');
sqlResultNumRows 1
Das sqlCmd müsste doch anders lauten, um die Prozedur richtig aufrufen zu können.

Code Auswählen Erweitern

call dwd_load('full',curdate(),'none');
call dwd_load('update',curdate(),'none');
call dwd_load('update_yield_only',curdate(),'none');
Ich konnte in den Posts leider keinen Hinweis finden, aber vieleicht weis jemand Rat.
Besten Dank und viele Grüße
Girgl

[tobi01001]

Bei dieser Problemstellung kann ich dir nicht direkt helfen, aber vielleicht wäre ja auch Solarforecast was für dich?

[ch.eick]

< snip >
Das sqlCmd müsste doch anders lauten, um die Prozedur richtig aufrufen zu können.

Code Auswählen Erweitern

call dwd_load('full',curdate(),'none');
call dwd_load('update',curdate(),'none');
call dwd_load('update_yield_only',curdate(),'none');

Hallo Girgl,
herzlich willkommen.

Ich finde es Toll, wie weit Du Dich vorgekämpft hast und das ohne Geräusche zu machen
Du hast vollkommen recht mit Deinen dwd_load() aufrufen, ich komme einfach nicht dazu das Wiki mal wieder aufzuräumen

Das Scheduling wird aus dem WR_ctl Device heraus, mit diesem Block, durchgeführt:

Code Auswählen Erweitern

################################################################################################################
## 2 Start der KI Prognose
## Der Reading Name und das Device werden in LogDBRep_PV_KI_Prognose im executeAfterProc eingestellt
##  "/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.40 192.168.178.40 LogDBRep_PV_KI_Prognose WR_1_ctl Yield_fc"
##
2_KI_Prognose
{if( !([$SELF:state] eq "off")                                           ## DOIF enabled
    and
     (
      ReadingsVal("LogDBRep_PV_KI_Prognose","PV_KI_Prognose","null") eq "done"  ## Die Prognose darf nicht gerade laufen !!!
      or
      ReadingsVal("LogDBRep_PV_KI_Prognose","state","null") eq "initialized"
     )
    and
  (
    ([05:00-22:00] and [:05]                                             ## In der PV-Zeit jede Stunde aktualisieren
    )
    or [$SELF:ui_command_1] eq "2_KI_Prognose"                           ## Hier wird das uiTable select ausgewertet
  )
   ) {

  if ($hour == 5) {
    ::CommandSet(undef, "LogDBRep_PV_KI_Prognose sqlCmd call dwd_load_new('full',curdate(),'none')");
  } else {
    ::CommandSet(undef, "LogDBRep_PV_KI_Prognose sqlCmd call dwd_load_new('update',curdate(),'none')");
  }

  if (AttrVal("$SELF","verbose",0) >=3) {
      Log 3, "$SELF 2_KI_Prognose : Start KI Prognose";
    }

    set_Reading("ui_command_1","---");                                   ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten
                                                                         ## kann das Kommando nicht sofort wiederholt werden
  }
}

EDIT: Ich habe das DbRep nochmal im contrib aktualisiert

[ch.eick]

Bei dieser Problemstellung kann ich dir nicht direkt helfen, aber vielleicht wäre ja auch Solarforecast was für dich?

Das hängt davon ab, ob man sich für die MySQL Datenbank Unterstützung, oder das Solarforecast Modul entschieden hat.
Für mich ist im Solarforcast leider zuviel vermischt worden und ich möchte lieber den Forecast separat vom Energiemanagement halten.

Aber jeder wie er mag
VG   Christian

[tobi01001]

Bei dieser Problemstellung kann ich dir nicht direkt helfen, aber vielleicht wäre ja auch Solarforecast was für dich?

Das hängt davon ab, ob man sich für die MySQL Datenbank Unterstützung, oder das Solarforecast Modul entschieden hat.
Für mich ist im Solarforcast leider zuviel vermischt worden und ich möchte lieber den Forecast separat vom Energiemanagement halten.

Aber jeder wie er mag
VG  Christian

Da ist was dran... Ich nutze Solarforecast eigentlich "nur" für PV-Prognose und die Information ob ich Überschuss zur Verfügung habe. Energiemanagement in Verbidnung mit Tibber mache ich für die meisten separat.


Da muss ich mich wohl mal hier durch den Thread / Wiki lesen. Vielleicht ergibt sich da noch ezwas potential.

[Girgl]

ah ok. Die Erklärung im Wiki hatte ich leichtsinniger Weise nur überflogen.
Jetzt scheitere ich nur noch daran die python-scripts aus dem svn zu laden. Mit dem FHEM-Befehl

Code Auswählen Erweitern

{ Svn_GetFile('contrib/ch.eick/', 'contrib/ch.eick/') }
bzw.
{ Svn_GetFile('/fhem/trunk/fhem/contrib/ch.eick/', 'contrib/ch.eick/') }
erhalte ich in beiden Fällen
2025.03.14 14:49:18 1: ERROR Svn_GetFile contrib/ch.eick/: read from https://svn.fhem.de:443 timed out
Was mache ich falsch? Hast Du dafür noch einen Tip für mich?

[ch.eick]

Da ist was dran... Ich nutze Solarforecast eigentlich "nur" für PV-Prognose und die Information ob ich Überschuss zur Verfügung habe. Energiemanagement in Verbidnung mit Tibber mache ich für die meisten separat.

Da muss ich mich wohl mal hier durch den Thread / Wiki lesen. Vielleicht ergibt sich da noch ezwas potential.

Wichtig ist halt, dass die Daten in der MySQL Datenbank sind und es sollte eine vollwertige Datenbank sein
Um es hier einfacher zu haben sind die Namensstandards halt auch wichtig, da durch die MySQL Prozedur die Daten aufbereitet werden und man ansonsten zuviel anpassen müsste. Wenn die dwd_full Tabelle dann passt, macht das Python Skript mit der KI die Leistungsprognose, ohne irgendwelches Wissen über die PV-Hardware oder Ausrichtung, das hat für mich einen sehr großen Charm.

[ch.eick]

ah ok. Die Erklärung im Wiki hatte ich leichtsinniger Weise nur überflogen.
Jetzt scheitere ich nur noch daran die python-scripts aus dem svn zu laden. Mit dem FHEM-Befehl

Code Auswählen Erweitern

{ Svn_GetFile('contrib/ch.eick/', 'contrib/ch.eick/') }
bzw.
{ Svn_GetFile('/fhem/trunk/fhem/contrib/ch.eick/', 'contrib/ch.eick/') }
erhalte ich in beiden Fällen
2025.03.14 14:49:18 1: ERROR Svn_GetFile contrib/ch.eick/: read from https://svn.fhem.de:443 timed out
Was mache ich falsch? Hast Du dafür noch einen Tip für mich?

Puh, das habe ich mir auch nur zusammen Kopiert

Im Browser kommst Du mit diesem Link ans contrb https://svn.fhem.de/fhem/trunk/fhem/contrib/ch.eick/ , aber Achtung, kein copy/paste, da sind schon viele Merkwürdigkeiten passiert. Besser ist ein Download.