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