Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)

[ch.eick]

ich habe zwar keinen Kostal plenticore, aber lese immer mal interressiert rein. 

Die Module LogDb und LogDbRep gibt es nicht, die Module heißen DbLog und DbRep. Das müsstest du mal durchgehend ändern, sonst könnten Anfänger bisschen durcheinander kommen was Module und was Devices sind.

Hallo Heiko,
Du hast natürlich recht, aber vor lauter Buchstaben sieh man das manchmal nicht
vielen Dank
     Christian

[ch.eick]

Ich habe mal zwei kleine Änderungen im Wiki-Beitrag gemacht:

• Infobox Hardware "repariert"
• Exemplarisch ein Stück Python code in <Syntaxhighlight> Tags gesetzt

Danke dafür, ich habe es jetzt auch durchgängig, auch für Perl und sogar die DOIFs sehen mit "Perl" besser lesbar aus.

Wenn Du möchtest - und soweit mit dem Inhalt fertig bist - kann ich gern mal komplett drüberschauen.

Das Angebot nehme ich gerne an, die SVGs sind nun auch drin, Du kannst gerne schon mal durchgehen.
Das ist mein erstes Wiki und Du kannst auch gerne direkt rein schreiben.

Wie bekomme ich nun noch Beispielbilder rein?
Gibt es auch eine Formatierung, die den Code zum Scrollen Darstellt? Dann wäre die Seite eswas kürzer

Gruß
     Christian

[ch.eick]

Sieht Hammer aus, Danke!!!!

Hey Mumpitz,
Du bist jetzt aufgerufen Deine ersten Erfahrungen beizusteuern. Ich denke Du bist der Erste, der es so komplett übernommen hat.
Gruß
    Christian

[ch.eick]

Hallo Ihr lieben Mitstreiter,

seit geraumer Zeit machen mir die vielen Variablen, die ich teilweise noch hart codiert in den Geräten verstreut habe etwas sorge.
Auch die Portabilität für den Forecast ist hiervon besonders betroffen.

Aus diesem Grund führe ich gerade ein Dummy ein, dass die zu konfigurierenden Variablen beherbergen soll.

Bitte schaut bei Zeiten ins Wiki, wo ich die Aktualisierungen einpflege.

Gruß
     Christian

[ch.eick]

Hallo zusammen,

ich habe im PV Eigenverbrauch jetzt mal den ersten Forecast eingebaut.

Am aktuellen Tag wird geschaut, wie die Prognose für 12:00 Uhr ist und dann die Startzeit nach vorne verschoben.

Code Auswählen Erweitern


################################################################################################################
## 13 Pool Startzeit durch Forecast verschieben. Der Forecast wird um 7:00 im Device PV_Schedule aktualisiert
##
DOELSEIF
([07:17])
    (
     {my $timestamp = POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time));
      my $VALUE     = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",$timestamp,0);
      if ( $VALUE < 4000 )
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartWinter",0) )}
      else
         {fhem("setreading Pool TimeStart ".ReadingsVal("Pool","TimeStartSummer",0) )}
     },
     {Log 3, "Pool_PV cmd_13 : Pool TimeStart switched"}
    )

Der Forecast wird um 7:00 Uhr erzeugt, damit er so aktuell wie möglich ist.

Solar_Calculation_fc0 mit localtime(time) ist der Tages Forecast, der am selben Tag erstellt wurde.
Solar_Calculation_fc1 mit localtime(time) ist der Forecast, der am Vortag für den aktuellen Tag erstellt wurde
Solar_Calculation_fc1 mit localtime(time + 24*60*60) dieser Forecast wurde heute, für morgen erzeugt

*_fc1 ist immer ungenauer als *_fc0 , da die Daten regelmäßig aktualisiert werden.

Gruß
    Christian

[ch.eick]

Hallo zusammen,
mit etwas Stolz möchte ich verkünden, dass es nun geglückt ist mit dem Plenticore über die API Schnittstelle mit dem HTTPMOD Modul zu kommunizieren. Dies umfasst folgende Möglichkeiten:

Code Auswählen Erweitern


