76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

Max_Meyer

Zitat von: Parallix am 23 Juni 2025, 09:40:31Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?

Hallo Parallix
schau mal hier - ist vom Frauenhofer - da gibt es viel - vielleicht passt dir was davon
https://www.energy-charts.info/index.html?l=de&c=DE
Das meiste ist über API verfügbar - ich hab bisschen mit der Stromampel rumgespielt
Gruß Gerd

ch.eick

Zitat von: Parallix am 23 Juni 2025, 09:40:31Mal was ganz anderes: Künftig wird es wohl immer mehr Anlagen geben, die dynamisch abgeregelt werden können. In der Konsequenz bedeutet das, dass die Leistung, die lokal nicht genutzt wird und daher in das öffentliche Netz eingespeist werden kann (vereinfachend meist PV-Überschuss genannt), nur noch prognostiziert, aber nicht mehr gemessen werden kann.

Insofern wird es zunehmend extrem wichtig sein, sehr gute Prognosedaten zu haben. Hierfür wird es mittelfristig erforderlich sein, das Zeitfenster und die Stärke einer vorgesehenen Abregelung im Vorfeld zu kennen, um diese vorausschauend in SF berücksichtigen zu können. Gibt es hierfür öffentlich zugängige Datenbanken und APIs, die von uns genutzt werden können?
Ich denke, gerade im Sommer, wo es die Abregelung geben wird, sind doch unsere Prognosen bereits ziemlich gut, da habe selbst ich mit meinem vereinfachten Ansatz sehr gute Ergebnisse. Daraus bekomme ich ein ziemlich gutes Zeitfenster für das Mittagshoch.
Ich würde nun nicht die Prognose auf biegen und brechen noch besser machen, sondern eher die Zeiten mit der Abregelung hinzuziehen. Wenn man dort einen Block in der Mitte nimmt, wird sicherlich der Solarhügel getroffen werden :-)

Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.

Über Tibber habe ich mir dann auch noch die höchsten Preise als Zeitfenster berechnet, was entsprechend die beste Zeit für das Einspeisen aus dem Speicher wäre. Leider wird ja diese Unterstützung des Netzes nicht finanziel gefördert, weshalb wohl niemand seinen Speicher dafür hergeben wird.

My5cent
    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

Max_Meyer

Zitat von: ch.eick am 23 Juni 2025, 15:36:27Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.
Hallo Christian,
Ich glaube im Prinzip hast du Recht - zumindest kurzfristig - der Nachteil der Lösung über den Preis ist, das wir nur eine Preiszone haben, daher ist der Preis von der Nordsee bis zum Bodensee identisch - obwohl die regionale Energiesituation unterschiedlich ist - sollten unsere ÜNB wirklich mal mit der Digitalisierung voran kommen könnte es regionale Signale geben d.h. - Smartmeter vorausgesetzt - Anlagen werden regional abgeregelt - aus meinem, bisher sehr oberflächlichen Verständnis setzt da die Stromampel - post vorher - an. Dort habe ich den Netz-Mix bezogen auf meine PLZ. Sollte sich das bestätigen ist das Signal auf die Dauer genauer als der Preis - aus meiner Sicht zumindest.
Heute arbeite ich aber auch mit dem Preis
Gruß Gerd


ch.eick

