76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Ich habe noch etwas weitergefeilt.
Über die prognostizierte benötigte Ladeleistung des (Rest)Tages wird die Summe ermittelt und darüber ein benötigter Durchschnitt mit den noch verfügbaren Ladestunden gebildet.
Im Log "average" -> dieser Wert wird für die aktuelle Stunde mit der zunächst ermittelten Mindestladeleistung verglichen und der Maximalwert beider Werte als Target-Leistung verwendet. Im Beispiel "OTP: 1829 W", dieser Wert findet sich auch im Reading Battery_ChargeOptTargetPower_XX wieder:

Code Auswählen Erweitern

2025.09.13 10:55:46.863 1: SolCast DEBUG> ChargeOTP - max OTP Bat 01: 2846 W, sum need: 10972 Wh, number hrs: 6, average: 1829 W
2025.09.13 10:55:46.863 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.09.13 10:55:46.864 1: SolCast DEBUG> ChargeOTP - NOTE: The hours listed below are the estimated number of hours remaining on the current day with at least the respective PV surplus.
2025.09.13 10:55:46.864 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 11, Start SoC: 20460 Wh, Surplus: 1438 Wh (5 hrs), OTP: 1829 W, safety: 20 %
2025.09.13 10:55:46.864 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 21754 Wh, Surplus: 1320 Wh (6 hrs), OTP: 1320 W, safety: 20 %
2025.09.13 10:55:46.865 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 23074 Wh, Surplus: 1965 Wh (3 hrs), OTP: 1965 W, safety: 20 %
2025.09.13 10:55:46.865 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 25028 Wh, Surplus: 1673 Wh (4 hrs), OTP: 1016 W, safety: 20 %
2025.09.13 10:55:46.865 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 26044 Wh, Surplus: 3336 Wh (1 hrs), OTP: 2846 W, safety: 20 %
2025.09.13 10:55:46.866 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 28030 Wh, Surplus: 2892 Wh (1 hrs), OTP: 463 W, safety: 20 %
2025.09.13 10:55:46.866 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 28416 Wh, Surplus: 2280 Wh (2 hrs), OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.866 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 28416 Wh, Surplus: 226 Wh (7 hrs), OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.867 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.867 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.867 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.868 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.868 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %
2025.09.13 10:55:46.868 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OTP: 1000 W, safety: 20 %

Warum das Ganze?
Es wird bei der benötigten Ladeleistung von einer gleichbleibenden Mindestladeleistung von X W über eine Stunde ausgegangen um die benötigte Ladeenergie für diese Stunde zu erreichen. D.h. man begrenzt die Ladeleistung praktisch im Inverter.
Allerdings wird dieser Idealzustand innerhalb der Stunde nur bei sehr stabilen Verhältnissen zutreffen. Real wird es auch Zeiten innerhalb der aktuellen Stunde geben, dass die min. Ladeleistung nicht erreicht wird. Sei es weil eine Wolke vor der Sonne ist oder der Wasserkocher angeschaltet wurde. Andererseits gibt es wahrscheinlich auch Zeiten mit höhrem Überschuß als kalkuliert was zu einer ausgleichenden Ladung führen kann sofern die Ladeleistung nicht auf das Minimum begrenzt ist.
Die Überhöhung des Targets auf den benötigten Durchschnittswert wirkt diesem Effekt entgegen. Liegt die berechnete Mindestladeleistung über dem kalkulierten Durchschnitt, wird dieser Wert als Target im Reading verwendet.

Update liegt im contrib.

Wirkt eine grundsätzliche Überhöhung nicht dem Ziel entgegen, dass der TargetSOC möglichst spät erreicht wird?

PS: Derzeit teste ich eine vom Ladezustand und der Prognose abhängige Überhöhung und hoffe, dass ich Anfang der Woche hier eine erste Beschreibung dazu liefern kann.

[DS_Starter]

Wirkt eine grundsätzliche Überhöhung nicht dem Ziel entgegen, dass der TargetSOC möglichst spät erreicht wird?

Könnte sein, allerdings glaube ich es nicht weil:

1. keine grundsätzliche Erhöhung stattfindet, sondern selektiv in der aktuellen Stunde sofern bsiheriger Target
   unter Durchschnitt liegt
2. die Überhöhung nicht wirkt, wenn der PV-Überschuß wie prognostiziert eintritt. Wir limitieren ja den
   Inverter mit der Leistungsvorgabe. Wenn die Vorgabe höher ist, aber kein weiterer Überschuß vorhanden
   ist, wird auch nicht mehr geladen als prognostiziert
3. wir viel mit Wahrscheinlichkeiten umgehen die eintreffen können, oder auch nicht. Wir wollen ja auch
   am Ende des Tages einen möglichst hohen SoC (99 - 100%) zielgenau erreichen, was dem ersten Ziel ein wenig
   konträr läuft

Aber wie immer ist die Praxis der Prüfstein der Theorie. Wie werden sehen wie sich das Ganze ausspielt.

[DS_Starter]

Hallo Martin,

willkommen!

Bei dieser Konfiguration wird der Input von PV dauerhaft positiv angezeigt (auch Nachts, wenn Leistung_vom_Dach=0 ist)

Das ist sicherlich ein Konfigurationsfehler.
Zur Info, die Angabe von pvIn=Leistung_vom_Dach:W ist nur für die Anzeige relevant. Für die Berechnung wichtig ist die Angabe in pvOut=status-load_power:kW.

