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

ch.eick · 08 Dezember 2020, 09:39:17

Zitat von: Mumpitz am 08 Dezember 2020, 05:23:01
Unteranderem wird dabei ja die Batterie zuerst auf 90% geladen bevor sie wieder entladen wird. Im Moment steht sie seit Tagen auf ca. 54%. Die Batterie befindet sich dabei im Normal Modus. Ist das bei euch auch so oder ist sie bei euch im Ruhemodus?

Ein herzliches Gruezi wohl an den Bodensee

Das ist bei mir auch so, wobei sich der Modus "Ruhe1" auch bereits einmal aktiviert hat. Dies war nach der Entladung und mehreren Tagen von fehlender PV Leistung.
Zu diesem Zeitpunkt habe ich dann im PV_Anlage_1_API die Erweiterung mit EM_State eingebaut und zum Testen im WR den Ruhemodus beendet.

Das was ich hier umgesetzt habe ist nur ein Batterieschonen aus dem Bauch heraus, also nicht wissenschaftlich fundiert, aber wenn der Speicher dann 15 Jahre alt wird mach ich ne Party.

Für weitere Informationen kannst Du auch in diesem Forum viel dazu lesen:
plenticore-plus-und-byd-hvs-unklar
tägliche-notladungen-des-plenticore-durch-fehlerhafte-software
programmatischer-lesender-und-schreibender-zugriff-auf-kostal-plenticore-z-b-min

Auch sollten wir dort dann darüber diskutieren, damit dieser Thread nicht auch so platzt.

VG
Christian

ch.eick · 08 Dezember 2020, 12:16:09

Hallo zusammen,
ich wollte mal zur Motivation etwas erfolgreiches zeigen. Durch die Geißelung der LWP habe ich die Temperaturanhebung am Tag umgesetzt. Der Tag läuft per Zeiteinstellung in der Heizung von 10:00-16:00 Uhr !

Trotz der schlechten Wetterprognose vom DWD kam dann heute die Sonne raus

Im ersten Diagramm sieht man sehr schön, dass die LWP sich schön mit PV Leistung versorgt und somit einen hohen Sofortverbrauch gönnt.
Darunter die miese DWD Prognose, die dann mit fc0 nochmal etwas nachgebessert wurde, das wäre aber auch noch besser gegangen.

VG
Christian

DS_Starter · 14 Dezember 2020, 16:06:21

Hallo Christian, @all,

vielleicht hast du/ihr schon gesehen dass ich gerade an einem Solar Forecast Modul baue.
Grundlage ist wie bei deiner Lösung auch DWD_OpenData.

Nun meine Frage. Gibt es schon Erfahrungen wie gut die Strahlungserwartung des DWD ist ?
Heute zum Beispiel habe ich eine starke Abweichung des tatsächlichen Geschehens von der Vorhersage festgestellt.
Vielleicht war es einfach nur ein ungünstiger Fall. Ich schaue mir DWD Data erst seit kurzem an. Wie sind eure Erfahrungen ?

Grüße,
Heiko

ch.eick · 14 Dezember 2020, 18:03:50

Zitat von: DS_Starter am 14 Dezember 2020, 16:06:21
vielleicht hast du/ihr schon gesehen dass ich gerade an einem Solar Forecast Modul baue.
Grundlage ist wie bei deiner Lösung auch DWD_OpenData.

Nun meine Frage. Gibt es schon Erfahrungen wie gut die Strahlungserwartung des DWD ist ?
Heute zum Beispiel habe ich eine starke Abweichung des tatsächlichen Geschehens von der Vorhersage festgestellt.
Vielleicht war es einfach nur ein ungünstiger Fall. Ich schaue mir DWD Data erst seit kurzem an. Wie sind eure Erfahrungen ?

Hallo Heiko,
ich habe mal ein Prognose Diagramm von heute angehängt, was die normalen Abweichungen aus der Solar_forcast() Funktion wiederspiegelt.
Das es hier einige im Forum gibt, die generell eine Leistungsprognose für sinnfrei erachten stellt sich die Frage, ob Du nicht meine Version verwenden möchtest.

Aber zurück zur Frage. Es gibt einige tage, bei denen der DWD ziemlich daneben liegt, was sie dann zaghaft versuchen zu korrigieren

Aber es ist halt Glaskugel lesen und das bleibt es auch.
Meine Näherung habe ich erreicht, indem Wolken,Regen, und die Modultemperatur, sowie die Ausrichtung der Module eingeflossen ist.
Ganz zum Schluss kann man noch einen eigenen Faktor definieren, den man auch zB mit den Jahreszeiten wechseln könnte.