get:
## start, finish, create_session werden für den Login benötigt und arbeiten über userreadings mit zwei Python Skripten zusammen
01_/auth/start
02_/auth/finish
03_/auth/create_session

## Auskunft über den Anmeldezustand, es muss aber kurz vorher abgefragt werden
04_/auth/me

## Informationen zum Plenticore
05_/info/version

20_/processdata/scb_statistic_EnergyFlow

## Liste aller Plenticore Module. Es werden keine readings erzeugt. Das Ergebnis steht im httpbody, der mit attr <Device> showBody 1 angezeigt werden kann.
21_/modules_list

## Hier gibt es viele technische Loggings. Sollte es Probleme beim Abholen der Daten geben kann es am timeout liegen
24_/logdata/download

## Speicher Type habe ich folgendes ermitteln können 0=keine , 4=BYD
## Die Werte können auch gesetzt werden, siehe set Befehle
31_Battery_Type
32_Battery_MinHomeComsumption
33_Battery_Strategy
34_Battery_MinSoc
35_Battery_SmartBatteryControl_Enable
36_Battery_DynamicSoc_Enable

## Das zeigt den FW Update Status beim FW Laden an. Die Rückmeldung ist im httpbody zu sehen, es werden keine readings erzeugt.
41_/update/status

set:
## Eine bestehende Session wird abgemeldet
06_/auth/logout

## Die letzten Events können in deutsch oder englisch abgeholt werden
23_/events/latest_5 [en-gb,de-de]

## Batterie Einstellungen können verändert werden. Es werden einige Werte vorgeschlagen. Bitte vorher immer den aktuellen Wert abfragen und besser aufschreiben!
## Hier sollte nur etwas gesetzt werden, wenn man sich sicher ist, was man tut.
31_Battery_Type [0,4]
32_Battery_MinHomeComsumption
33_Battery_Strategy
34_Battery_MinSoc
35_Battery_SmartBatteryControl_Enable
36_Battery_DynamicSoc_Enable

## Der reboot läuft noch nicht. Da ist die API ziemlich zickig. Ich habe ein Skript, womit es bereits geht :-)
51_/system/reboot


1 ) Bei einem fehlenden Login wird bereits ein neues Login durchgeführt. Das gilt auch, wenn man ein Logoff machen möchte, aber gar keine aktuelle Session hat It's not a bug, it's a feature

2 ) Möchte man bewusst ein Login machen, ohne bereits ein API Kommando zu senden, dann beginnt man mit "get 01_/auth/start" alle weiteren Schritte folgen dann automatisch,
    bis die auth_sessionId empfangen wurde.

3 ) "get /auth/me" kann immer abgefragt werden, um zu erfahren, ob die Session noch gültig ist. Wenn nicht erfolgt ein neuer Session Aufbau

4 ) 05_/info/version geht auch ohne Session

5 ) Die Statistiken werden mit "get 20_/processdata/scb_statistic_EnergyFlow" abgeholt und bereits in der Datenbank geloggt. Dies sollte dann zyklisch erfolgen und wird noch im Wiki fest eingebaut.

6 ) für die Batterie Einstellungen stehen "[g|s]et 3[1-6]_Battery_[Type|MinHomeComsumption|Strategy|MinSoc|SmartBatteryControl_Enable|DynamicSoc_Enable]" zur Verfügung.
    Bitte zuerst einen Wert abfragen und merken, bevor er neu gesetzt wird! Was z.B. bei einem falschen Battery_Type geschieht ist nicht bekannt, könnte aber dem Speicher schaden!

7 ) "set 23_/events/latest_5 ..." ist nicht als get Befehl implementiert, da hier die Sprache ausgewählt werden kann.

8 ) Am "set 51_/system/reboot" wird noch gearbeitet. Da kommt noch aktuell ein Fehler.

Die RAW Definition zum PV_Anlage_1_API steht im Wiki Kostal_Plenticore_10_Plus, so wie auch die Python Skripte.

Gruß
    Christian

[ch.eick]

