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

[Mumpitz]

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

Ich habe bei mir ja bereits die täglichen Werte über einen Monat aus mit einem Chart visualisiert. Was ich bei meinem Post angesprochen habe ist, dass ich gerne auswerten würde, welchen Verbrauch ich an allen Montagen, allen Dienstagen, allen Mittwochen und so weiter hatte. Mit Hilfe dieser Erkenntnis könnte man auch die nötige Ladung der Batterie berechnen.

Mit deinem DbRep Device bekomme ich einfach die täglichen Werte. Weisst Du was ich meine?

[ch.eick]

Ich habe bei mir ja bereits die täglichen Werte über einen Monat aus mit einem Chart visualisiert. Was ich bei meinem Post angesprochen habe ist, dass ich gerne auswerten würde, welchen Verbrauch ich an allen Montagen, allen Dienstagen, allen Mittwochen und so weiter hatte. Mit Hilfe dieser Erkenntnis könnte man auch die nötige Ladung der Batterie berechnen.

Mit deinem DbRep Device bekomme ich einfach die täglichen Werte. Weisst Du was ich meine?

Moin,
dann sag das doch , das geht natürlich auch.

Hier mal ein SQL für einen Monat, mit dem Durchschnitt pro Wochentag (0 = So)

Code Auswählen Erweitern


MySQL [fhem]>
SELECT
       READING,
       cast(avg(VALUE) AS DECIMAL(6,2)) AS AVG,
       WEEKDAY
  FROM
    (
     SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d') AS DATE,
            READING,max(VALUE)                 AS VALUE,
            weekday(TIMESTAMP)                 AS WEEKDAY
     FROM history
     WHERE DEVICE    = 'PV_Anlage_1_API'
       AND READING   = 'Statistic_EnergyHome_Day'
       AND TIMESTAMP > '2021-01-01 00:00:00'
       AND TIMESTAMP < '2021-02-01 00:00:00'
     GROUP BY DATE
    ) t1
  GROUP BY WEEKDAY;
+--------------------------+---------+---------+
| READING                  | AVG     | WEEKDAY |
+--------------------------+---------+---------+
| Statistic_EnergyHome_Day | 6108.50 |       0 |
| Statistic_EnergyHome_Day | 7115.97 |       1 |
| Statistic_EnergyHome_Day | 8058.25 |       2 |
| Statistic_EnergyHome_Day | 4665.92 |       3 |
| Statistic_EnergyHome_Day | 8954.76 |       4 |
| Statistic_EnergyHome_Day | 7835.43 |       5 |
| Statistic_EnergyHome_Day | 6654.06 |       6 |
+--------------------------+---------+---------+


Oder halt alle Tageswerte sortiert nach Wochentagen

Code Auswählen Erweitern


MySQL [fhem]>
SELECT DATE,
       READING,
       VALUE,
       WEEKDAY
  FROM
    (
     SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d') AS DATE,
            READING,max(VALUE)                 AS VALUE,
            weekday(TIMESTAMP)                 AS WEEKDAY
     FROM history
     WHERE DEVICE    = 'PV_Anlage_1_API'
       AND READING   = 'Statistic_EnergyHome_Day'
       AND TIMESTAMP > '2021-01-01 00:00:00'
       AND TIMESTAMP < '2021-02-01 00:00:00'
     GROUP BY DATE
    ) t1
  ORDER BY WEEKDAY;