Was noch fehlt ist Schnee und Rauhreif auf den Modulen, da fehlen mir noch die Forecast Daten und der sssssittt, bum Faktor, wenn der Belag von den Modulen gerutscht ist

Im großen und ganzen kann man aber sagen, das mein Forecast konservativ ist. Man kann mit DbRep die Tagessumme berechnen und als kWh (weil Rad1h zugrunde liegt) nehmen.
Das gibt einen Richtwert für Entscheidungen und alles was drüber liegt da kann man sich freuen.

Für die Anpassung habe ich eine "Heizungskurve" für die Werte zugrunde gelegt, wodurch man die Aggressivität der Korrektur einstellen kann.

Ob sich dafür ein Modul lohnt, was Du dann Maintainen musst ist echt die Frage. Ich liefer Dir aber gerne weitere Tips, meiner fast zweijährigen Arbeit.

Im Photovoltaik Forum gibt es von kilian auch noch die Phyton Implementierung, die mit der pvlib arbeitet, aber wie gesagt, man sollte es nicht übertreiben.

Viele Grüße
Christian

DS_Starter · 15 Dezember 2020, 17:07:45

Hallo Christian,

danke für die Infos.
Das Forecast-Modul ist eigentlich nur ein "Abfallprodukt" des SMAPortal-Moduls welches durch die SMA Strategie leider zu den Akten gelegt werden musste.
Wir hatte seinerzeit viel Arbeit in die Grafik investiert und das wollte ich einfach nur retten und etwas brauchbares damit der Community zur Verfügung stellen. In diesem Forecast Device soll aber nicht nur die Prognose für den Standort vorausgesagt werden, sondern auch andere Mehrwerte die man für eine Steuerung auswerten kann. Zum Beispiel eine 4h Forecast bzw. eine Empfehlung per Reading, wann man planen könnte zusätzliche Verbraucher einzuschalten und solche Dinge.

Nur sollte es etwas mehr als ein bloßer Blick in die Glaskugel sein.

Jetzt frage ich mich natürlich, der rad1h Wert nicht bereits die prognostizierten Wetterverhältnisse (Bewölkung, Regen usw.) beinhaltet ?
Und was ist mit einer Direktstrahlung, gibt es diese Angabe im DWD_OpenData ? Der Rad1h Wert ist doch nur die diffuse Globalstrahlung oder sehe ich das falsch ?

Grüße,
Heiko

ch.eick · 15 Dezember 2020, 17:46:28

Zitat von: DS_Starter am 15 Dezember 2020, 17:07:45
Das Forecast-Modul ist eigentlich nur ein "Abfallprodukt" des SMAPortal-Moduls welches durch die SMA Strategie leider zu den Akten gelegt werden musste.
Wir hatte seinerzeit viel Arbeit in die Grafik investiert und das wollte ich einfach nur retten und etwas brauchbares damit der Community zur Verfügung stellen. In diesem Forecast Device soll aber nicht nur die Prognose für den Standort vorausgesagt werden, sondern auch andere Mehrwerte die man für eine Steuerung auswerten kann. Zum Beispiel eine 4h Forecast bzw. eine Empfehlung per Reading, wann man planen könnte zusätzliche Verbraucher einzuschalten und solche Dinge.

Nur sollte es etwas mehr als ein bloßer Blick in die Glaskugel sein.

Jetzt frage ich mich natürlich, der rad1h Wert nicht bereits die prognostizierten Wetterverhältnisse (Bewölkung, Regen usw.) beinhaltet ?
Und was ist mit einer Direktstrahlung, gibt es diese Angabe im DWD_OpenData ? Der Rad1h Wert ist doch nur die diffuse Globalstrahlung oder sehe ich das falsch ?

Nach meiner Kenntnis ist rad1h die direkt und diffuse Strahlung. Ich hatte nur nach einem strahlungsabhängigen Wert gesucht, der auch optimaler weise Stündlich sein sollte.
Wolken und Regen scheinen da nicht mit drin zu sein, zumindest hat meine Korrektur zu einem besseren Ergebnis geführt, da der rad1h Wert doch immer sehr hoch ist.
Ein Forecastsignal vom Forecast habe ich bisher als nicht notwendig empfunden.

Ich verändere bisher nur die erlaubte Startzeit nach dem Forecast für zB 12:00 Uhr wodurch das Gerät bei schlechter Prognose schon früher starten darf.
Oder man fragt die Summe der zuerwartenden Leistung ab und man startet dann halt auch die starken Verbraucher sofort, wenn eh nichts zu erwarten ist.

