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

[papa]

vielleicht hast du/ihr schon gesehen dass ich ein Modul SolarForecast gebaut habe (https://forum.fhem.de/index.php/topic,102112.msg1123116.html#msg1123116) was auch eine informative Grafik (Anhang) enthält.

Gibt es da schon ein HowTo, wie das ganze aufgesetzt wird?

[DS_Starter]

Moin,

die Vorgehensweise habe ich unter dem Punkt Definition in der Hilfe zum Modul (help solarforecast de) beschrieben.
Außerdem werden nach der Definition des Devices im Grafikteil Hinweise gezeigt wenn etwas fehlen sollte.

Die Definition ist simpel:

   define <name> SolarForecast

Alles andere wird dann über Set-Kommandos hinterlegt. Die Grafik ist umfangreich mit Attributen konfigurierbar.
Ich habe soeben die Hilfe noch etwas überarbeitet und ins contrib geladen.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern


"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"


Fragen und Hinweise zum Modul wären dann sicherlich besser in diesem Thread aufgehoben damit das Thema hier nicht dadurch gestört wird.

LG,
Heiko

[plin]

Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Ich habe mich etwas schlau gemacht und gebastelt.  Aktuell lasse ich die DWD-Forcast-Werte 'Rad1h','Neff','R600','Azimuth','Altitude','SunD1','VV' sowie den Durchschnitt der erzeugten Leistung in das Modell einfließen.

In den Grafiken seht Ihr
- die erzeugte Leistung (Total_AC_active_power mit hoher zeitlcher Auflösung, gelbe Linie)
- den Mittelwert der verstrichenen Stunde dieser Leistung (yield, orangefarbene Linie)
- die Vorhersage des Modells (Forecast, Stundenbasis, blaue Linie)

Jetzt heißt es abwarten, denn meine Anlage ist erste Ende Oktober live gegangen und ich habe ca. 1.700 Datensätze als Basis für die Analyse. Aktuell kann die PV-Erzeung bei schlechtem Wetter schon recht gut vorhergesagt werden. Sommer muss noch trainiert werden  .

[ch.eick]

Ich habe mich etwas schlau gemacht und gebastelt.  Aktuell lasse ich die DWD-Forcast-Werte 'Rad1h','Neff','R600','Azimuth','Altitude','SunD1','VV' sowie den Durchschnitt der erzeugten Leistung in das Modell einfließen.

In den Grafiken seht Ihr
- die erzeugte Leistung (Total_AC_active_power mit hoher zeitlcher Auflösung, gelbe Linie)
- den Mittelwert der verstrichenen Stunde dieser Leistung (yield, orangefarbene Linie)
- die Vorhersage des Modells (Forecast, Stundenbasis, blaue Linie)

Jetzt heißt es abwarten, denn meine Anlage ist erste Ende Oktober live gegangen und ich habe ca. 1.700 Datensätze als Basis für die Analyse. Aktuell kann die PV-Erzeung bei schlechtem Wetter schon recht gut vorhergesagt werden. Sommer muss noch trainiert werden  .

Super, ich denke das wäre eine Bereicherung für Heiko, der in dem anderen Thread an einem DWD_Forecast Modul arbeitet.
Magst Du diesen Beitrag dort nochmal rein stellen, ich bin dort auch schon aktiv.

Gruß
   Christian

[Mumpitz]

EDIT 15:43: Ich habe den Eintrag nochmals überarbeitet. Bei Bedarf bitte nochmals lesen.

Hallo Mumpitz,

ich hatte nun auch den Loop im PV_Schedule

Code Auswählen Erweitern


2021.01.01 10:59:16.089 2: PV Überschuss wird in Batterie geladen. Keine Entladung
2021.01.01 10:59:22.835 2: PV Überschuss wird in Batterie geladen. Keine Entladung
...

Das hat folgende Bewandtnis:

Code Auswählen Erweitern


Das entsprechende DOELSEIF reagiert auf den Trigger [PV_Anlage_1_API:Battery_InternControl_MinSoc]
dann erfolgt ein "get PV_Anlage_1_API 22_Battery_InternControl" , was wiederum den Status abfragt und wieder einen event-on-update erzeugt.


Um das nun abzustellen wäre eine Änderung der Events im PV_Anlage_1_API ,notwendig, was ich bereits getestet habe.

Code Auswählen Erweitern


attr PV_Anlage_1_API event-on-change-reading Battery_.*
attr PV_Anlage_1_API event-on-update-reading auth_.*,Statistic_Autarky.*,Statistic_Energy_.*arge.*,Statistic_EnergyFeedIn.*,Statistic_EnergyHome.*, Statistic_EnergyPv[1|2].*,Statistic_.*Consumption.*,Statistic_Yield.*


Weiterhin habe ich auch die Logmeldung im PV_Schedule etwas verändert, damit man sieht aus welchem Device die Meldung kommt.

Code Auswählen Erweitern


snip...
################################################################################################################
## 6 Wenn die Ladung im Herbst/Winter unter MinSoc geht allen PV Überschuss in die Batterie laden
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] <= [PV_Anlage_1_API:Battery_InternControl_MinSoc])
  (get BYD_Status BatteryInformation)
  (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])
  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"})