+------------+--------------------------+---------+---------+
| DATE       | READING                  | VALUE   | WEEKDAY |
+------------+--------------------------+---------+---------+
| 2021-01-04 | Statistic_EnergyHome_Day | 9916.82 |       0 |
| 2021-01-18 | Statistic_EnergyHome_Day | 5325.27 |       0 |
| 2021-01-11 | Statistic_EnergyHome_Day | 958.09  |       0 |
| 2021-01-25 | Statistic_EnergyHome_Day | 8233.81 |       0 |
| 2021-01-05 | Statistic_EnergyHome_Day | 958.07  |       1 |
| 2021-01-19 | Statistic_EnergyHome_Day | 9985.62 |       1 |
| 2021-01-12 | Statistic_EnergyHome_Day | 8113.84 |       1 |
| 2021-01-26 | Statistic_EnergyHome_Day | 9406.36 |       1 |
| 2021-01-20 | Statistic_EnergyHome_Day | 7488.43 |       2 |
| 2021-01-13 | Statistic_EnergyHome_Day | 7071.45 |       2 |
| 2021-01-27 | Statistic_EnergyHome_Day | 7723.69 |       2 |
| 2021-01-06 | Statistic_EnergyHome_Day | 9949.42 |       2 |
| 2021-01-21 | Statistic_EnergyHome_Day | 893.56  |       3 |
| 2021-01-14 | Statistic_EnergyHome_Day | 984.37  |       3 |
| 2021-01-28 | Statistic_EnergyHome_Day | 9932.60 |       3 |
| 2021-01-07 | Statistic_EnergyHome_Day | 6853.16 |       3 |
| 2021-01-01 | Statistic_EnergyHome_Day | 9533.68 |       4 |
| 2021-01-15 | Statistic_EnergyHome_Day | 8134.20 |       4 |
| 2021-01-29 | Statistic_EnergyHome_Day | 8335.38 |       4 |
| 2021-01-08 | Statistic_EnergyHome_Day | 9116.93 |       4 |
| 2021-01-22 | Statistic_EnergyHome_Day | 9653.61 |       4 |
| 2021-01-02 | Statistic_EnergyHome_Day | 9987.33 |       5 |
| 2021-01-16 | Statistic_EnergyHome_Day | 5114.72 |       5 |
| 2021-01-30 | Statistic_EnergyHome_Day | 6828.49 |       5 |
| 2021-01-09 | Statistic_EnergyHome_Day | 7374.64 |       5 |
| 2021-01-23 | Statistic_EnergyHome_Day | 9871.96 |       5 |
| 2021-01-03 | Statistic_EnergyHome_Day | 990.86  |       6 |
| 2021-01-17 | Statistic_EnergyHome_Day | 8195.89 |       6 |
| 2021-01-10 | Statistic_EnergyHome_Day | 8728.49 |       6 |
| 2021-01-24 | Statistic_EnergyHome_Day | 8701.01 |       6 |
+------------+--------------------------+---------+---------+


Wenn Du das eingebaut haben möchtest, dann müssten wir nochmal überlegen, wie und wo das rein passt.
Ein DbRep mit eigener SQL wäre das einfachste.

Viele Grüße
    Christian

[Mumpitz]

Moin,
dann sag das doch , das geht natürlich auch.

Gratuliere, echt kompliment wie schnell du das jeweils hinkriegst....

Hier mal meine Werte des Durchschnittlichen Totalverbrauchs im Januar:

Code Auswählen Erweitern

"2021-01-04" "Statistic_TotalConsumption_Day" "46426.59" "0"
"2021-01-05" "Statistic_TotalConsumption_Day" "42894.41" "1"
"2021-01-06" "Statistic_TotalConsumption_Day" "41022.96" "2"
"2021-01-07" "Statistic_TotalConsumption_Day" "41720.25" "3"
"2021-01-01" "Statistic_TotalConsumption_Day" "43064.02" "4"
"2021-01-02" "Statistic_TotalConsumption_Day" "41856.10" "5"
"2021-01-03" "Statistic_TotalConsumption_Day" "47740.83" "6"


Wenn ich die Werte so sehe macht es kaum Sinn, pro Wochentag andere Ladeprofile für die Batterie zu erstellen...

[ch.eick]

Hier mal meine Werte des Durchschnittlichen Totalverbrauchs im Januar:

Das DATE kannst Du übrigens raus nehmen, das macht beim avg über einen Monat keinen Sinn.

Hier mal mein Januar.

Code Auswählen Erweitern


+--------------------------------+----------+---------+
| READING                        | AVG      | WEEKDAY |
+--------------------------------+----------+---------+
| Statistic_TotalConsumption_Day | 21375.33 |       0 |
| Statistic_TotalConsumption_Day | 23539.65 |       1 |
| Statistic_TotalConsumption_Day | 21291.04 |       2 |
| Statistic_TotalConsumption_Day | 23754.45 |       3 |
| Statistic_TotalConsumption_Day | 20600.56 |       4 |
| Statistic_TotalConsumption_Day | 22537.18 |       5 |
| Statistic_TotalConsumption_Day | 28151.07 |       6 |
+--------------------------------+----------+---------+