Das ist aber alles sehr Verbraucher spezifisch, sodass ich das direkt in den DOIFs der Geräte erledige.

Generell hat sich nun in zwei Jahren Entwicklung gezeigt, dass es bei den Verbrauchern ausreichend ist, wenn sie nach den aktuellen Werten der PV Anlage gesteuert werden,
was in meinen Muster Geräten umgesetzt ist. Durch Mindestlaufzeiten und Wartezeiten puzzeln sich die Verbraucher jetzt unter die Leistungskurve.
Im Winter hat man eh immer zu wenig, da schalten die Geräte sich auch nachts ein, wie zB der Wirlpool, damit der Temperaturverlust aufgeholt werden kann.
Beim Pool habe ich auch ein aWattar Beispiel eingebaut, wenn man schwankende Strompreise hätte, oder wenn der Energiemarkt das mal ermöglichen wird. Das wird besonders interessant, wen ein BEV dazu kommt.
Im Sommer schiebt der Kostal die Batterieladung ziemlich gut in die Mittagszeit, damit die dynamischen 70% genutzt werden können, was ja bei SMA wohl nicht so ist. Aber auch da würde man mit meiner recht simplen Prognose einen maxValue abfragen und dann die Ladezeit des Speichers dort hin verlagern können.

Mit einer WallBox und einem passenden BEV wäre es gut, wenn man die Ladehöhe vorwählen könnte, aber auch da würde man sich dann an der Leistungskurve entlang hangeln und den Überschuss jeweils in Stufen der WallBox mitteilen. Wenn die WallBox am KSEM mitliest erkennt sie ja auch, wann eingespeist würde und kann dann die Ladung des BEV daran anpassen.

Lange Rede kurzer Sinn, es ist weniger Prognose notwendig als man denkt. Einfach alles sofort verbrauchen, was man hat, das hat man

Gruß
Christian

DS_Starter · 15 Dezember 2020, 17:58:51

Danke Christian und ich gebe dir der Sinnhaftigkeit von Vorhersagen weitgehend Recht.
Aber du hast etwas wichtiges vergessen zu erwähnen ... den Spieltrieb

LG,
Heiko

ch.eick · 15 Dezember 2020, 18:13:38

Zitat von: DS_Starter am 15 Dezember 2020, 17:58:51
Danke Christian und ich gebe dir der Sinnhaftigkeit von Vorhersagen weitgehend Recht.
Aber du hast etwas wichtiges vergessen zu erwähnen ... den Spieltrieb

Da bin ich wieder dabei

ch.eick · 16 Dezember 2020, 08:59:08

Guten morgen zusammen,

der Fehlerteufel hat wieder zugeschlagen. In der API von Kostal ist ein Schreibfehler, den ich durch Copy/Paste der Wertenamen einfach mit übernommen habe.

Es lässt sich recht einfach korrigieren, da dieser Wert in meiner Implementierung nicht in die Datenbank geht.

Code Auswählen


## Achtung, beim http Aufruf der API muss der Rechtschreibfehler bestehen bleiben, da Kostal ja die API noch nicht korrigiert hat.
attr PV_Anlage_1_API get22-3Name Battery_InternControl_MinHomeConsumption
attr PV_Anlage_1_API set223Name 22_3_Battery_MinHomeConsumption

## Im PV_Schedule müssen ebenfalls zwei Zeilen im DEF korrigiert werden, aber nur wenn Ihr die Batteriesteuerung im Herbst/Winter einsetzt.

1.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])
2.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption 50)

Viele Grüße
Christian

ch.eick · 16 Dezember 2020, 09:03:13

Und noch eine Nachricht.

Unter diesem Link Frevel: Die Idee einheitlicher Devicenamen und Readings versuchen wir etwas Ordnung in die Namensvergabe bei Solaranlagenkomponenten zu bringen. Die Diskussion hat gerade mit dem Sammeln von Ideen begonnen.

Viele Grüße
Christian

Mumpitz · 16 Dezember 2020, 09:09:16

Zitat von: ch.eick am 16 Dezember 2020, 08:59:08
Guten morgen zusammen,

der Fehlerteufel hat wieder zugeschlagen. In der API von Kostal ist ein Schreibfehler, den ich durch Copy/Paste der Wertenamen einfach mit übernommen habe.