Ich vermute nachdem ich deine Konfig gelesen habe, dass dein Inverter ein Hybridwechselrichter ist, richtig?
Das lässt auch vermuten, dass pvOut nicht nur eine PV-Leistung angibt so wie es verlangt ist, sondern auch einen Battrieanteil der ins Hausnetz entladen wird.
Das passt so natürlich nicht zusammen. Bei einem Hybridwechselrichter legst du einen PV-Wechselrichter UND zusätzlich einen Batterie-Wechselrichter an. Die jeweiligen anzugebenden Schlüssel sind in der Online-Hilfe genau erläutert und der sachliche Inhalt, den die Readings liefern müssen, ist genau einzuhalten. Also es vllt. nicht so genau zu nehmen ob das Reading nun nur PV oder PV und Batterieleistung liefert, geht schief. 

Eine große Hilfe bei der Überprüfung ist ein DebugLog mit ctrlDebug=collectData. Es zeigt genau welcher Input geliefert wird und sieht etwa so aus:

Code Auswählen Erweitern

2025.09.13 18:12:10.709 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, source: pv, delivery: default =>
2025.09.13 18:12:10.709 1: SolCast DEBUG> pvOut: 356 W, pvIn: 359 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 68513755 Wh
2025.09.13 18:12:10.710 1: SolCast DEBUG> collect Inverter 02 data - device: MQTT2_cerboGX_c0619ab34e08_solarcharger_Common, source: pv, delivery: bat =>
2025.09.13 18:12:10.710 1: SolCast DEBUG> pvOut: 135 W, pvIn: 135 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 4995300 Wh
2025.09.13 18:12:10.711 1: SolCast DEBUG> collect Inverter 03 data - device: MQTT2_cerboGX_c0619ab34e08_vebus, source: bat, delivery: default =>
2025.09.13 18:12:10.711 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 255 W, etotal: 0 Wh
2025.09.13 18:12:10.711 1: SolCast DEBUG> summary data of all Inverters - pv: 491 W, this hour Generation: 136 Wh
2025.09.13 18:12:10.712 1: SolCast DEBUG> State of Plant derating: 0, info: The value of device "MQTT2_cerboGX_c0619ab34e08_solarcharger_Common", reading "Regulated" doesn't match the condition "1"
2025.09.13 18:12:10.712 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2025.09.13 18:12:10.713 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 19: 328.7 % -> pvrlvd: 1
2025.09.13 18:12:10.778 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2025.09.13 18:12:10.778 1: SolCast DEBUG> gcon: 23.2 W, gfeedin: 0 W, contotal: 49288.4 Wh, feedtotal: 2090842.3 Wh
2025.09.13 18:12:10.779 1: SolCast DEBUG> write to pvHistory - day: 13, hod: 19, GridConsumption (gcons): 3 Wh
2025.09.13 18:12:10.780 1: SolCast DEBUG> collect Battery Readings data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2025.09.13 18:12:10.780 1: SolCast DEBUG> pin: 0 W, pout: 35 W, totalin: 6072495.41618549 Wh, totalout: 6028612.74056674 Wh, soc: 98
2025.09.13 18:12:10.797 1: SolCast DEBUG> EnergyConsumption input -> PV: 134 Wh, PP: 0 Wh, GridIn: 34 Wh, GridCon: 2 Wh, BatIn: 2 Wh, BatOut: 14 Wh
2025.09.13 18:12:10.797 1: SolCast DEBUG> EnergyConsumption result -> 114 Wh
2025.09.13 18:12:10.798 1: SolCast DEBUG> current Power values -> PV2Node: 356 W, PV2Bat: 135, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 23 W
2025.09.13 18:12:10.799 1: SolCast DEBUG> current Power Battery -> BatIn: 0 W (Node2Inv2DC: 0 W), BatOut: 35 W (DC2Inv2Node: 255 W)
2025.09.13 18:12:10.799 1: SolCast DEBUG> current Consumption result -> 634 W


Dieses Debug ist sehr wichtig um Zusammnhänge zu erkennen und wird für den Support benötigt.

Also ich würde dir raten die Inverterkonfig nochmal zu überprüfen wie oben geschrieben und wenn das erledigt ist und immer noch Fragen/Zweifel bestehen hier mal ein Debuglog zu posten.

LG,
Heiko

[DS_Starter]

@all,

könnte mir mal jemand mit mit einem Hybridwechselrichter seine laufende Konfiguration posten?
Dann würde ich die Vorgehensweise der Einrichtung eines Hybriden anhand dieses Beispiels im Wiki hinterlegen.

Danke!

[Wolle02]

Hallo Heiko, ich habe hier einen Fronius Symo Gen24 laufen. Das ist ein Hybridwechselrichter, weil er auch die BYD Batterie mit wechselrichtet. Meine Konfiguration habe ich derzeit so eingestellt:

Code Auswählen Erweitern

SetupBatteryDev01
PV_Batterie
cap=10240
charge=BatteryChargePercent
icon=@dyn:@dyn:@dyn:@dyn
intotal=Summe_Ladung:Wh
outtotal=Summe_Entladung:Wh
pin=BatteryChargeWatt:W
pinmax=10000
pout=BatteryDischargeWatt:W
show=2


setupInverterDev02
Fronius_Symo_Gen24 etotal=User_Produced_PV_Energie:kWh pvOut=PowerFlow_Site_P_PV:W capacity=6000 strings=Dach_Ost,Dach_West
Das funktioniert sehr gut und ich bin damit auch sehr zufrieden.

Ich habe mich bei der Einrichtung an diesem Wiki Eintrag orientiert: https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD

[DS_Starter]

Vielen Dank!
Was mich wundert, dass du nur einen setupInverterDev02 angegeben hast. Was ist mit setupInverterDev01?

LG,
Heiko