Zitat von: Max_Meyer am 23 Juni 2025, 16:04:53
Zitat von: ch.eick am 23 Juni 2025, 15:36:27Am Beispiel von gestern lag mein Mittagshoch von 12-16 Uhr, was bei Tibber ebenfalls die Stunden mit den niedrigsten Preisen waren. Ich habe da jetzt zwar noch nicht die negativen Preise an der Börse dargestellt, jedoch sollten die mit dem Tibber auf und ab ja deckungsgleich sein.
Hallo Christian,
Ich glaube im Prinzip hast du Recht - zumindest kurzfristig - der Nachteil der Lösung über den Preis ist, das wir nur eine Preiszone haben, daher ist der Preis von der Nordsee bis zum Bodensee identisch - obwohl die regionale Energiesituation unterschiedlich ist - sollten unsere ÜNB wirklich mal mit der Digitalisierung voran kommen könnte es regionale Signale geben d.h. - Smartmeter vorausgesetzt - Anlagen werden regional abgeregelt - aus meinem, bisher sehr oberflächlichen Verständnis setzt da die Stromampel - post vorher - an. Dort habe ich den Netz-Mix bezogen auf meine PLZ. Sollte sich das bestätigen ist das Signal auf die Dauer genauer als der Preis - aus meiner Sicht zumindest.
Heute arbeite ich aber auch mit dem Preis
Gruß Gerd
Ich arbeite mit dem was jetzt und kostenlos verfügbar ist, der Rest wird sicherlich irgendwann kommen :-) :-)
Um meinen Ansatz generischer zu gestallten müsste ich mal auf den Börsenpreis als Quelle umstellen.
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

Kurze Zwischenfrage,
hat bereits jemand die Abfrage der EPEX Spot Preise direkt von der Quelle, also ohne Drittanbieter Web Seiten dazwischen für FHEM umgesetzt?
Ich hatte im Wiki ja mal https://wiki.fhem.de/wiki/Stromb%C3%B6rse begonnen, jedoch hat bisher niemand etwas ergänzt :-(
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

Max_Meyer

Zitat von: ch.eick am 23 Juni 2025, 16:33:59hat bereits jemand die Abfrage der EPEX Spot Preise direkt von der Quelle, also ohne Drittanbieter Web Seiten dazwischen für FHEM umgesetzt?
Ich hatte im Wiki ja mal https://wiki.fhem.de/wiki/Stromb%C3%B6rse begonnen, jedoch hat bish
Hallo Christian,
rudimentär - ich hab das folgende HTTPMOD gemacht - aber bisher nicht weiter verwendet oder geprüft
defmod netprice_1 HTTPMOD https://api.energy-charts.info/price?bzn=DE-LU 3600
attr netprice_1 userattr
attr netprice_1 disable 0
attr netprice_1 extractAllJSON 1
attr netprice_1 group price
attr netprice_1 room XX_Kategorie->HTTPMOD
attr netprice_1 showBody 0
attr netprice_1 userReadings 000_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_0",0) ) ) ."/". ReadingsNum($name,"price_0",0)."". ReadingsVal($name,"unit","0")  },\
001_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_1",0) ) ) ."/". ReadingsNum($name,"price_1",0)."". ReadingsVal($name,"unit","0")  },\
002_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_2",0) ) ) ."/". ReadingsNum($name,"price_2",0)."". ReadingsVal($name,"unit","0")  },\
003_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_3",0) ) ) ."/". ReadingsNum($name,"price_3",0)."". ReadingsVal($name,"unit","0")  },\
004_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_4",0) ) ) ."/". ReadingsNum($name,"price_4",0)."". ReadingsVal($name,"unit","0")  },\
005_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_5",0) ) ) ."/". ReadingsNum($name,"price_5",0)."". ReadingsVal($name,"unit","0")  },\
006_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_6",0) ) ) ."/". ReadingsNum($name,"price_6",0)."". ReadingsVal($name,"unit","0")  },\
007_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_7",0) ) ) ."/". ReadingsNum($name,"price_7",0)."". ReadingsVal($name,"unit","0")  },\
008_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_8",0) ) ) ."/". ReadingsNum($name,"price_8",0)."". ReadingsVal($name,"unit","0")  },\
009_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_9",0) ) ) ."/". ReadingsNum($name,"price_9",0)."". ReadingsVal($name,"unit","0")  },\
010_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_10",0) ) ) ."/". ReadingsNum($name,"price_10",0)."". ReadingsVal($name,"unit","0")  },\
011_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_11",0) ) ) ."/". ReadingsNum($name,"price_11",0)."". ReadingsVal($name,"unit","0")  },\
012_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_12",0) ) ) ."/". ReadingsNum($name,"price_12",0)."". ReadingsVal($name,"unit","0")  },\
013_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_13",0) ) ) ."/". ReadingsNum($name,"price_13",0)."". ReadingsVal($name,"unit","0")  },\
014_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_14",0) ) ) ."/". ReadingsNum($name,"price_14",0)."". ReadingsVal($name,"unit","0")  },\
015_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_15",0) ) ) ."/". ReadingsNum($name,"price_15",0)."". ReadingsVal($name,"unit","0")  },\
016_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_16",0) ) ) ."/". ReadingsNum($name,"price_16",0)."". ReadingsVal($name,"unit","0")  },\
017_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_17",0) ) ) ."/". ReadingsNum($name,"price_17",0)."". ReadingsVal($name,"unit","0")  },\
018_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_18",0) ) ) ."/". ReadingsNum($name,"price_18",0)."". ReadingsVal($name,"unit","0")  },\
019_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_19",0) ) ) ."/". ReadingsNum($name,"price_19",0)."". ReadingsVal($name,"unit","0")  },\
020_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_20",0) ) ) ."/". ReadingsNum($name,"price_20",0)."". ReadingsVal($name,"unit","0")  },\
021_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_21",0) ) ) ."/". ReadingsNum($name,"price_21",0)."". ReadingsVal($name,"unit","0")  },\
022_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_22",0) ) ) ."/". ReadingsNum($name,"price_22",0)."". ReadingsVal($name,"unit","0")  },\
023_hour {strftime("%H",gmtime(ReadingsNum($name,"unix_seconds_23",0) ) ) ."/". ReadingsNum($name,"price_23",0)."". ReadingsVal($name,"unit","0")  }\
Gruß Gerd
PS.: ggfls ist das off Topic und wir sollten woanders weiter diskutieren?

