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

[ch.eick]

Hallo,
ich habe ein kleines Problem:
Ich habe gestern einen Speicher an meinem Kostal nachgerüstet.
Die Variable "Actual_Battery_charge_usable_P" ist 0. Daher hab ich weiter geschaut:

Ich habe gesehen, dass das Reading Battery_work_capacity leer ist. Wie bekomme ich diese gefüllt?

Das kommt vom Plenticore.
Ich hatte dazu vor 2 Wochen auch mal was geschrieben, da es bei mir auch aufeinmal weg gewesen ist.
- Man kann wohl auch die gleiche FW zum aktualisieren verwenden.
- Oder auch mal einen Soft Reset über WR_1_API ausprobieren.
- Eventuell im Plenticore mal den Speicher weg konfigurieren und dann wieder neu eintragen.

[kaiman]

Das kommt vom Plenticore.
Ich hatte dazu vor 2 Wochen auch mal was geschrieben, da es bei mir auch aufeinmal weg gewesen ist.
- Man kann wohl auch die gleiche FW zum aktualisieren verwenden.
- Oder auch mal einen Soft Reset über WR_1_API ausprobieren.
- Eventuell im Plenticore mal den Speicher weg konfigurieren und dann wieder neu eintragen.

Danke für den Input.
Es hat gereicht den Wert ,,Batterieentladung ab Netzbezug von " einfach nochmal auf 50 zu ändern und speichern. Jetzt werden die Werte gefüllt.

[ch.eick]

Hallo zusammen.

Das PV_KI_Prognose.py Skript wurde aktualisiert.
Im Skript waren leider Fehler bei der Berechnung der Tages Werte für fc1, die jetzt behoben wurden.

[MaHue]

Hallo zusammen,
ich habe leider das Problem, dass seit einer Woche die Daten für WR_1_API nicht mehr aktualisiert werden.
Anscheinend sperrt sich der Kostal Plenticore immer, wenn die entsprechende Anfrage (get WR_1_API 20_Statistic_EnergyFlow) abgesetzt wird.
Wenn ich dann die Website vom Wechselrichter aufrufe, sagt sie "Entweder wurde noch kein Passwort festgelegt oder das Konto wurde aus Sicherheitsgründen gesperrt. Bitte geben Sie den Master Key (siehe Typenschild) sowie ein neues Passwort ein."
Setze ich das Passwort neu und lege es mittels {KeyValue("store","PW_WR_1_API_user","PASSWORT")} in fhem ab, ist es nach dem nächsten Abruf der Statistik wieder gesperrt.

Die manuelle Ausführung der Anmeldung laut Wiki

1. get WR_1_API 01_auth_start
   2. get WR_1_API 02_auth_finish
   3. get WR_1_API 03_auth_create_session
   4. Die Rückmeldung vom Plenticore wird gelesen und es sollte eine SessionId bestehen, mit der nun alle weiteren Abfragen laufen

liefert mir in Schritt 2 noch Token und Signature, führt aber in Schritt 3 zu

Code Auswählen Erweitern

{"message":"invalid transaction"}
Hat jemand eine Idee, woran das liegen bzw. wie ich das beheben kann?

Typenbezeichnung	PLENTICORE plus 10
UI-Version	01.28.10771
MC-Version	01.78
IOC-Version	01.78
HW-Version	0202

[ch.eick]

Hallo zusammen,
ich habe leider das Problem, dass seit einer Woche die Daten für WR_1_API nicht mehr aktualisiert werden.

< snip >

Hat jemand eine Idee, woran das liegen bzw. wie ich das beheben kann?

Typenbezeichnung	PLENTICORE plus 10
UI-Version	01.28.10771
MC-Version	01.78
IOC-Version	01.78
HW-Version	0202

Im WR_1_API sind noch readings mit auth im Namen, die könntest Du noch vorher nochmal löschen.
Das Passwort sollte möglichst keine spezielle Sonderzeichen haben. Teste die Abfrage nochmal wie im Wiki beschrieben.