Hallo zusammen,
es gibt wieder Neuerungen. Durch einen Tip von amenomade ist mein Mechanismus die Daten vom DWD abzuholen komplett überflüssig geworden. Die bisherige Implementierung habe ich aus einem anderen Forum übernommen und angepasst gehabt, jedoch gibt es bereits ein DWD_Forecast Modul, das mit einem Attribut ebenfalls die Rad1h Werte liefern kann. Lange rede kurzen Sinn, ich war Betriebsblind und habe es nun korrigiert.
Die aktuelle Version ist wie immer im Wiki.

Neu:
- DWD_Forecast
- PV_Schedule
- 99_myUtils - Solar_forecast()

Raus:
- dwd_get_forecast.py

Gruß
    Christian

[ch.eick]

Und noch eine Änderung wegen der Statistiken des Plenticore, die schon etwas her ist und auch im Wiki steht.

Neu:
PP_Anlage_1 geändert
PV_Anlage_1_API
plenticore_auth_finish.py
plenticore_auth_session.py

Raus:
Im PV_Anlage_1 die readings der Statistiken
plenticore_statistic.py

Wer schon etwas länger dabei ist sollte den Umstieg laut Wiki durchführen. Neue Interessenten implementieren einfach nach dem Wiki.

[ch.eick]

Momentan arbeite ich an der BYD Speicher Abfrage.

Das ganze läuft bereits mit HTTPMOD Login, jedoch müssen noch die readings erarbeitet werden.
Damit würde dann noch ein Python Skript wegfallen, wodurch die Implementierung sauberer im FHEM integriert sein wird.

[ch.eick]

Wer könnte sich denn bei den Diagrammen in Grafana mit einbringen?
Da bräuchte ich echt noch Unterstützung

- Die Daten sind in der SQL Datenbank
- Mein Docker mit Grafana ist auch schon gestartet.

[ch.eick]

Hallo zusammen,

könntet Ihr mir bitte Muster aus dem PV_Anlage_1 Device für

Code Auswählen Erweitern


Battery_Type 892941625

zusenden? Ich hoffe, dass man mit

8929 => 8,93  KW die Nennleistung ableiten kann.

Gruß
    Christian

[plin]

Wer könnte sich denn bei den Diagrammen in Grafana mit einbringen?
Da bräuchte ich echt noch Unterstützung

- Die Daten sind in der SQL Datenbank
- Mein Docker mit Grafana ist auch schon gestartet.

ok, das war das Startsignal.

Ich habe meine Panels von Heckert auf dem Dach, warte aber noch auf meinen Kostal Plenticore Plus 7 Wechselrichter und den neuen Zähler. Aktuell sammle ich alles was ich finde. Aus Deinem Wiki habe ich bereits einiges übernommen (und verworfen). Für wunderground nutze ich das WEATHER-Modul, da ich Probleme mit Celsius/Fahrenheit hatte. Ich habe mittlerweile die Solar-Daten vom DWD in meinem FHEM und einer MySQL-Datenbank, die Vorhersage von Proplanta sowie zwei Wetterstattionen aus der Nachbarschaft via wunderground.

Aktuell sieht meine erste Übersicht wie angehängt aus.

Was will ich tun?

• Belastbare Forecast-Daten zusammentragen, um visuell getriggert oder via FHEM Verbraucher tagsüber einzuschalten.
• Diverse Auswertungen (Wie gut bin ich schon mit der Eigennutzung?)
• Basisdaten für die Steuer
• Lastprofile meiner Stromverbraucher
• etc.

Ich habe da also viel Bedarf. Mein Ansatz für die Datensammlung ist eine eigene MySQL-DB namens Solar mit separaten Tabellen für die Quellen.

VG plin

P.S. Meine FHEM-Landschaft https://wiki.fhem.de/wiki/Benutzer:Plin53177

[ch.eick]

ok, das war das Startsignal.