DS_Starter

#3262
ZitatAktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe.
Ich habe eine Weile gesucht um die Ursache zu finden. In der Stunde des Sonnenuntergangs hatte ich vergessen nur anteilig zu rechnen.

Die Version 1.52.18 ist eingecheckt. In dieser Version gibt es auch ein weiteres Special Reading:

conForecastComingNight    
Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.

LG,
Heiko
Proxmox+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

Parallix

#3263
Zitat von: DS_Starter am 23 Juni 2025, 22:39:16
ZitatAktuell (8:11) erhalte ich für <special_remainingSurplsHrsMinPwrBat_XX> einen höheren Wert (13.82) als für <special_SunHours_Remain> (13.62), was meiner Ansicht nach nicht stimmen kann, da <SunSet> in SF mit 21:49 angegeben wird und da sicher keinen nennenswerten solaren Ertrag, wohl aber einen höheren Verbrauch habe.
Ich habe eine Weile gesucht um die Ursache zu finden. In der Stunde des Sonnenuntergangs hatte ich vergessen nur anteilig zu rechnen.

Danke für Dein Feedback und das Update! Super!

Zitat von: DS_Starter am 23 Juni 2025, 22:39:16Die Version 1.52.18 ist eingecheckt. In dieser Version gibt es auch ein weiteres Special Reading:

conForecastComingNight   
Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.

Ganz große Klasse!

@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.

PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

300P

Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.

Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D  ;)  O:-)
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

DS_Starter

#3265
Zitat... für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht.
Die Abregelung der Anlage ist ein generelles Problem im Hinblick auf die Auswertung von Prognose und realer Erzeugung bzw. davon abgeleitete Korrekturfaktoren, KI-Trainings, Überschußprognosen und was alles sonst noch davon abhängig ist.
Für das Modul ist im Fall einer Abregelung die realer Erzeugung einfach nicht vorhanden und führt zu einem entsprechenden Gap zwischen Prognose und Ertrag und in der Folge zu tendenziell falschen Korrekturen. In gewisser Weise ist durch den verwendeten Median eine Resilienz im Modul eingebaut, dennoch ist es auf Dauer ein Problem für die Prognose.

