FHEM - Anwendungen > Solaranlagen

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

(1/76) > >>

ch.eick:
Hallo zusammen,
da es von mir mehrere Threads zu diesem Thema gegeben hat fasse ich nun alles hier zusammen und schließe die anderen.

Dokumentiert wird alles auf der Wiki Seite Kostal_Plenticore_10_Plus

Es geht um folgende Themen:

* Plenticore 10 Plus
* KSEM
* BYD HV
* Forecast/Leistungsprognose
* Bilanz
* Eigenverbrauch Steuerung
Das Wiki umfasst momentan folgende Einträge

--- Code: ---Stand 2020.10.07
Inhaltsverzeichnis
1 Voraussetzungen Energietechnik
2 Geräte-Registrierung
3 Hersteller Dokumentation
4 Einbindung in das Netzwerk
5 Voraussetzungen FHEM Umfeld
5.1 Alle Geräte müssen mit TCP/IP erreichbar sein
5.2 Alle Module sollten auf einem aktuellen Stand sein
5.3 Python
5.3.1 Ein Python 3 sollte vorhanden sein
5.3.2 Es müssen folgende Python Module vorhanden sein
5.4 Eine LogDB/LogDBRep sollte bereits vorhanden sein, was hier nicht weiter erklärt wird.
5.5 Verwendete Module
6 Einbindung in FHEM: Überblick
6.1 Hardware Anbindung (alles über LAN)
6.1.1 Kostal Plenticore Plus
6.1.1.1 Kostal Plenticore Plus die Basis information (Modbus/TCP)
6.1.1.1.1 Plenticore Modbus Definition
6.1.1.1.2 Modbus Timing
6.1.1.1.3 RAW Definition des konfigurations Dummy
6.1.1.1.4 RAW Definition des Wechselrichters
6.1.1.1.5 Userreadings
6.1.1.2 Kostal Plenticore Plus die API (über HTTPMOD mit Python Skript Authentifizierung)
6.1.1.2.1 Umstellungsaufwand, falls jemand früher eingestiegen ist.
6.1.1.2.2 Plenticore API
6.1.1.2.3 Dateiverzeichnis
6.1.1.2.4 Python 3
6.1.1.2.5 Passworte
6.1.1.2.6 plenticore_auth_* Erläuterung
6.1.1.2.7 plenticore_auth_finish
6.1.1.2.8 plenticore_auth_session
6.1.1.2.9 Ablaufbeschreibung PV_Anlage_1_API
6.1.1.2.10 Automatischer Login mit Sessionaufbau
6.1.1.2.11 RAW Definition des PV_Anlage_1_API
6.2 Kostal Smart Energy Manager (KSEM) (Modbus/TCP)
6.2.1 RAW Definition des KSEM
6.3 BYD Speicher (mit HTTPMOD)
6.3.1 RAW Definition BYD_Status
7 Timeing für die PV extra Funktionen
7.1 RAW Definition PV_Schedule (DOIF)
8 Energie Bilanz
8.1 RAW Definition Energiebilanz
8.2 Erstellen von zusätzlichen Werten in der Datenbank
8.2.1 RAW Definition LogDBRep_PV_total_diff_Week
8.2.2 RAW Definition LogDBRep_PV_total_max_Month
8.2.3 RAW Definition LogDBRep_PV_used_diff_Week
8.2.4 RAW Definition LogDBRep_PV_used_max_Month
8.3 Timing für die Datenbank Einträge
8.4 Löschen von nicht mehr benötigten Werten in der Datenbank
9 Wetter-/Leistungs-Prognose
9.1 Deutscher Wetter Dienst (DWD)
9.1.1 RAW Definition DWD_Forecast
9.2 99_myUtils.pm Funktionen
9.2.1 Solar_forecast
9.2.2 Solar_Plain
9.2.3 Forecast Basiseinstellung
9.2.4 Berücksichtigung von Temperatur, Bewölkung und Regen
9.2.4.1 Temperatur
9.2.4.2 Wolken und Regen
9.3 wunderground
9.4 RAW Definition Wetter_<Wohnort>
10 Diagramme
10.1 RAW Definition Hauptverbraucher
10.1.1 SVG_LogDB_Photovoltaik_2
10.1.2 GPLOTFILE SVG_LogDB_Photovoltaik_2.gplot
10.2 RAW Definition Leistungsbezug
10.2.1 SVG_LogDB_Photovoltaik_3
10.2.2 GPLOTFILE SVG_LogDB_Photovoltaik_3.gplot
10.3 RAW Definition PV_Bilanz
10.3.1 SVG_LogDB_PV_Bilanz
10.3.2 GPLOTFILE SVG_LogDB_PV_Bilanz.gplot
10.4 RAW Definition Forecast / Calculation
10.4.1 SVG_LogDB_Photovoltaik_4
10.4.2 GPLOTFILE SVG_LogDB_Photovoltaik_4.gplot
11 PV Eigenverbrauch-Steuerung
11.1 Beispiel Luft Wärme Pumpe
11.1.1 RAW Definition LWP_LuftWärmePumpe (dummy Modul)
11.1.2 RAW Definition LWP_PV (DOIF Modul)
11.1.3 RAW Definition rg_LWP_Status (readingsGroup Modul)
11.2 Beispiel Pool
11.2.1 RAW Definition Pool_Softube (dummy Modul)
11.2.2 RAW Definition Pool_PV (DOIF Modul)
11.2.3 RAW Definition Pool_Signale (Shelly Modul: shelly1pm)
11.2.4 RAW Definition Pool_Counter (HourCounter Modul)
11.2.5 RAW Definition rg_Pool_Status (readingsGroup Modul)
11.3 Beispiel Waschmaschine (mit Walzenschalter ;-) )
11.3.1 RAW Definition Waschmaschine (dummy Modul)
11.3.2 RAW Definition Waschmaschine_PV (DOIF Modul)
11.3.3 RAW Definition Waschmaschine_Signale (Shelly Modul: shelly1pm)
11.3.4 RAW Definition Waschmaschine_Counter (HourCounter Modul)
11.3.5 RAW Definition rg_Waschmaschine_Status (readingsGroup Modul)
12 Problemlösung
13 Projekte der FHEM-Community
14 Links