VG Christian

[MaHue]

Im WR_1_API sind noch readings mit auth im Namen, die könntest Du noch vorher nochmal löschen.
Das Passwort sollte möglichst keine spezielle Sonderzeichen haben. Teste die Abfrage nochmal wie im Wiki beschrieben.

VG Christian

Danke, ich habe alle auth_-Readings gelöscht und die Authentizierung dann noch mal versucht - jetzt läuft's wieder.

[ch.eick]

Hallo zusammen,
Dieser Thread ist nicht tot Es läuft halt nur alles wie es soll.

VG Christian

[hausbesetzer]

Hallo zusammen,

super tolle Lösung! Ich habe die Devices WR_1 und WR_1_API erfolgreich am laufen. Da seit heute meine Anlage läuft, sehe ich nun auch endlich Daten .

Ich stehe nur leider vor einem kleinen Rätsel, zu dem mir keine Lösung einfällt: Das Reading P_DC3 bekomme ich nicht in mein DBLog übertragen...

Das Reading an sich hat im FHEM valide Daten, d.h. das Auslesen mit Modbus vom Wechselrichter funktioniert. Im Attribut DbLogInclude habe ich das Reading ergänzt:

Code Auswählen Erweitern

Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Battery_MaxChargePowerLimitAbs,Battery_.*SOC,P_DC1,P_DC2,P_DC3,Total_.*,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_Temp,Solar_WR_.*,Solar_middayhigh.*,SW_.*,P_limit_from_EVU.*
Im DbLog-Device steht das Attribut DbLogSelectionMode auf Exclude/Include.

Die Readings P_DC1 und P_DC2 werden sehr wohl ins DBLog übertragen. Eigentlich sehe ich keinen Grund, warum das nicht auch für P_DC3 passiert.

Oder habe ich etwas übersehen?

Viele Grüße,
 Peter

[ch.eick]

Ich stehe nur leider vor einem kleinen Rätsel, zu dem mir keine Lösung einfällt: Das Reading P_DC3 bekomme ich nicht in mein DBLog übertragen...
Das Reading an sich hat im FHEM valide Daten, d.h. das Auslesen mit Modbus vom Wechselrichter funktioniert. Im Attribut DbLogInclude habe ich das Reading ergänzt:

Code Auswählen Erweitern

Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Battery_MaxChargePowerLimitAbs,Battery_.*SOC,P_DC1,P_DC2,P_DC3,Total_.*,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_Temp,Solar_WR_.*,Solar_middayhigh.*,SW_.*,P_limit_from_EVU.*

Hallo Peter,
da wird dann wohl der Event fehlen. Ich habe am String 3 bei mir den Speicher dran und deshalb ist P_DC3 immer 0

Hier wäre das geänderte Attribut

Code Auswählen Erweitern

attr WR_1 event_on_change-reading Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_I,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Battery_MaxChargePowerLimitAbs,Battery_.*SOC,Home_own_consumption.*,P_DC1,P_DC2,P_DC3,Solar_.*,Total_.*,SW_.*,.*_yield,Inverter_state.*,Inverter_Generation_P_Actual.*,Solar_Calculation_fc.*_day

VG   Christian

[hausbesetzer]

Logo! Das war's!

Vielen Dank für die schnelle und kompetente Unterstützung Christian!

Viele Grüße,
 Peter

[kaiman]

Hallo Christian,

Ich habe ein Problem bei der Quartalsberechnung. Alle Werte werden berechnet außer die des Speichers.
Ich habe mal aus deinem Post zitiert.

...

Nach dem Ausführen sollte es dann so aussehen, Q4 hat den "previos" Eintrag, da wir ja noch nicht April haben.

Code Auswählen Erweitern