Was hast Du denn da für Energieschleudern in Betrieb?
Bei läuft LWP HZ für 180m² 2 Wohnungen + WW für einen Haushalt, KWL, Pool, TV ganztägig, 4 Router, Home Office und der Rest vom Haushalt.
Du hast ja gut 20 kW höheren Verbrauch, ist da ein E-Auto dabei, ansonsten solltest Du das mal untersuchen?

[ch.eick]

Tach zusammen,

da wir jetzt ja das Batterie Device getrennt im DOIF ansteuern müssten wir mal festlegen, was jetzt über ExternControl angesteuert werden soll.

Offen wäre momentan

Code Auswählen Erweitern


die Ladebegrenzung im Sommer, wenn der Haushalt während der Nacht nicht alles verbrauchen würde.
Hier muss geprüft werden, ob es morgen, also fc1 eine schlechte Leistungsprognose gibt. Dann soll natürlich 100% geladen werden.
Bei mir müsste ich den MaxSoc in % angeben können, da ich momentan mit 40% Soc aus der Nacht komme, was den gesamten Sommer über schlecht für den Speicher ist.
Ab und zu müsste dann jedoch der Speicher auch mal voll gemacht werden, damit er es nicht verlernt :-)

Dann müsste der Leistungshügel um die Mittagszeit ermittelt werden, der in Deutschland > 70% ist. Für andere Lände würde das nicht schaden, weil man da das E-Auto gut laden könnte.
Bis zum Leistungshügel könnte man dann eine Maximale Ladung vorgeben, damit mittags noch platz ist um nicht in die Abschaltung zu kommen. Das versucht der Plenticore bei der intelligenten Steuerung ja auch bereits.

Von Mumpitz habe ich mir noch die zwei Tarif Problematik gemerkt.

Bei einem E-Auto wählt man dann eventuell noch einen Tarif von aWattar oder ähnlichem Anbieter. Da sollte der Speicher dann ja auch nicht zum billigsten Arbeitspreis entladen werden.
Bei einem negativen Preis könnte man ihn hingegen zusätzlich laden, dann kann man Tagsüber lieber PV Einspeisen.


Dann habe ich hier noch folgendes gefunden, was sich me
iner Vorstellung auch deckt.

batterieeinstellungen-kostal

Ich habe heute mal folgende Steuerung eingebaut und getestet:

- Während die Batterie geladen wird teste ich auf den SOC, ab 90% limitiere ich das
  MaxChargeLimit auf 800 Watt, ab 95% auf 400 Watt. Meine Zellen zeigen bei über 90% SOC während
  dem Laden extreme Abweichungen, einzelne gehen auf über 3600 mV (die anderen sind dabei um 3430 mV),
  das kann nicht gut sein. Je geringer der Ladestrom desto geringer die Ausreißer.

- Nachdem einmal 100% erreicht sind (gut fürs Balancing und was wir hier sonst schon alles an
  Empfehlungen gelesen haben) setze ich den MaxSOC auf 90%, d.h. der Speicher wird nicht ständig
  auf 100% gehalten und lädt ständig im obersten Bereich wieder nach. Erst wenn der SOC wieder mal
  unter 90% gefallen ist, setze ich MaxSOC wieder auf 100.

Damit wird der Speicher regelmäßig durchgeladen aber nicht permanent nachgeladen und nicht
auf 100% gehalten. Ich denke, das sollte schonender sein...

Ich bitte um Rückmeldung, damit alles mit einfließen kann.

[Mumpitz]

Was hast Du denn da für Energieschleudern in Betrieb?
Bei läuft LWP HZ für 180m² 2 Wohnungen + WW für einen Haushalt, KWL, Pool, TV ganztägig, 4 Router, Home Office und der Rest vom Haushalt.
Du hast ja gut 20 kW höheren Verbrauch, ist da ein E-Auto dabei, ansonsten solltest Du das mal untersuchen?