################################################################################################################
## 7 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90)

  (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption 50)
  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 2, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})


VG
   Christian

Nun ist endlich mal wieder der Fall eingetroffen, dass die Batterie über 90% gekommen ist und den Entlademodus freigegeben hat. Leider komme ich dadurch wieder in den Loop und die Bilanz wird nicht mehr aktualisiert:

Code Auswählen Erweitern


2021.01.22 12:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben
2021.01.22 11:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben


Hast du eine Idee wie wir diesen rausbringen?

[ch.eick]

Nun ist endlich mal wieder der Fall eingetroffen, dass die Batterie über 90% gekommen ist und den Entlademodus freigegeben hat. Leider komme ich dadurch wieder in den Loop und die Bilanz wird nicht mehr aktualisiert:

Code Auswählen Erweitern


2021.01.22 12:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben
2021.01.22 11:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben

Hast du eine Idee wie wir diesen rausbringen?

Ich hatte hier schon fast alles fertig geschrieben und dann ist es mir aufgefallen

Der DOELSEIF Pfad von cmd_5 und cmd_6 wird genau von zwei Events ausgelöst, die aus dem PV_Anlage_1_API Device kommen
- Battery_Info_SoC
- Battery_InternControl_MinSoc

Diese sollten im PV_Anlage_1_API wie folgt gesetzt sein
- event-on-change-reading Battery_.*
- Achtung, vorher war das mal bei event-on-update-reading eingetragen, da muss Battery_.* raus

Die Ursache sehe ich jedoch einfach darin, dass der Plenticore ja noch weiter Läd, als nur bis Soc 90 und somit natürlich noch mehr Events kommen.
Auch beim Entladen stoppt er ja auch nicht sofort und der Eigenverbrauch in der Nacht geht ja auch aus der Batterie.

Versuche es einfach mal mit den zwei zusätzlichen and Statements, die stellen einfach Fest, ob Battery_MinHomeConsumption bereits gesetzt wurde oder noch nicht.
Das sollte so klappen.

Ich hatte bereits bei mir die cmd_* Reihenfolge angepasst, so dass es jetzt mit Deiner Reihenfolge übereinstimmen sollte.
Ich verwende bereits im PV_Anlage_1_API Device die HTTPMOD Version 4.0.17, diese bietet das Attribut "set2204FollowGet 22_Battery_InternControl" , was nach dem set Aufruf als nächstes direkt ein get ermöglicht.
Das hatte ich im Forum bereits geschrieben. Deshalb steht im PV_Schedule das get bereits auf Kommentar.

Code Auswählen Erweitern


################################################################################################################
## 5 Wenn die Ladung im Herbst/Winter unter MinSoc geht allen PV Überschuss in die Batterie laden
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] <= [PV_Anlage_1_API:Battery_InternControl_MinSoc] and
  [PV_Anlage_1_API:Battery_MinHomeConsumption] <= 100 )

  (get BYD_Status BatteryInformation)
  ({Log 3, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"})
  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])