--- Ende Code ---

Gruß
   Christian

ch.eick:
Moin,
ein Newsletter mit Informationen, die bisher verstreut waren:

durch einen Test von einem anderen Mitstreiter hat sich herausgestellt, dass BYD nun die neue Version des Speichers BYD_HVS ausliefert. Dieser neue Speicher hat anscheinend noch kein WebGui und wird nur über eine Handy App Konfiguriert. Leider kann man den somit nicht mit meiner Lösung abfragen.

BYD HV Speicher (nicht HVS!)
Diese Speicher wird über das httpmod Modul angesprochen, ist jedoch noch nicht bis in die letzten Tiefen abfragbar.
Der Begriff "Array" bezeichnet einen Speicher mit mehreren Modulen, die mit dem Series_Battery_Counts angegeben werden. Eine Battery hat dabei ca. 1.28 KW und kann über RunData.asp mit weiteren details abgefragt werden. Momentan ist jedoch noch keine gezielte Abfrage der Module 2-n über "get BYD_Status RunData" möglich.

BYD_Speicher HV mit HTTPMOD

Update: 2020.10.08
Für den bisherigen BYD_HV habe ich eine Aktualisierung im Wiki eingefügt.
Man kann jetzt über ein get den Wert Series_Battery_Counts auslesen und in einem userreading wird dieser mit 1.28 zur Gesamtkapazität berechnet.


--- Code: ---InstallationConfig_Array_Counts 1
InstallationConfig_Array_Power 8.96
InstallationConfig_Installation_Time 2020-1-5 13:36:8
InstallationConfig_Series_Battery_Counts 7

--- Ende Code ---

Gruß
     Christian