...
Q3
Q3_SW_Statistic_EnergyHome 1623
Q3_SW_Statistic_EnergyHomeFeedInGrid 4797
Q3_SW_Statistic_EnergyHomeGrid 16
Q3_SW_Statistic_EnergyHomePv 1186
Q3_SW_Statistic_EnergyHomePvSum 1607
Q3_SW_Statistic_EnergyPv1 2019
Q3_SW_Statistic_EnergyPv2 1614
Q3_SW_Statistic_EnergyPv4 1260
Q3_SW_Statistic_EnergyPv5 1797
Q3_SW_Statistic_TotalConsumption 1623
Q3_SW_Statistic_Yield 6404
Q3_Statistic_EnergyHomeBat 421
...

VG
    Christian

Der Eintrag Q3_Statistic_EnergyHomeBat fejkt bei mir. Habe den Speicher erst seit Juli. Die Anlage schon länger. Liegt das daran?
In der Spalte für das Jahr wird der Wert für das Jahr korrekt angezeigt.

Lg
Achim

[ch.eick]

Ich habe ein Problem bei der Quartalsberechnung. Alle Werte werden berechnet außer die des Speichers.
< snip >
Der Eintrag Q3_Statistic_EnergyHomeBat fehlt bei mir. Habe den Speicher erst seit Juli. Die Anlage schon länger. Liegt das daran?
In der Spalte für das Jahr wird der Wert für das Jahr korrekt angezeigt.

Hallo Achim,
es könnte sein, dass für den Speicher der erste Werte im Juli in der datenbank fehlt.

Im SQL wird nach TIMESTAMP gefiltert "%Y-%m-01", somit muss am 01. des Monats auch ein Wert für Statistic_EnergyHomeBat_* vorhanden sein. Falls der fehlt könntest Du den aller ersten Wert zum Zeitpunkt Deiner Speicher Installation auf den TIMESTAMP der anderen Werte am 01. des Monats kopieren, oder den TIMESTAMP überschreiben.

VG   Christian

[kaiman]

Danke für die Aufklärung, ja der Speicher war nicht am 1. des Monats vorhanden.

Ich schaue mir das die nächste Woche einmal an.

Lg

[trupf]

Ich habe mal noch eine Frage zu den LogDBRep_Statistic...

Die schreiben bei mir in eine MariaDB SQL-Datenbank in das Device "PV_1_API". Aber alle geschriebenen Werte sind =0. Das sieht dann bei einer Abfrage in der DB direkt so aus:
| 2023-08-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_EnergyHomePvSum_Month | 0.0000 | NULL |
| 2023-09-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_EnergyHomePvSum_Month | 0.0000 | NULL |
| 2022-01-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_Yield_Month          | 0.0000 |      |

Gibt es da noch einen Fehler das die Werte nicht korrekt berechnet werden? Mir ist unklar wie das ganze funktionieren soll und wo und wie die zu schreibenden Werte berechnet werden sollten. Offensichtlich funktioniert die Berechnung ja auch nicht.

[ch.eick]

Ich habe mal noch eine Frage zu den LogDBRep_Statistic...

Die schreiben bei mir in eine MariaDB SQL-Datenbank in das Device "PV_1_API". Aber alle geschriebenen Werte sind =0. Das sieht dann bei einer Abfrage in der DB direkt so aus:
| 2023-08-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_EnergyHomePvSum_Month | 0.0000 | NULL |
| 2023-09-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_EnergyHomePvSum_Month | 0.0000 | NULL |
| 2022-01-01 23:59:58 | PV_1_API | calculated | calculated | max_month_Statistic_Yield_Month          | 0.0000 |      |

Gibt es da noch einen Fehler das die Werte nicht korrekt berechnet werden? Mir ist unklar wie das ganze funktionieren soll und wo und wie die zu schreibenden Werte berechnet werden sollten. Offensichtlich funktioniert die Berechnung ja auch nicht.

Hallo trupf

Ich denke Du wirst noch alte DbRep Definitionen verwenden, die nur noch als Beispiele dienen sollten. Die wenigsten werden das wirklich verwenden, was ich an den wenigen Rückfragen ausmache