##  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 3, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"})

################################################################################################################
## 6 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90 AND
  [PV_Anlage_1_API:Battery_MinHomeConsumption] > 100)

  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption 50)
  ({Log 3, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})

##  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 3, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})



VG
   Christian

[ch.eick]

@Mumpitz
Beim PV_Schedule war der Fehlerteufel da das "> 100" muss ein "gt 100" sein, sorry.

Code Auswählen Erweitern


################################################################################################################
## 6 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90 and
  [PV_Anlage_1_API:Battery_MinHomeConsumption] gt 100 )

  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption 50)
  ({Log 3, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})


[Mumpitz]

@Mumpitz
Beim PV_Schedule war der Fehlerteufel da das "> 100" muss ein "gt 100" sein, sorry.

Code Auswählen Erweitern


################################################################################################################
## 6 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90 and
  [PV_Anlage_1_API:Battery_MinHomeConsumption] gt 100 )

  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption 50)
  ({Log 3, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})


Bist du sicher? Aus meiner bescheidenen Sicht stimmt das >. Es haben sich eher folgende Fehler eingeschlichen:

bei cmd_5:
{Log 2, "PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung"}



bei cmd_6:
{Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"}


Sowie bei beiden heisst das Reading nicht mehr

Code Auswählen Erweitern

Battery_MinHomeConsumption sondern

Code Auswählen Erweitern

Battery_InternControl_MinHomeConsumption

stimmts?
Gruess

[ch.eick]

Bist du sicher? Aus meiner bescheidenen Sicht stimmt das >. Es haben sich eher folgende Fehler eingeschlichen:

bei cmd_5:
{Log 2, "PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung"}
bei cmd_6:
{Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"}
Sowie bei beiden heisst das Reading nicht mehr

Code Auswählen Erweitern

Battery_MinHomeConsumption sondern

Code Auswählen Erweitern

Battery_InternControl_MinHomeConsumption

Hey, Du bist echt gut.
Dann habe ich es jetzt so verschlimmbessert

Code Auswählen Erweitern


################################################################################################################
## 5 Wenn die Ladung im Herbst/Winter unter MinSoc geht allen PV Überschuss in die Batterie laden
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] <= [PV_Anlage_1_API:Battery_InternControl_MinSoc] and
  [PV_Anlage_1_API:Battery_InternControl_MinHomeConsumption] <= 100 )

  (get BYD_Status BatteryInformation)
  ({Log 3, "PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung"})
  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])

################################################################################################################
## 6 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90 and
  [PV_Anlage_1_API:Battery_InternControl_MinHomeConsumption] > 100 )

  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption 50)
  ({Log 3, "PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben"})

################################################################################################################
## 7 Test zur Begrenzung des MaxSoc
##
DOELSEIF
(([Astro:ObsSeason] eq "Frühjahr" or [Astro:ObsSeason] eq "Sommer") and
[07:00-20:00|1234] and [+180] )
 
  (set PV_Anlage_1_API 23_09_Battery_ExternControl_MaxSocRel 90)
  ({Log 3, "PV_Schedule cmd_7 : Batterie MaxSoc halten"})


unter cmd_7 findest Du zur Entschädigung schon mal die nächste Idee.
Von 7-20 Uhr wird alle 180 Minuten der Ladezustand der Batterie auf Soc 90 begrenzt, damit sie nicht permanent auf Soc 100 geladen wird.
Bei mir komme ich im Sommer noch mit 40% aus der Nacht und denke so, dass ich dann zwischen 30 und 90 pendle.
Das gilt dann für Montags bis Donnerstags und am Wochenende kann man es dann mal richtig krachen lassen

Gruß
    Christian

[Mumpitz]

Code Auswählen Erweitern



################################################################################################################
## 7 Test zur Begrenzung des MaxSoc
##
DOELSEIF
(([Astro:ObsSeason] eq "Frühjahr" or [Astro:ObsSeason] eq "Sommer") and
[07:00-20:00|1234] and [+180] )
 
  (set PV_Anlage_1_API 23_09_Battery_ExternControl_MaxSocRel 90)
  ({Log 3, "PV_Schedule cmd_7 : Batterie MaxSoc halten"})