Ich habe meine Panels von Heckert auf dem Dach, warte aber noch auf meinen Kostal Plenticore Plus 7 Wechselrichter und den neuen Zähler. Aktuell sammle ich alles was ich finde. Aus Deinem Wiki habe ich bereits einiges übernommen (und verworfen). Für wunderground nutze ich das WEATHER-Modul, da ich Probleme mit Celsius/Fahrenheit hatte. Ich habe mittlerweile die Solar-Daten vom DWD in meinem FHEM und einer MySQL-Datenbank, die Vorhersage von Proplanta sowie zwei Wetterstattionen aus der Nachbarschaft via wunderground.

Aktuell sieht meine erste Übersicht wie angehängt aus.

Was will ich tun?

• Belastbare Forecast-Daten zusammentragen, um visuell getriggert oder via FHEM Verbraucher tagsüber einzuschalten.
• Diverse Auswertungen (Wie gut bin ich schon mit der Eigennutzung?)
• Basisdaten für die Steuer
• Lastprofile meiner Stromverbraucher
• etc.

Ich habe da also viel Bedarf. Mein Ansatz für die Datensammlung ist eine eigene MySQL-DB namens Solar mit separaten Tabellen für die Quellen.

VG plin

P.S. Meine FHEM-Landschaft https://wiki.fhem.de/wiki/Benutzer:Plin53177

1) Eine eigene SQL Datenbank ist nicht notwendig und erhöht den Aufwand. => DbLog im Docker Container
2) Wetter Daten:
    - nicht zu viele in die Datenbank, weniger ist mehr, also nur, was Du auch darstellen möchtest
    - Proplanta ist jetzt bei mir auch raus
    - wunderground habe ich doch umgerechnet? Das liefert, bei passenden Stationen tolle momentan Radiation
    - DWD Implementierung mit Leistungsprognose findes Du auf der Wiki Seite, das ist ganz frisch am WE überarbeitet
      Ich logge vom DWD keine Daten, sondern nur die Leistungsprognose der PV Anlage von heute und morgen.
      nach maximal einem Monat interessiert die Prognose eh nicht mehr.
3) Leistung
    - Lastprofile bekomme ich über die shellys, bzw den Stromverbrauch, den ich mir dann im Diagramm mit darstelle.
      Hier ist der Weg zum Grafana, da man dort wohl auch Einzelverbräuche graphisch stapeln kann.
    - Bei den Forecast Daten zählt eigentlich nur die Leistungsprognose in einem möglichst engen Raster. Mit dem DWD gelingt das sehr gut auf Stundenbasis.
      Wolken und Regen habe ich auch gut im Griff, denn das macht den Unterschied. Das ist zwar recht tricky einzustellen, aber dann läuft es.

Im Diagramm sieht man sehr schön die gemessene SolarRadiation der Nachbarn mit dem Knick um 11:00 Uhr.
Der DWD ist morgens immer recht forsch bei dem Wert um 9:00 Uhr. In den letzten Tagen ist der Einfluss von Regen und Wolken sehr niedrig, mal sehen was der Herbst so bringt.
Ich habe die default Werte meiner Anlage im Wiki, im PV_Anlage_1_config abgelegt.

In den letzten 2 Wochen war sehr viel Bewegung auf der Wiki Seite. Aktualisiere da am besten nochmal.

Bekommst Du auch einen Speicher?
Was hast Du verworfen, oder hat Dir nicht gefallen?
Was könnte man noch verbessern?

Gruß
    Christian

[plin]

Hi Christian,

1) Eine eigene SQL Datenbank ist nicht notwendig und erhöht den Aufwand. => DbLog im Docker Container
2) Wetter Daten:
    - nicht zu viele in die Datenbank, weniger ist mehr, also nur, was Du auch darstellen möchtest
    - Proplanta ist jetzt bei mir auch raus
    - wunderground habe ich doch umgerechnet? Das liefert, bei passenden Stationen tolle momentan Radiation
    - DWD Implementierung mit Leistungsprognose findes Du auf der Wiki Seite, das ist ganz frisch am WE überarbeitet
      Ich logge vom DWD keine Daten, sondern nur die Leistungsprognose der PV Anlage von heute und morgen.
      nach maximal einem Monat interessiert die Prognose eh nicht mehr.