Eine Variante wäre die Datensätze vom Learning auszuschließen sofern eine Abregelung der Anlage erfolgt, was wiederum thematisiert, dass:

1. SF in geeigneter Weise über eine aktive Abregelung der Anlage informiert werden muß
2. wenn die Anlage zu häufig/zu regelmäßig abgeregelt wird, eine durchgängige und zügig arbeitende Anpassung
   der Korrekturen vermutlich nicht mehr realisiert wird

Nach meiner aktuellen Einschätzung werde ich vermutlich über den Einbau von Punkt 1) nicht drumherum kommen falls uns nicht etwas besseres einfällt.

LG,
Heiko

 
Proxmox+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

Parallix

Zitat von: 300P am 24 Juni 2025, 10:37:36
Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.

Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D  ;)  O:-)

Der Gesundheit wegen hatte ich deshalb auf diese Angelegenheit hingewiesen. Persönlich bin ich froh, dass ich die maximale Ladeleistung auch im Fall "Notladung"  limitieren kann und nicht der Strategie des Herstellers ausgeliefert bin.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

Parallix

Zitat von: DS_Starter am 24 Juni 2025, 11:46:31...
Eine Variante wäre die Datensätze vom Learning auszuschließen sofern eine Abregelung der Anlage erfolgt ...

Auch wenn man klassisch (also ohne KI) herangeht muss das Vorliegen des Sonderfalls "Abregelung" bekannt sein. Wenn dann für die Zeit der Abregelung eine gute Schätzung für die solar einbringbare Energie vorliegt, kann man diese regelungstechnisch als Ersatzwerte für die zu einem Zeitpunkt nicht messbaren aber möglichen Ertragswerte ansetzen. Alles nicht trivial, aber sicher auch kein Mega-Showstopper.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

ZitatWenn dann für die Zeit der Abregelung eine gute Schätzung für die solar einbringbare Energie vorliegt, kann man diese regelungstechnisch als Ersatzwerte für die zu einem Zeitpunkt nicht messbaren aber möglichen Ertragswerte ansetzen.
Das wäre im Prinzip identisch den Ertragswert = Prognosewert zu setzen, falls der Abregelungsstatus vorliegt. Kann man machen. SF muß in jedem Fall über den Abregelungsstatus informiert werden. Tritt dieser Status auch nur zu einem gewissen Teil einer Stunde (z.b. 20 Minuten) ein, wäre der Datensatz dieser Stunde als komprimitiert und als entspechend zu behandeln vorzusehen. 
Proxmox+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: Parallix am 24 Juni 2025, 13:01:06
Zitat von: 300P am 24 Juni 2025, 10:37:36
Zitat von: Parallix am 24 Juni 2025, 09:20:20PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.

Das mag für deinen und evtl. andere WR ja so sein - bei mir wird immer so oder so geladen wenn es (seitens des BWR/BMS wird übersteuert) für die "Gesundheit" der Batterie auch notwendig ist. ;D  ;)  O:-)

Der Gesundheit wegen hatte ich deshalb auf diese Angelegenheit hingewiesen. Persönlich bin ich froh, dass ich die maximale Ladeleistung auch im Fall "Notladung"  limitieren kann und nicht der Strategie des Herstellers ausgeliefert bin.

Bei mir ist die Notladung bisher nur im Winter bei längerer PV Flaute mal aufgetreten. Das ist mit MinSOC 20% und meinem SmartLaden, bis wieder 100% erreicht ist, schon einige Jahre nicht mehr aufgetreten. Ich denke im Winter wird ja wohl niemand auf die Idee kommen PV abzuregeln.
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