Das weiss ich eben auch nicht. Ich vermute, nein ich weiss es eigentlich, dass meine LWP offenbar einen sehr hohen Verbrauch hat. Wieso weiss ich leider nicht. Allenfalls muss ich mal einen Techniker bemühen, welcher die Einstellungen kontrollieren muss. Leider habe ich 0,0 Möglichkeit einer externen Steuerung. Meine Umstände:

300m2 verteilt auf 3 Stockwerke
5 Personen
Keine E Auto
Keine sonstigen Verbraucher, ausser das Übliche (Geschirrspüler, Tiefkühltruhe usw)
Waschmaschine, Tumbler und Entfeuchter (wird jeden 2ten Tag gebraucht da Outdoor Aktive Kinder)
HomeOffice 50%

Gruss

[ch.eick]

Das weiss ich eben auch nicht. Ich vermute, nein ich weiss es eigentlich, dass meine LWP offenbar einen sehr hohen Verbrauch hat. Wieso weiss ich leider nicht. Allenfalls muss ich mal einen Techniker bemühen, welcher die Einstellungen kontrollieren muss. Leider habe ich 0,0 Möglichkeit einer externen Steuerung. Meine Umstände:

Das wurde in Mails weiter bearbeitet, da es hier Offtopic ist.

[ch.eick]

EDIT 2010.02.05 : Wenn man diese Änderung durchführen möchte, kann man in der fhem.cfg mal nach den zuändernden Namen suchen. Es sollte nach der Änderung natürlich nichts mehr zu finden sein
    Die Verschiebung der Datenbank Einträge wurde ja auch bereits in früheren Posts beschrieben. Bei mir geht es dann mit dem Einbau der neuen Geräte weiter

Hallo zusammen,
in eigener Sache möchte ich ankündigen, dass sich die PV_* Device Namen ändern werden. Dadurch verändert sich nicht die Funktionalität, sodass Ihr natürlich bei den bisherigen Namen bleiben könnt.
- Der Hintergrund ist, das mich bei PV_Anlage_1 das "Anlage_" schon länger stört, es wird deshalb kürzer zu PV_1 .
- Beim Speicher Namen wurde es einfach zu lang. PV_Anlage_1_Speicher_1 ==> PV_1_Speicher_1 . Hat hier jemand eine Ideeum "Speicher" noch einzukürzen?
- PV_Anlage_1_API wird dann PV_1_API

Des weiteren werde ich noch aufrüsten und bekommen einen zweiten WR und zwei WallBoxen ( die werden gerade noch gefördert!!! )
- Es wird somit zu einer Schwarm PV Anlage und einige Devices kommen dazu.
- Kostal ist noch nicht soweit, dass der Hausverbrauch richtig berechnet wird.
- Somit erwarte ich auch, dass Autarkie und Eigenverbrauchrate nicht korrekt sein werden.
- Es wird einige neue userreadings geben müssen, die die Berechnung vom Hausverbrauch, Autarki und Eigenverbrauchquote übernehmen.

- Die "intelligente Batterie Steuerung" scheint dann auch nicht mehr korrekt zu laufen und soll deaktiviert werden.
- Dadurch wird der Bereich PV_1_Speicher_1_ExternControl wichtiger werden und die Intelligenz bereitstellen

- Bei den Starkverbrauchern kommen die zwei WallBoxen dazu

Alles in allem wird es somit viele Veränderungen und Weiterentwicklungen geben.
Wer also in den nächsten 5 Jahren in eine änliche Richtung gehen möchte, der sollte dann bereits jetzt sein Umfeld mit verändern.

Aktuell habe ich bereits folgende Schritte in Bearbeitung:
Die durchgestrichenen sind bereits erledigt.
- Umbenennung der Devices
- Anpassung der DOIF mit den neuen Namen der Devices
- Korrektur der DbRep Devices mit den neuen Namen
- Umzug der Daten in der DB auf die neuen Namen
- Anpassung der Namen in Grafana
- Definition des neuen WR << der WR wird ende März geliefert, das Device ist schon vorhanden.
- Erweiterung der Leistungsprognose << ist in Arbeit

Gruß
   Christian