3) Leistung
    - Lastprofile bekomme ich über die shellys, bzw den Stromverbrauch, den ich mir dann im Diagramm mit darstelle.
      Hier ist der Weg zum Grafana, da man dort wohl auch Einzelverbräuche graphisch stapeln kann.
    - Bei den Forecast Daten zählt eigentlich nur die Leistungsprognose in einem möglichst engen Raster. Mit dem DWD gelingt das sehr gut auf Stundenbasis.
      Wolken und Regen habe ich auch gut im Griff, denn das macht den Unterschied. Das ist zwar recht tricky einzustellen, aber dann läuft es.

In den letzten 2 Wochen war sehr viel Bewegung auf der Wiki Seite. Aktualisiere da am besten nochmal.

Was hast Du verworfen, oder hat Dir nicht gefallen?
Was könnte man noch verbessern?

Gruß
    Christian

1) MySQL- bzw. MariaDB läuft schon seit Jahren auf meinem Server, da kommt es auf eine DB mehr auch nicht an.

2) wunderground habe ich durch Dein Wiki neu entdeckt. Im Wiki fehlte der Hinweis auf define uconvInit notify global:INITIALIZED {use UConv}, deshalb sind mir vermutlich die HTTPMOD-basierten Daten um die Ohren geflogen. Das habe ich aber erst jetzt als möglich Ursache identifiziert, denn ich habe immer nur Fahrenheit statt Celsius gesehen und irgendwann genervt auf WEATHER umgestellt. Da ich im Augenblick noch in der Findungsphase bin, gönne ich mir die eine oder andere Quelle zusätzlich. Proplanta nutze ich z.B. schon seit Jahren für die Planung der Gartenbewässerung. Durch wunderground kriege ich jetzt sogar den realen Niederschlag aus der Nachbarschaft.
dwdforecast.py: In der pvlib fehlen meine Module und der Wechselrichter. Hast Du die nachgetragen und welche Spalte enthält welche Daten aus dem Datenblatt?

3) Leistung: Da brauche ich erst mal Hardware ...

Was habe ich verworfen? Meine iegne MariaDB statt DbLog, WEATHER statt HTTPMOD.
Was man verbessern könnte? Ich brauche erst mal das Gesamtbild und eigene Daten, dann kommen schon die Ideen.

VG Peter

[ch.eick]

Hi Christian,

1) MySQL- bzw. MariaDB läuft schon seit Jahren auf meinem Server, da kommt es auf eine DB mehr auch nicht an.

2) wunderground habe ich durch Dein Wiki neu entdeckt. Im Wiki fehlte der Hinweis auf define uconvInit notify global:INITIALIZED {use UConv}, deshalb sind mir vermutlich die HTTPMOD-basierten Daten um die Ohren geflogen. Das habe ich aber erst jetzt als möglich Ursache identifiziert, denn ich habe immer nur Fahrenheit statt Celsius gesehen und irgendwann genervt auf WEATHER umgestellt. Da ich im Augenblick noch in der Findungsphase bin, gönne ich mir die eine oder andere Quelle zusätzlich. Proplanta nutze ich z.B. schon seit Jahren für die Planung der Gartenbewässerung. Durch wunderground kriege ich jetzt sogar den realen Niederschlag aus der Nachbarschaft.
dwdforecast.py: In der pvlib fehlen meine Module und der Wechselrichter. Hast Du die nachgetragen und welche Spalte enthält welche Daten aus dem Datenblatt?

3) Leistung: Da brauche ich erst mal Hardware ...

Was habe ich verworfen? Meine iegne MariaDB statt DbLog, WEATHER statt HTTPMOD.
Was man verbessern könnte? Ich brauche erst mal das Gesamtbild und eigene Daten, dann kommen schon die Ideen.

VG Peter

Okay, das mit dem uconv schau ich mir an, das wird natürlich benötigt.

dwdforecast ist mittlerweile abgelöst und das Python Skript wird nicht mehr benötigt. Du solltest dringlichst die Wiki Seite checken.
Ich arbeite an Python raus, weil das nur ein Zwischenschritt war. Die pvlib hat Kilian mit rein gebracht, weil in dem Forum eine andere Platform verwendet wird.