unter cmd_7 findest Du zur Entschädigung schon mal die nächste Idee.
Von 7-20 Uhr wird alle 180 Minuten der Ladezustand der Batterie auf Soc 90 begrenzt, damit sie nicht permanent auf Soc 100 geladen wird.
Bei mir komme ich im Sommer noch mit 40% aus der Nacht und denke so, dass ich dann zwischen 30 und 90 pendle.
Das gilt dann für Montags bis Donnerstags und am Wochenende kann man es dann mal richtig krachen lassen

Gruß
    Christian

Herrlich, genau wegen solchen Ideen bin ich hier aktiv!
Nun, denken wir mal etwas weiter. Meiner Meinung nach wäre hier zb auch die richtige Stelle, den Forecast einzubauen. Denn auch im Sommer, wenn er schlechtes Wetter hat am nächsten Tag, ist irgendwann Ende Feuer der Batterie. Da reuen mich dann die 10%, bei mir 1kWh. Daher schlage ich vor, dieses cmd_7 nur zu triggern, wenn der Forecast am nächsten Tag mehr als 15 kWh oder bis 12 Uhr 8 kWh prognostiziert. Die Werte müsste man dann noch einstellen könne, z.B. in der config.

Weiter würde ich vorschlagen, das PV_Schedule DOIF auseinanderzunehmen und die Batteriesteuerung in ein eigenes DOIF zu übernehmen. Denke es wäre übersichtlicher!

Nächste Idee was mir schon länger im Kopf herum geistert. Du hast bei dir die Begrenzung am Wochenende ausser Kraft gesetzt. Ich finde das etwas undynamisch. Es wäre doch viel besser, Wochentagsprofile zu erstellen, nicht?

Bei mir zu Hause z.b ist die ganze Familie an einzelnen Wochentagen grösstenteils abwesend. An meistens den gleichen Tagen wird gewaschen. Dies könnte man doch ebenfalls berücksichtigen mit der Lademenge...

Zum anfangen würde ich gerne mal erheben, welchen Gesamtenergie Verbrauch ich pro Wochentag hatte? Hast du als SQL Freak hier einen Ansatz?

Falls nein, würde ich mal mit einem Dummy und einem DOIF beginnen, welches mir jeden Abend in ein Reading im Wochentagsdummy den Wert um 23:59 schreibt und addiert.

Ich bin gespannt auf deine Meinung!

[ch.eick]

Hi,
ich schau mal was mir dazu morgen so alles einfällt.
Leider geht es hier beim Nonintrusive Load Monitoring (NILM) nicht so richtig weiter, bzw los. Es ist halt mega komplex.

cmd_7 war ja nur ein Test für die Externe Batterie Kontrolle, wie es überhaupt geht, da arbeite ich ja gerade dran, wenn es bei der Leistungsprognose stockt

VG
   Christian

[ch.eick]

Nun, denken wir mal etwas weiter.
Meiner Meinung nach wäre hier zb auch die richtige Stelle, den Forecast einzubauen. Denn auch im Sommer, wenn er schlechtes Wetter hat am nächsten Tag, ist irgendwann Ende Feuer der Batterie.
Da reuen mich dann die 10%, bei mir 1kWh.

Das sehe ich auch so

Weiter würde ich vorschlagen, das PV_Schedule DOIF auseinanderzunehmen und die Batteriesteuerung in ein eigenes DOIF zu übernehmen. Denke es wäre übersichtlicher!

Da habe ich Dir den ersten Entwurf zugesendet. Das ist also so gut wie erledigt.

Nächste Idee was mir schon länger im Kopf herum geistert. Du hast bei dir die Begrenzung am Wochenende ausser Kraft gesetzt. Ich finde das etwas undynamisch.
Es wäre doch viel besser, Wochentagsprofile zu erstellen, nicht?
Daher schlage ich vor, dieses cmd_7 nur zu triggern, wenn der Forecast am nächsten Tag mehr als 15 kWh oder bis 12 Uhr 8 kWh prognostiziert.
Die Werte müsste man dann noch einstellen könne, z.B. in der config.