An Deinem DB Auszug sehe ich, dass sich der Job wohl auf die Statistic_* und nicht auf die SW_Statistic_* bezieht, was aber bei nur einem WR egal wäre. Du solltest also Statistic_EnergyHomePvSum_Month und Statistic_Yield_Month als Einträge in Deiner Datenbank haben. Wenn das nicht so ist, werden die bei Dir nicht gelogged.

Dann sollte die DbRep Definitionen so aussehen

Code Auswählen Erweitern

defmod LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month DbRep LogDB
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month DbLogExclude .*
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month aggregation month
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month allowDeletion 1
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month comment Version 2020.10.23 15:00\
Dieser Wert ist die gesamte Dc Lieferung der PV Anlage inklusive Batterie im Monat.\
Gestartet über PV_Schedule am ersten des Monats.
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month device WR_1_API
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month reading SW_Statistic_EnergyHomePvSum_Month
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month room System
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month timestamp_begin current_year_begin
attr LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month timestamp_end previous_month_end

Und im DB_Service_Schedule Device (früher PV_Schedule) folgender maßen aufgerufen werden.

Code Auswählen Erweitern

set LogDBRep_Statistic_EnergyHomePvSum_Year_max_Month maxValue writeToDB

Nach dem Aufruf müsste folgendes im DbRep Device stehen

Code Auswählen Erweitern

READINGS:
     2023-10-01 01:13:01   2023-01-31_23-57-03__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-01 269854.0000
     2023-10-01 01:13:01   2023-02-28_23-57-03__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-02 625267.0000
     2023-10-01 01:13:01   2023-03-31_23-57-03__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-03 805980.0000
     2023-10-01 01:13:01   2023-04-30_23-57-03__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-04 748631.0000
     2023-10-01 01:13:01   2023-05-31_23-57-02__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-05 759929.0000
     2023-10-01 01:13:01   2023-06-30_23-57-02__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-06 760850.0000
     2023-10-01 01:13:01   2023-07-31_23-57-02__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-07 837835.0000
     2023-10-01 01:13:01   2023-08-31_23-57-02__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-08 649154.0000
     2023-10-01 01:13:01   2023-09-30_23-57-02__WR_1_API__SW_Statistic_EnergyHomePvSum_Month__MAX__2023-09 734464.0000

Hier gibt es dann einen Unterschied zu den reading Namen innerhalb der Datenbank.
Den Eintrag am 01.01. mit VALUE 0 habe ich, wenn ich mich recht erinnere von Hand eingetragen, damit der Graph besser aussieht.

Code Auswählen Erweitern

select * from history
where DEVICE="WR_1_API"
  and TIMESTAMP > "2023-01-01"
  and READING = "max_month_SW_Statistic_EnergyHomePvSum_Month"
;

'2023-01-01 23:59:58', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '0.0000', NULL
'2023-01-31 23:57:03', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '269854.0000', NULL
'2023-02-28 23:57:03', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '625267.0000', NULL
'2023-03-31 23:57:03', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '805980.0000', NULL
'2023-04-30 23:57:03', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '748631.0000', NULL
'2023-05-31 23:57:02', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '759929.0000', NULL
'2023-06-30 23:57:02', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '760850.0000', NULL
'2023-07-31 23:57:02', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '837835.0000', NULL
'2023-08-31 23:57:02', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '649154.0000', NULL
'2023-09-30 23:57:02', 'WR_1_API', 'HTTPMOD', '', 'max_month_SW_Statistic_EnergyHomePvSum_Month', '734464.0000', NULL

Sollte es bei Dir wegen der MariaDB Probleme geben, dann gibt es im Forum noch einen Thread mit Support zu DbRep. Das ist ein Grund, warum ich darmals auf die standard Module gesetzt habe, damit man den Support auf mehrere Schultern verteilen kann. Im DbRep setzt Heiko das SQL auf die Möglichkeiten der jeweiligen Datenbank um.

Beim DbRep bin ich bei FVERSION 93_DbRep.pm:v8.52.11-s27975/2023-09-17

VG  Christian

Hier mal ein Beispiel aus Grafana für 2022
Du darfst diesen Dateianhang nicht ansehen.