ch.eick:
EDIT: Die Einspeisung ist nun auch im PV_Anlage_1_API Device integriert und in den userreadings aufgenommen worden.

Hallo zusammen,
es wurde nun bereits mehrfach nach der Darstellung der Einspeisung nachgefragt.
Hier liefert der Kostal Plenticore bereits sehr viele Informationen, bei denen man dann noch die Batterie, falls vorhanden, berücksichtigen muss.
Die Ladung der Batterie ist nicht als Einspeisung zu werten.

Meine Interpretation ist in dem Device Dum.Energie im userreading beinhaltet.
Möchte man nun einen Plot erstellen und die Einspeisung, bzw den Netzbezug darstellen, so kann man dies am einfachsten aus dem Dum.Energie Device machen,
oder muss eventuell die gewünschten userreadings zusätzlich in das PV_Anlage_1 Device übernehmen.

Dum.Energie readings

--- Code: ---READINGS:
     AutarkyQuote   
     AutarkyQuoteDay
     AutarkyQuoteMonth
     AutarkyQuoteYear
     GridConsumption <<< Netzbezug
     GridConsumptionDay
     GridConsumptionMonth
     GridConsumptionYear
     GridFeedIn      <<< Einspeisung
     GridFeedInDay   
     GridFeedInMonth
     GridFeedInYear 
     PV             
     PVDay           
     PVMonth         
     PVTotal         
     PVTotalDay     
     PVTotalMonth   
     PVTotalYear     
     PVYear         
     SelfConsumptionQuote
     SelfConsumptionQuoteDay
     SelfConsumptionQuoteMonth
     SelfConsumptionQuoteYear
     TotalConsumption
     TotalConsumptionDay
     TotalConsumptionMonth
     TotalConsumptionYear

--- Ende Code ---
Bei diesen Readings handelt es sich um Statistiken, die nicht mit einer hohen Frequenz geschrieben werden. Sie eignen sich somit nicht für eine Berechnung von Verbräuchen, diese sollten besser aus dem PV_Anlage_1 Device bezogen werden, wobei wahrscheinlich die meisten Werte bereits schon vorhanden sein werden.

Eine Abfrage des KSEM ist in Verbindung mit dem Plenticore nicht notwendig und würde die LAN Belastung nur unnötig erhöhen. Wesentliche Werte vom KSEM werden vom Plenticore über RS485 oder LAN gelesen und vom Plenticore über ModBus/TCP bereit gestellt.

PV_Anlage_1

--- Code: ---Total_active_power_(powermeter)   <<< Liefert als +/- Wert die Information vom KSEM, hierbei bedeutet - eine Einspeisung und + den Netzbezug
Home_own_consumption_from_grid   <<< zeigt nur den Netzbezug, jedoch nicht die Einspeisung

--- Ende Code ---
Um readings mit "(" ins Logging aufzunehmen ist zu beachten, dass "(" und ")" im Regex als Gruppenkennzeichnis verwendet wird und deshalb bei event-on-* maskiert werden muss.

--- Code: ---DBLogInclude Total_active_power_\(powermeter\),Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Solar_.*

event-on-change-reading Total_active_power_\(powermeter\),Act_state_of_charge,Actual_battery_charge_.*,Battery_temperature,Home_own_consumption_from_.*,Power_DC1,Power_DC2,Power_DC_Sum,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Solar_.*

# Ergebnis in der DbLog...
| 2020-10-16 13:28:57 | PV_Anlage_1 | Total_active_power_(powermeter)                       | -4.70 |
| 2020-10-16 13:29:52 | PV_Anlage_1 | Total_active_power_(powermeter)                       | -6.20 |

--- Ende Code ---

PV_KSEM

--- Code: ---M_AC_Power  <==> Total_active_power_(powermeter)

--- Ende Code ---

Viele Grüße
     Christian

ch.eick:
EDIT: Achtung, dieser Update kann entfallen und mit dem nächsten Post kombiniert werde, da das PV_Anlage_1_Bilanz Device in der Zwischenzeit komplett entfallen kann.