[Mumpitz]

Hallo zusammen,
Stefan war mit dem HTTPMOD Modul mal wieder fleißig un bietet ab der Version 4.1.00 ein neues Attribut an, was wir hier gut gebrauchen können.
set[0-9]*FollowGet dieses Attribut ermöglicht es nach einem Set als nächstes ein Get automatisch zu starten, um das Ergebnis direkt abzuholen. Dadurch können wir dann im PV_Schedule die Aufrufe für die Aktualisierung der Readings wieder entfernen. Das macht das ganze dann wieder übersichtlicher, weil man innerhalb der HTTPMOD direkt sehen kann, wie es aktualisiert wird.

Da die neue HTTPMOD Version nun offiziell verfügbar ist, habe ich diese Änderungen implementiert! Sollten also wieder auf dem selben Stand sein!

[ch.eick]

Sollten also wieder auf dem selben Stand sein!

Abgesehen von der bestellten Aufrüstung und der Umbenennung, um das zu berücksichtigen;-)

[plin]

Kennt jemand eine Quelle für  MOSMIX Files des DWD der letzten Monate? Habe mir meine Datenbank verhunzt und dann festgestellt, dass die Dasi ein Problem hat ...

[ch.eick]

Kennt jemand eine Quelle für  MOSMIX Files des DWD der letzten Monate? Habe mir meine Datenbank verhunzt und dann festgestellt, dass die Dasi ein Problem hat ...

Ich nutze nur das DWD Modul, aber logge die Wetterdaten nicht mit.

[ch.eick]

EDIT: Ich habe dann mal einen Graphen von gestern und heute angehängt.
Gestern sieht man die vormittags eingedrückte Prognose, die durch die Teilabdeckung der Module mit einem Schneefaktor 0.1 (frei wählbar) gemacht wurde.
Gegen 14:30 ist der Schnee vom Dach gerutscht und sofort die Leistung der Ost Module angestiegen.
Heute war der Stromfluss um 9:00 Uhr > 0.88 A , sodass der Schneefaktor auf 1 gesetzt wurde.
Hierdurch wurde im Vergleich zum Vortag die Kurve nicht mehr eingedrückt.

Das zweite Bild zeigt die Prognose für heute ohne die Autokorrektur.
===================================================

Hallo zusammen,

es ist mal wieder Zeit für die Nachrichten.

Momentan habe ich mich mit dem Solar_forecast() und der Autokorrektur beschäftigt. Ihr habt eventuell in den anderen Threads schon Teile davon gesehen.
Es besteht noch ein DbRep Problem, was ich bereits gemeldet habe.
Dann bestand das Problem, wie bei vielen Anderen, dass ich Schnee auf den Modulen hatte und deshalb der Forecast total daneben lag.

Die Ideen dazu sind:
- Autokorrektur mit Faktoren auf Stundenbasis, aus dem Durchschnitt der letzten Tage
- Ein Faktor, wenn die Module mit Schnee bedeckt sind. Da hatte ich >700V aber nur 0.88 A .
  Sollte das der Fall sein, setze ich den String auf Faktor 0.1 , was ich bisher nur an einem String testen konnte.
  Nun sind heute die Reste ins Rutschen gekommen und es gab einen Sprung um Modul Strom, einerseits gut, jedoch schlecht zum Testen

Ich denke der Ansatz ist gemacht und kann beim nächsten Schnee mit anschließenden Sonnenschein verfeinert werden.

Somit habe ich nun zusätzliche readings in der PV_1_config, die einiges in dieser Richtung abbilden. Es wird noch verfeinert...

Die Funktion Solar_forecast() ist bei dieser Gelegenheit auch etwas geändert worden.
Setzt man das Device PV_1_config auf verbose >3 , so reagiert die Funktion mit den bekannten Loggingmeldungen.
Deshalb kann man dann wieder "attr global verbose 3" setzen, ohne ungewollt mit Logging überflutet zu werden.

Dann wurden ja auch noch eine Vielzahl von get und set Meldungen im Log erzeugt, die ich ebenfalls beseitigen konnte.

Es stehen jetzt noch viele Tests und die Korrektur im DbRep an, bis ich das dann hier vorstelle.