Es lässt sich recht einfach korrigieren, da dieser Wert in meiner Implementierung nicht in die Datenbank geht.
Code Auswählen Erweitern
## Achtung, beim http Aufruf der API muss der Rechtschreibfehler bestehen bleiben, da Kostal ja die API noch nicht korrigiert hat. attr PV_Anlage_1_API get22-3Name Battery_InternControl_MinHomeConsumption attr PV_Anlage_1_API set223Name 22_3_Battery_MinHomeConsumption ## Im PV_Schedule müssen ebenfalls zwei Zeilen im DEF korrigiert werden, aber nur wenn Ihr die Batteriesteuerung im Herbst/Winter einsetzt. 1.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity]) 2.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption 50)

Viele Grüße
Christian

Einmal mehr ein grosses Dankeschön für deinen unermüdlichen Einsatz für uns alle!!! Echt unglaublich wie du uns alle immer wieder sofort von deiner grossen Arbeit profitieren lässt!

ch.eick · 16 Dezember 2020, 09:16:54

Zitat von: Mumpitz am 16 Dezember 2020, 09:09:16
Einmal mehr ein grosses Dankeschön für deinen unermüdlichen Einsatz für uns alle!!! Echt unglaublich wie du uns alle immer wieder sofort von deiner grossen Arbeit profitieren lässt!

Danke für die Anerkennung.

knuddli · 18 Dezember 2020, 17:16:52

Hallo Christian,

erst mal ein riesen Danke für die tolle Arbeit. Mir fällt die ganze Programmiererei ziemlich schwer und ich verstehe wenig von dem Ganzen.
Nun habe ich alles aus dem Wiki abgeschrieben und bekomme dennoch viele Fehlermeldungen.

Code Auswählen

Messages collected while initializing FHEM:
configfile: PV_Anlage_1_API: unknown attribute DbLogExclude. Type 'attr PV_Anlage_1_API ?' for a detailed list.
PV_Anlage_1_API: unknown attribute DbLogInclude. Type 'attr PV_Anlage_1_API ?' for a detailed list.
PV_KSEM: unknown attribute DbLogExclude. Type 'attr PV_KSEM ?' for a detailed list.
BYD_Status: unknown attribute DbLogExclude. Type 'attr BYD_Status ?' for a detailed list.
PV_Schedule: unknown attribute DbLogExclude. Type 'attr PV_Schedule ?' for a detailed list.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
DB_Service_Schedule: unknown attribute DbLogExclude. Type 'attr DB_Service_Schedule ?' for a detailed list.
DWD_Forecast: unknown attribute DbLogExclude. Type 'attr DWD_Forecast ?' for a detailed list.
Astro: unknown attribute DbLogExclude. Type 'attr Astro ?' for a detailed list.
Astro: unknown attribute DbLogInclude. Type 'attr Astro ?' for a detailed list.
Can't open ./db.conf: No such file or directory
The specified DbLog-Device "LogDB" doesn't exist.
Invalid characters in name (not A-Za-z0-9._): wetter_
Unknown command 
, try help. Unknown command ====, try help. Unknown command
, try help.
[Shelly] Invalid IP address  of Shelly device
[Shelly] Invalid IP address  of Shelly device

Autosave deactivated

Das FHEM (6) ist frisch auf Debian 10 installiert und ich habe auch die ganzen geforderten *perl*.deb installiert. Dennoch scheint da was mit der Datenbank (welche Datenbank eigentlich?) falsch zu sein. Den Plenticore und den KSEM sehe ich. Einen BYD habe ich nicht.
Ist es möglich einfach mal die fhem.cfg, 99_myUtils.pm und ggf. noch weitere fehlende Dateien anzuhängen. Damit hat man erst mal die initiale Konfiguration. Trotz copy & paste hab ich sicher was falsch gemacht. Die Schellys gibt es allerdings nicht! Welche Voraussetzungen muss das FHEM schon vorher mitbringen (Datenbank?).

So groß brauche ich das im Prinzip auch nicht. Mir reicht es schon einen Dummy (oder MQTT*dingens) bei 2000W DC ein und bei 1000W wieder aus zu schalten.

danke und Grüße
Andi

ch.eick · 19 Dezember 2020, 10:18:02