Hallo nochmal,

es gab da noch eine Unsauberkeit bei der Namensgebung für die Bilanz.
Das Device Dum.Energy wurde nun umbenannt in PV_Anlage_1_Bilanz. Die Plots ändern sich somit ebenfalls, da sie auf das Device in der Datenbank zugreifen.
Ein Vorteil dieser Änderung ist, dass bei einem SELECT in der Datenbank mit "DEVICE LIKE 'PV_Anlage_1%'" nun alle READING sehr einfach zu erreichen sind.

Alle diejenigen, die bereits vor diesem Datum eingestiegen sind müssen dann jedoch noch die Einträge in der DbLog umschreiben.
Als aller erstes solltet Ihr mal einen aktuellen Backup der Datenbank erstellen, bei einem Fehler durch die falsche Auswähl wäre ansonsten alles weg :-(

Danach geht's dann weiter

--- Code: ---# zuerst bitte genau nachschauen, dass Ihr auch die richtigen Einträge erwischt.
SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='Dum.Energy' AND TIMESTAMP > '2020-01-01 00:00:00' ORDER BY TIMESTAMP LIMIT 500;

# Es ist wichtig, dass Ihr den alten TIMESTAMP beibehaltet!
UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_Bilanz' WHERE DEVICE='Dum.Energy' AND TIMESTAMP > '2020-01-01 00:00:00';

--- Ende Code ---

Bei mir war dann ca. 20 Minuten später alles wieder schön :-)

Hier kommt auch mal ein schönes SELECT, für Devices, bei denen einige readings nicht so häufig geschrieben werden ;-)

--- Code: ---## Alle aktuellsten readings eines devices im letzten Tagesverlauf
SET @device = 'PV_Anlage_1_Bilanz';
SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM history t1
  INNER JOIN
   (select max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
      from history
      where DEVICE    = @device and
            TIMESTAMP > NOW() - INTERVAL 1 DAY
      group by READING) x
  ON x.TIMESTAMP = t1.TIMESTAMP AND
     x.DEVICE    = t1.DEVICE    AND
     x.READING   = t1.READING;

--- Ende Code ---

Gruß
    Christian

ch.eick:
EDIT 2020.10.21 Diese Bereinigung und Umstellung wäre dann nun erledigt. Ein späterer Schritt könnte dann noch das weitere Aufräumen der readings im PV_Anlage_1_API Device sein.

     Vielen Dank für Euer Gehör
           Christian

EDIT 2020.10.21 Das stateFormat wurde nochmals nachgearbeitet
EDIT 2020.10.21 Es wurde im PV_Schedule Device ein 5 Minuten Update für "get PV_Anlage_1_API 04_/auth/me" eingerichtet, damit das stateFormat die Aktuellen Werte häufiger aktualisiert.
EDIT 2020.10.21 Unten sind nun auch SQL zum Löschen in der Datenbank, aber erst einen Backup machen, wenn Ihr nicht sicher seit!
EDIT 2020.10.21 Im Dum.Energie => PV_Anlage_1_Bilanz tauchen jetzt in der Datenbank nur nor die Momentanwerte auf, die in der Form nicht benötigt werden.
                         Weiter unten in diesem Post habe ich noch eine sql SELECT eingefügt, um diese zu zeigen.
                         Der nächste Schritt ist nun das Löschen vom Dum.Energie bzw PV_Anlage_1_Bilanz und auch das löschen der restlichen DB Einträge.
                         Bitte achtet vorher darauf, dass Ihr alle Werte, die noch gewünscht sind zum PV_Anlage_1_API Device migriert habt.
EDIT 2020.10.21 Für die bereits in der DB erzeugten diff und max Werte habe die SQL Statements für die Migration unten hinzugefügt
EDIT 2020.10.21 Das stateFormat und userreading fon PV_Anlage_1API wurde für die Statistic_ der Bilanz angepasst. Ein Bild hängt an.
                         Momentanwerte werden hier nicht ins Log geschrieben, da sie nur der Übersicht dienen sollen.