@alle Habt Ihr eventuell noch weitere Ideen, oder Wünsche in die Richtung Forecast/Leistungsprognose ?
   Natürlich bin ich in dem anderen Thread auch dabei, jedoch war die Abweichung in der Basis, ohne Autokorrektur immer noch recht hoch.
   Deshalb habe ich auch mal hier mit einer Autokorrektur begonnen. Der Algorithmus sollte der gleiche sein, bei geht es jedoch aus der
   Datenbank, was viele readings im Device vermeidet.

Viele Grüße
    Christian

P.S. Die Batteriesteuerung ist noch nicht vergessen Durch meine Aufrüstung mit einem zweiten WR kann Kostal wohl den Hausverbrauch nicht mehr
richtig berechnen und auch die "inteligente Batterie Steuerung" klappt wohl auch nicht mehr. Da muss ich dann wohl auch etwas nachhelfen Der Post wurde auch heute aktualisiert.

[ch.eick]

Moin, irgend jemand hatte mal geschrieben, ich solle meine Ergebnisse doch etwas besser verkaufen
So seih es nun, für die Leistungsprognose.

In der Forecast Grafik sieht man gestern eine starke Spitze um die Mittagszeit, die man so nicht vorhersagen konnte.
In der Mitte ist die rote Linie der Forecast für heute ohne die Autokorrektur, die der DWD grundlegend beeinflusst hat.

Die grüne Linie ist dann die aktuelle Prognose inklusive der Autokorrektur.
Man erkennt sogar etwas die Spitze vom Vortag, wobei diese durch den drei Tage Durchschnitt etwas abgemildert wurde.
Der Autokorrekturfaktor lag hierbei bei 1.2 bis 1.5 für die Mittagszeit.

Auf der rechten Seite ist dann bereits die erste Prognose für morgen, ebenfalls inklusive der Autokorrektur.

Die bald kommende Version beinhaltet dann auch noch die folgenden Werte, die man optimal für die Tagesplanung verwenden kann:

Code Auswählen Erweitern


Solar_Calculation_fc0_4h   7010 2021-02-16 12:08:19
Solar_Calculation_fc0_day  9999 2021-02-16 12:08:19
Solar_Calculation_fc0_rest 7796 2021-02-16 12:08:19


Auch eine Reaktion auf Abdeckung durch Schnee ist in den Grundzügen eingebaut und drückt die Prognose pro String mit einem Faktor von 0.1 .
Leider konnte das nur noch am letzten Tag beobachtet werden, aber wer will schon Schnee auf den Modulen

Viele Grüße
     Christian

[ch.eick]

Und nochmal hallo, es bleibt spannend.

In Vorbereitung auf die Speicher Steuerung habe ich dann auch noch das Erkennen der Leistungsspitze zur Mittagszeit eingebaut.
Die deutschen Anwender haben ja in Ihrem Wechselrichter eine 70 % Grenze eingestellt. Damit wird im PV_1 Device im reading Inverter_Max_Power eine Leistung angezeigt, ab der der WR abregelt.
Bei Nutzung der dynamischen 70% Regelung wird hier jedoch noch der Hausverbrauch zusätzlich zur Verfügung gestellt. Kostal versucht dann die Batterieladung auch in diesen Bereich zu legen, was mehr schlecht als recht funktioniert. Bei meiner zukünftigen Schwarm Installation mit zwei WR steht diese Funktion nicht mehr zur Verfügung, weshalb ich diese gerade nachbaue

Durch den Forecast werden nun weitere readings geschrieben

Code Auswählen Erweitern


Solar_middayhigh_fc0 1
Solar_middayhigh_fc0_start 11:00
Solar_middayhigh_fc0_stop 15:00
Solar_middayhigh_fc1 1
Solar_middayhigh_fc1_start 11:00
Solar_middayhigh_fc1_stop 14:00


Auf die 70% habe ich noch 500W als durchschnittlichen Hausverbrauch addiert.
Die 1 gibt an, dass es eine Überschreitung geben wird. Mit _start und _stop bekommt man die Triggerzeiten für ein entsprechendes DOIF

Viele Grüße
     Christian