Zitat von: knuddli am 18 Dezember 2020, 17:16:52
Code Auswählen Erweitern
Messages collected while initializing FHEM: configfile: PV_Anlage_1_API: unknown attribute DbLogExclude. Type 'attr PV_Anlage_1_API ?' for a detailed list. PV_Anlage_1_API: unknown attribute DbLogInclude. Type 'attr PV_Anlage_1_API ?' for a detailed list. PV_KSEM: unknown attribute DbLogExclude. Type 'attr PV_KSEM ?' for a detailed list. BYD_Status: unknown attribute DbLogExclude. Type 'attr BYD_Status ?' for a detailed list. PV_Schedule: unknown attribute DbLogExclude. Type 'attr PV_Schedule ?' for a detailed list. The specified DbLog-Device "LogDB" doesn't exist. The specified DbLog-Device "LogDB" doesn't exist. The specified DbLog-Device "LogDB" doesn't exist. The specified DbLog-Device "LogDB" doesn't exist. DB_Service_Schedule: unknown attribute DbLogExclude. Type 'attr DB_Service_Schedule ?' for a detailed list. DWD_Forecast: unknown attribute DbLogExclude. Type 'attr DWD_Forecast ?' for a detailed list. Astro: unknown attribute DbLogExclude. Type 'attr Astro ?' for a detailed list. Astro: unknown attribute DbLogInclude. Type 'attr Astro ?' for a detailed list. Can't open ./db.conf: No such file or directory The specified DbLog-Device "LogDB" doesn't exist. Invalid characters in name (not A-Za-z0-9._): wetter_ Unknown command , try help. Unknown command ====, try help. Unknown command , try help. [Shelly] Invalid IP address of Shelly device [Shelly] Invalid IP address of Shelly device Autosave deactivated

Das FHEM (6) ist frisch auf Debian 10 installiert und ich habe auch die ganzen geforderten *perl*.deb installiert. Dennoch scheint da was mit der Datenbank (welche Datenbank eigentlich?) falsch zu sein. Den Plenticore und den KSEM sehe ich. Einen BYD habe ich nicht.
Ist es möglich einfach mal die fhem.cfg, 99_myUtils.pm und ggf. noch weitere fehlende Dateien anzuhängen. Damit hat man erst mal die initiale Konfiguration. Trotz copy & paste hab ich sicher was falsch gemacht. Die Schellys gibt es allerdings nicht! Welche Voraussetzungen muss das FHEM schon vorher mitbringen (Datenbank?).

So groß brauche ich das im Prinzip auch nicht. Mir reicht es schon einen Dummy (oder MQTT*dingens) bei 2000W DC ein und bei 1000W wieder aus zu schalten.

Hallo Andi,

der Appetit kommt beim Essen.

Als erstes fällt mir auf, dass Du wahrscheinlich die DbLog nicht installiert hast. Dazu findest Du im Fhem eine entsprechende Anleitung.
Das ist eine Datenbank, in der die ganzen Daten gesammelt werde, die die PV Anlage liefert, um später Diagramme zeichnen zu können.

Wenn Du das weg lässt, dann kannst Du nur auf Momentanwerte reagieren, aber hast keine Diagramme und der Forecast fällt dann auch weg.
Dazu musst Du Dich entscheiden. Von Filelog rate ich Dir ab, da es ein ziemliches Datenvolumen werden wird, das man in einer Datenbank besser händeln kann.

Am Anfang lege bitte zuerst das PV_Anlage_1 Device an später würde dann PV_Anlage_1_API dazu kommen, um die Statistiken abzufragen.
Die Konfiguration erfolgt über das PV_Anlage_1_config Device, dort kommt z.B. die IP-Adresse des Plenticore rein. Bitte lade das als RAW mit den setstate Befehlen, das sind einige defaults.

Die Geräte Devices brauchst Du am Anfang noch nicht, da schauen wir mal was für Dein 2000W Gerät am besten passen würde.
Wenn Du keine Shellys für die Ansteuerung der Geräte verwendest, musst Du in den Devices entsprechend Änderungen vornehmen. Da Du aber nur ein Gerät schalten möchtest ist das überschaubar.
Was ist das für ein Gerät, das Du schalten möchtest?

Gruß
Christian

knuddli · 19 Dezember 2020, 13:07:00

Hallo Christian,

danke für die schnelle Antwort. Die Datenbank ist angelegt und scheint zu funktionieren. Zumindest sind nun keine Fehlermeldungen mehr da.
Ist das Normal das die PV_Anlage_1_API nur "? ? ?" anzeigt? Die API meines Plenticore ist aber auch nur 0.2.0! Firmware 1.42/1.43.

Wie schon erwähnt, ich hab schon alles abgeschrieben. Mittlerweile hab ich auch Astro und DWD richtig eingestellt.

Deine Shellys sind fast baugleich mit meien sonoffs (ESP8266). Allerdings hab ich da Tasmota (MQTT) drauf, da bei mir nix nachhause telefonieren darf. Das passe ich mir noch an...

Noch mal einen riesen Dank für die wahnsinns Arbeit!
VG
Andi