EDIT 2020.10.20 Unten findet Ihr jetzt auch die SQL Statements für die Datenbank Änderung der readings.
EDIT 2020.10.20 Das PV_Anlage_1_Bilanz Device ist nun ebenfalls im Wiki aktualisiert. Das userreading holt nun die Werte aus dem _API Device.


Und das Aufräumen geht weiter.

Im Device PV_Anlage_1_Bilanz werden zur Zeit im userreading erweiterte Statistiken berechnet, die zum Device PV_Anlage_1_API gehören, was jedoch historisch bedingt noch nicht existiert hatte. Somit wandern diese readings dann jetzt in das richtige Device.

Betroffen sind zur Zeit folgende readings, die dann auch den Zusatz "Statistic_" bekommen
EDIT: Hierzu gibt es bereits einen aktuelleren Eintrag, damit die Namen besser zu denen vom Plenticore passen!

--- Code: ---PVDay
PVMonth
PVYear

GridFeedInDay
GridFeedInMonth
GridFeedInYear

TotalConsumptionDay
TotalConsumptionMonth,
TotalConsumptionYear

--- Ende Code ---

Die Berechnungen für die Momentan Werte wird erst einmal bleiben, da diese ja nicht statistisch sind.

Im Device PV_Anlage_1_API sind die oben genannten Werte dann noch in Watt und werden anschließend im PV_Anlage_1_Bilanz Device in Kilowatt dargestellt.

Die Aktualisierung ist bereits im Wiki. Bitte beachtet, dass im Anschluss noch die Änderung im Bilanz Device folgen muss, da ansonsten doppelte werte in der Datenbank sein werden.
Bisherige Werte aus dem Bilanz Device können dann natürlich in der Datenbank später dem neuen Device zugeordnet werden und gehen somit nicht verloren. Die Vorgehensweise dürfte bereits bekannt sein.

Ich habe es natürlich jetzt schon gemacht, aber bitte prüft die SQL Statements vorher und macht auch vorher einen Backup.
EDIT: Achtung, an dieser Stelle kann man auch direkt zu den endgültigen Namen vom 2020.10.22 umziehen.

--- Code: ---UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_TotalConsumptionYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='TotalConsumptionYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_PVYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='PVYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInDay', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInDay' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInMonth', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='Statistic_GridFeedInYear', VALUE=round(VALUE*1000,2)
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='GridFeedInYear' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='max_month_Statistic_PVMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='max_month_PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='max_month_Statistic_PVTotalMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='max_month_PVTotalMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='diff_week_Statistic_PVMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='diff_week_PVMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

UPDATE history SET TIMESTAMP=TIMESTAMP, DEVICE='PV_Anlage_1_API', READING='diff_week_Statistic_PVTotalMonth'
   WHERE DEVICE='PV_Anlage_1_Bilanz' and READING='diff_week_PVTotalMonth' AND TIMESTAMP > '2020-01-01 00:00:00';

###################### Achtung, das ist zum Löschen, also Backup machen oder sich sicher sein :-) ###################

delete FROM history WHERE DEVICE='PV_Anlage_1_Bilanz' AND TIMESTAMP > '2020-01-01 00:00:00';

--- Ende Code ---

Die Reste vom Dum.Energie bzw PV_Anlage_1_Bilanz Device in der Datenbank

--- Code: ---SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_Bilanz' AND TIMESTAMP > '2020-01-01 00:00:00' order BY TIMESTAMP limit 500;

snip ...
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | AutarkyQuote         | 90    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | GridConsumption      | 20    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | GridFeedIn           | 0     |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | PV                   | 641   |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | PVTotal              | 734   |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | SelfConsumptionQuote | 87    |
| 2020-10-21 10:45:00 | PV_Anlage_1_Bilanz | TotalConsumption     | 714   |
snip ...

--- Ende Code ---

Der Trigger von diesem Device ist im PV_Schedule enthalten und kann dann auch raus.


Gruß
   Christian

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln