76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@Wolle02,

das Debug zeigt jetzt mehr Informationen zu den gewählten Verbräuchen und Tagen.

Code Auswählen Erweitern

2025.11.18 11:40:21.581 1: SolCast DEBUG> ######################### Start Battery Management DebugLog #########################
2025.11.18 11:40:21.582 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.11.18 11:40:21.583 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Expected today -> PV forecast: 3787 Wh, consumption till sunset: 3311 Wh, used surp: 476 Wh
2025.11.18 11:40:21.583 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Expected tomorrow -> PV forecast: 19702 Wh, consumption till sunset: 12402 Wh, used surp: 13501 Wh (50 % consumption)
2025.11.18 11:40:21.584 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging with proportional consumption: 13501 Wh
2025.11.18 11:40:21.584 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Expected energy for charging after application Share factor: 13501 Wh
2025.11.18 11:40:21.584 1: SolCast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 55 %
2025.11.18 11:40:21.585 1: SolCast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 13501 Wh, need until maxsoc: 9377 Wh
....

Liegt im contrib als V 1.60.6


@Hadl,
ja es kann sein, dass BarrierSoC in der Fortschreibung noch nicht berücksichtigt ist. Das müsste ich nochmal kontrollieren.
Habe nur jetzt keine Zeit, vllt. heute Abend.

LG,
Heiko

[Max_Meyer]

Andererseits hab ich beobachtet, dass der Wert heute Nacht konstant war, obwohl heute Nacht die Wärmepumpe lief, seit heute morgen dann aber abgenommen hat.

Hallo Gisbert
Die Differenz zwischen dem (getrackten) Verbrauch (Consumer01-20) und dem realen Verbrauch über das Zähler-device wird über das folgende Reading ausgegeben:
special_todayNotOwnerConsumption
Gruß Gerd

[Wolle02]

das Debug zeigt jetzt mehr Informationen zu den gewählten Verbräuchen und Tagen.
....

Liegt im contrib als V 1.60.6

Ja, damit kann man das viel besser einordnen. Vielen Dank. Hab das Update gemacht .... läuft gut.

Meine Batterie hat es heute mit Startpunkt 10% auf insgesamt 48% gebracht. Von den gestern prognostizierten 11145 Wh sind heute leider nur noch 9805 Wh übriggeblieben. Damit konnte die Batterie leider auch dann nicht voll werden, wenn gestern durch die Berechnung nicht der OPT auf 10% gesetzt worden wäre. Da mein Verbrauch in der Regel auch größer ist als die angenommenen 50% der Verbrauchsprognose fände ich es an der Stelle sehr hilfreich, wenn man für das Batteriemanagement diese 50% mit einem Key auch noch individuell einstellbar machen könnte. Dann könnte ich mal mit 60% experimentieren, ob ich damit besser hinkomme.

Auf die bisherige Weise ist ein SOC von 100% in der dunklen Jahreszeit für mich eigentlich nicht erreichbar, weil ja immer mal ein schöner sonniger Tag kommt und es mir den OPT dann wieder auf 10% runterregelt.

[DS_Starter]

Da mein Verbrauch in der Regel auch größer ist als die angenommenen 50% der Verbrauchsprognose ...

50% sind vermutlich ein wenig zu pessimistisch. Ich stelle den Wert auf 75% ein. Wir werden sehen wie es sich ausspielt.
Bei mir bleibt der SoC auf 50% stehen. Er wird erst dann wieder um 5% (default) erhöht wenn die Erreichung des maxSoC innerhalb von careCycle unwahrscheinlich wird. Aber mein Akku ist auch groß im Vergleich zur PV-Leistung. Dadurch habe ich wenig Überschüsse für die Ladung zur Zeit und wenig Auswirkung einer (zu) geringen Verbrauchsschätzung/Anrechnung.

Abgesehen davon sind deine erreichten 48% völlig in Ordnung, eigentlich ideal für eine längere Haltezeit. Du kannst upSoC auf 60 stellen. Er fällt dann bei wenig! Überschuß nicht darunter. Mit den 75% Verbrauchsanrechnung ist wahrscheinlich ein guter Kompromiß erreicht.

Liegt im contrib und checke ich wahrscheinlich heute Abend noch ein.

Wenn du natürlich ständig einen SoC von 50% als "Ausfallreserve" in der Bat halten willst, musst du dir im Winterhalbjahr den lowSoC entsprechend hochsetzen. Das kannst du ja automatisch über "set ... attrKeyVal ..." machen.

[Gisbert]

...
special_todayConForecastTillSunset ist der Prognoseverbrauch ab der aktuellen Minute bis zur Minute des Sonnenuntergangs am aktuellen Tag, also ab Mitternacht. Dieser Wert ist nicht konstant und verringert sich tendenziell bis zum Sonnenuntergang.

Die Readings special_todayConsumptionForecast_01 .. 24 sind die Verbrauchsprognosen für die Stunde XX des Tages und bleiben über den Tag konstant. Sie werden aus den Daten der Vergangenheit gebildet.
...

Hallo Heiko,

hier sind meine Daten zu den beiden obigen Readings.
Mein Gefühl, dass das Reading special_todayConForecastTillSunset bis zum Sonnenaufgang in etwa konstant ist hat sich demnach bestätigt.
Erst ab Sonnenaufgang nimmt der Wert kontinuierlich ab.
Im Diagramm sind beide Werte für heute dargestellt (die anderen Werte hab ich ausgeblendet).

Kannst du da reinschauen, woran es liegen könnte? Falls es bei dir nicht auftritt, was sollte ich dir an Daten liefern?

Viele Grüße Gisbert

[DS_Starter]

Hallo Gisbert,

Erst ab Sonnenaufgang nimmt der Wert kontinuierlich ab.

Das war ein guter Hinweis. Dadurch ist es mir gleich ins Auge gestochen woran es liegt.
Die kleine Anpassung liegt bereits im Contrib und geht heute Abend noch mit in den Checkin.

[Hadl]

ja es kann sein, dass BarrierSoC in der Fortschreibung noch nicht berücksichtigt ist. Das müsste ich nochmal kontrollieren.

Hallo, wie erwartet hat die Ladestrategie gut funktioniert. Sobald der barrierSoC=40% erreicht war hat auch die Vorausschau wieder gut funktioniert.
Heute um die Mittagszeit hatte ich so großen Verbrauch das es bis Abends leider nicht ganz gereicht hat den Akku vollzubekommen obwohl Vormittags eingespeist wurde. Naja könnte trotzdem bis zum Sonnenaufgang reichen.
Du darfst diesen Dateianhang nicht ansehen.

Man sieht die Ladung durch barrierSoC bis kurz nach 10:00
Das hat mir echt heute gute Dienste erwiesen, sonst würde warscheinlich noch mehr im Akku fehlen.

Zwei Bitten hätte ich noch:
- Zur Steuerung meiner optionalen Verbraucher nutze ich aktuell "achievable", deutlich feinfühliger wäre ich mit "Ratio" könnten wir das als Reading rausschreiben? Evtl. könnte man sogar achievable damit überflüssig machen, denn das würde ja >= 100% Ratio bedeuten.

- Dann würde ich auch gerne mit den optionalen Verbrauchern drauf reagieren ob der "Barrier" SOC erreicht ist. Dafür wäre auch ein Reading schön. Entweder der Prozentsatz direkt oder ein true/false
Evtl. würden hier auch Bereiche in einem Statuswert Sinn machen wie:
1: SoC < MinSoC
2: MinSoc <= SoC < BarrierSoC
usw...

Viele Grüße

Hadl

[DS_Starter]

Zur Steuerung meiner optionalen Verbraucher nutze ich aktuell "achievable", deutlich feinfühliger wäre ich mit "Ratio" könnten wir das als Reading rausschreiben? Evtl. könnte man sogar achievable damit überflüssig machen, denn das würde ja >= 100% Ratio bedeuten.

"achievable" ist ein einfacher Indikator, der immer berechnet wird und deshalb sehr gut für externe Steuerung über ein Reading geeignet ist.
Da "Ratio" nur bei smartPower und auch nur bei Vorhandensein von Überschuß berechnet wird, ist es "spezieller".
Ich würde Ratio als special-Reading bereitstellen. Welcher Ersatzwert würde denn passen, wenn es kein Ratio gibt? Als Ersatzwert für ein nicht vorhandenes Ratio würde ich es "0" setzen.

Dann würde ich auch gerne mit den optionalen Verbrauchern drauf reagieren ob der "Barrier" SOC erreicht ist. Dafür wäre auch ein Reading schön. Entweder der Prozentsatz direkt oder ein true/false
Evtl. würden hier auch Bereiche in einem Statuswert Sinn machen wie:
1: SoC < MinSoC
2: MinSoc <= SoC < BarrierSoC
usw...

Auch dafür wäre ein special-Reading passend. Da überlege ich mir etwas.
Was ist MinSoc? Soll das lowSoC sein?