In die _config werde ich dann Prozent Werte einarbeiten, die dann die Limitierung im Verhältnis zur Speichergröße darstellen. Das passt eventuell besser zum Haushaltsverbrauch, da der je die Grundlage der Speichergöße sein sollte.

Bei mir zu Hause z.b ist die ganze Familie an einzelnen Wochentagen grösstenteils abwesend. An meistens den gleichen Tagen wird gewaschen. Dies könnte man doch ebenfalls berücksichtigen mit der Lademenge...

Das wären dann Lademengen, anhand von Verbrauchsstatistiken plus einen Sicherheitszuschlag, wenn man es Tageunabhängig betrachtet.

Zum Anfangen würde ich gerne mal erheben, welchen Gesamtenergie Verbrauch ich pro Wochentag hatte? Hast du als SQL Freak hier einen Ansatz?
Falls nein, würde ich mal mit einem Dummy und einem DOIF beginnen, welches mir jeden Abend in ein Reading im Wochentagsdummy den Wert um 23:59 schreibt und addiert.

Natürlich holen wir das aus der Datenbank Bitte keine separaten Statistiken über DUMMYs anfertigen, das macht keinen Sinn.
Wiederkehrende Reports kann man dann als DbRep einbauen.

Ich vermute, Du hast keinen EVU Zähler, den Du abliest, dann wäre das eine DB Abfrage des readings Statistic_EnergyHome_Day im Device PV_Anlage_1_API als maxValue .

[ch.eick]

Nächste Idee was mir schon länger im Kopf herum geistert. Du hast bei dir die Begrenzung am Wochenende ausser Kraft gesetzt. Ich finde das etwas undynamisch.
Es wäre doch viel besser, Wochentagsprofile zu erstellen, nicht?
Daher schlage ich vor, dieses cmd_7 nur zu triggern, wenn der Forecast am nächsten Tag mehr als 15 kWh oder bis 12 Uhr 8 kWh prognostiziert.
Die Werte müsste man dann noch einstellen könne, z.B. in der config.

In die _config werde ich dann Prozent Werte einarbeiten, die dann die Limitierung im Verhältnis zur Speichergröße darstellen.
Das passt eventuell besser zum Haushaltsverbrauch, da der je die Grundlage der Speichergöße sein sollte.

Ich habe da mal folgende Werte aus den Devices zusammen gesucht:

Code Auswählen Erweitern


Inverter_Max_Power 6999   aus dem WR Device die 70% Grenze in Deutschland, für andere Länder wird da 100%
Power_class 10            Das ist ein Plenticore 10 mit 10kWp Leistung ==> 10000 Wp * 70% => 7000 Wp

(round(Inverter_Max_Power / 1000 , 0)) * 100 / Power_class = > 70
    70 wäre dann Deutschland
  100 für Länder ohne 70 % Regelung

Für Deutschland müsste man die Spitze über 70 % zum Laden des Speichers treffen, was im Plenticore als "inteligente Batteriesteuerung" bezeichnet wird.
Der Netzbetreiber freut sich natürlich auch, wenn man die PV Spitze im Haus zurück behält, das wird in den nächsten Jahren noch ein größeres Problem werden.

=================================================================
Battery_Info_WorkCapacity 9252   aus dem API Device
Durchschnittlicher Hausverbrauch in der Nacht von 20:00 - 08:00 Uhr = 12h * 500 Watt = > 6 kWh
Bei mir 60% von 9252 also rund 5,5 kWh , was ich letzten Sommer beobachtet hatte.

Nun sollte es dann in der PV_Anlage_1_Speicher_1_ExternControl readings geben, die mit dem Verbrauch auf Tagesbasis des jeweiligen Haushaltes gefüllt werden.
z.B.
Home_own_consumption_from_battery_plan_[0-9]      [0-9] entspricht der DOIF commandref
Home_own_consumption_from_battery_plan_start      ist die Startzeit HH:mm
Home_own_consumption_from_battery_plan_end       ist die end Zeit HH:mm
Ich denke eine start/end Zeit pro Tag wäre etwas drüber :-)

=================================================================
Das wären dann die Prognosezeiten, bzw. die Werte pro Stunde, wenn man noch detaillierter entscheiden mag
Solar_Calculation_fc0_4h 2381
Solar_Calculation_fc0_day 4401
Solar_Calculation_fc0_rest 2381

Solar_Calculation_fc1_day 3195


Das wären dann mal meine ersten Gedanken, wobei ich das Tarifmodel der Schweiz mit teurem Strom am Morgen und am Abend nicht mit drin hätte Bitte schick mir das doch auch nochmal.

VG
   Christian

[Mumpitz]

Das wären dann mal meine ersten Gedanken, wobei ich das Tarifmodel der Schweiz mit teurem Strom am Morgen und am Abend nicht mit drin hätte Bitte schick mir das doch auch nochmal.

VG
   Christian

Also die Schweiz, zumindest in den Gemeinde in welchen ich wohnhaft war, kennt einen Normaltarif (T1) und einen Niedertarif (T2). Dieser setzt sich wie folgt zusammen:

Montag - Freitag: 07:00 - 19:00 durchgehend T1, Rest T2
Samstag & Sonntag: durchgehend T2

Der Preisunterschied beträgt dabei ca. 4 Rappen per kWh

[ch.eick]

Bei mir zu Hause z.b ist die ganze Familie an einzelnen Wochentagen grösstenteils abwesend. An meistens den gleichen Tagen wird gewaschen. Dies könnte man doch ebenfalls berücksichtigen mit der Lademenge...

Zum anfangen würde ich gerne mal erheben, welchen Gesamtenergie Verbrauch ich pro Wochentag hatte? Hast du als SQL Freak hier einen Ansatz?

Hallo Mumpitz,
ich fühlte mich da noch einer Antwort schuldig.

Letztes Jahr hatte ich da mal ein SQL geliefert, dass als sqlSpecial in DbRep eingegangen ist.
Die PV_Anlage_1_API readings werden ja regelmäßig in die DbLog geschrieben und Statistic_EnergyHome_Day wächst über den Tag an.

Mit diesem DbRep Device bekommst Du dann nun den Zähler und in einer weiteren Spalte noch die Differenzen berechnet
Die letzte Spalte gibt dann noch die Zeitdifferenz in Minuten an,  weil es nicht immer regelmäßig ist.

Das reading kannst Du ja auf den gewünschten Zählerwert *[Bat|Grid|Pv|PvSum] setzen.

set LogDBRep_select_Tagesverbrauch  sqlSpecial ReadingsDifferenceByTimeDelta

Code Auswählen Erweitern


defmod LogDBRep_select_Tagesverbrauch DbRep LogDB
attr LogDBRep_select_Tagesverbrauch DbLogExclude .*
attr LogDBRep_select_Tagesverbrauch device PV_Anlage_1_API
attr LogDBRep_select_Tagesverbrauch reading Statistic_EnergyHome_Day
attr LogDBRep_select_Tagesverbrauch room System
attr LogDBRep_select_Tagesverbrauch timestamp_begin previous_week_begin
attr LogDBRep_select_Tagesverbrauch timestamp_end previous_week_end


Mit aggregation und maxValue bekommst Du dann z.B. auch die Tageswerte.

set LogDBRep_select_Tagesverbrauch  maxValue display

Code Auswählen Erweitern


defmod LogDBRep_select_Tagesverbrauch DbRep LogDB
attr LogDBRep_select_Tagesverbrauch DbLogExclude .*
attr LogDBRep_select_Tagesverbrauch aggregation day
attr LogDBRep_select_Tagesverbrauch device PV_Anlage_1_API
attr LogDBRep_select_Tagesverbrauch reading Statistic_EnergyHome_Day
attr LogDBRep_select_Tagesverbrauch room System
attr LogDBRep_select_Tagesverbrauch timestamp_begin previous_week_begin
attr LogDBRep_select_Tagesverbrauch timestamp_end previous_week_end


Die zugrundeliegenden SQLs lassen sich natürlich auch, mit kleiner Anpassung, in Grafana anwenden

Viele Grüße
    Christian