76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Letztere sind aber z.B. dann sinnvoll, wenn in zwei oder mehr mit Elektroheizkörpern ausgestatteten Räumen die Heizkörper abwechselnd eingeschaltet werden müssen, um beide Räume mit PV-Überschuss zu beheizen. Typisch wäre z.B. eine Umschaltung alle 30 Minuten.

Dem stimme ich zu, ist aber wie beschrieben so nicht realisierbar. Machbar wäre noch eine zufällige Reihenfolge von Consumern mit einer identischen Prio=x.

Die Anforderung/Aufgabe als solche kann man als User aber realisieren indem man, z.B. über ein Notify, das Dev01 auto=0 sperrt und Dev02 auto=1 für das Schalten freigibt sobald ein Event state=off des D01 empfangen wird. Entsprechend Dev02 aut=0 und Dev01 auto=1 wenn state=off des D02 empfangen wird.
Ist in den Geräten mintime=30 eingetragen, ergibt sich ein wechselseitiges Einschalten alle 30 Minuten solange alle anderen Bedingungen eingehalten werden.

[Parallix]

Letztere sind aber z.B. dann sinnvoll, wenn in zwei oder mehr mit Elektroheizkörpern ausgestatteten Räumen die Heizkörper abwechselnd eingeschaltet werden müssen, um beide Räume mit PV-Überschuss zu beheizen. Typisch wäre z.B. eine Umschaltung alle 30 Minuten.

Dem stimme ich zu, ist aber wie beschrieben so nicht realisierbar. Machbar wäre noch eine zufällige Reihenfolge von Consumern mit einer identischen Prio=x.

Die Prioritäten sind - wie bereits geschrieben - ja absolut nicht dringend und werden mit den anderen Features bzw. Attributen erst dann wichtig, wenn mal eine präzisere Berücksichtigung bei Verbrauchsprognose erfolgt.

[Parallix]

Mit Einführung von "smartPower" hatte ich gedacht, dass bei Wahl von "optPower" das Reading Battery_ChargeOptTargetPower_XX, wenn Battery_TargetAchievable_XX == 0 und SOC_XX > ctrlBatSocManagementXX->lowSoc ist, so berechnet wird, dass bei eine fiktiven Füllung mit diesem (lt. Prognose nicht mehr erzielbarem) Wert <= ctrlBatSocManagementXX->pinmax der ctrlBatSocManagementXX->loadTarget noch bis Sonnenuntergang erreicht werden könnte. Mit der aktuellen Release-Version ist das aber leider nicht der Fall. Aktuell sehe ich einen viel zu kleinen Wert > ctrlBatSocManagementXX->pinreduced    Ist es möglich, dass die Berechnung von Battery_ChargeOptTargetPower_XX wie oben beschrieben in SF vorgenommen wird, der Wert also bis Sonnenuntergang schrittweise an ctrlBatSocManagementXX->pinmax herangeführt wird. Oder spricht etwas dagegen?

[DS_Starter]

Aktuell sehe ich einen viel zu kleinen Wert > ctrlBatSocManagementXX->pinreduced

Da liegt aber ein anderer Zusammenhang vor, denn wenn Battery_TargetAchievable_XX == 0 ist, wird pinmax verwendet wie bei mir aktuell:

Code Auswählen Erweitern

2025.10.19 17:15:42.785 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.19 17:15:42.785 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 70 %
2025.10.19 17:15:42.786 1: SolCast DEBUG> ChargeOTP Bat 01 - weighted self-consumption: 0 %
2025.10.19 17:15:42.786 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 28416 Wh, remaining: 3126 Wh -> target likely achievable? no
2025.10.19 17:15:42.786 1: SolCast DEBUG> ChargeOTP Bat 01 19/17 - hod: 18 / 00, lr/lc: 1/1, SoC S/E: 25290 / 24855 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.19 17:15:42.787 1: SolCast DEBUG> ChargeOTP Bat 01 19/18 - hod: 19 / 01, lr/lc: 1/1, SoC S/E: 24855 / 24233 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.19 17:15:42.787 1: SolCast DEBUG> ChargeOTP Bat 01 19/19 - hod: 20 / 02, lr/lc: 1/1, SoC S/E: 24233 / 23633 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.19 17:15:42.787 1: SolCast DEBUG> ChargeOTP Bat 01 19/20 - hod: 21 / 03, lr/lc: 1/1, SoC S/E: 23633 / 22924 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.19 17:15:42.788 1: SolCast DEBUG> ChargeOTP Bat 01 19/21 - hod: 22 / 04, lr/lc: 1/1, SoC S/E: 22924 / 22265 Wh, Surplus: 0 Wh, OTP: 5040 W
...

Da muß man sich das komplette Debug anschauen.

Edit: wichtig ist auch dass dein aktueller SoC > lowSoC ist (in Wh gerechnet!) nicht in %. Das ist zu ungenau.

[Parallix]

Aktuell sehe ich einen viel zu kleinen Wert > ctrlBatSocManagementXX->pinreduced

Da liegt aber ein anderer Zusammenhang vor, denn wenn Battery_TargetAchievable_XX == 0 ist, wird pinmax verwendet wie bei mir aktuell.
...

Meinerseits würde ich mir wünschen, wenn SF in diesem Fall Battery_ChargeOptTargetPower_XX auf max( pinmax, (100 - SOC)*capacity/timeTillSunset) gesetzt würde, sich also bis Sonnenuntergang schrittweise bis pixmax entwickelt. Ist das machbar? Oder spricht irgendetwas dagegen?

PS: Du verwendest mit 70% aber eine richtig große Sicherheitsmarge. Habe vermutlich ähnliche Probleme mit den aktuelle sehr volatilen Wetterlagen, aber auch mit dem (für mich) nicht ganz determistischen Regelverhalten meines Hybriden und würde mir wünschen, wenn es in SF neben der PVdeviation auch eine auf einem 1h breiten "sliding window" bestimmte BatChargeDeviation_XX geben würde. Deren Wert könnte auf nach Klärung folgender Frage ermittelt werden: Welche an Energiemenge sollte lt. SF in den letzten 60 Minuten in den Speicher verbracht werden und welche Energiemenge wurde tatsächlich in ihn verbracht?

[DS_Starter]

Meinerseits würde ich mir wünschen, wenn SF in diesem Fall Battery_ChargeOptTargetPower_XX auf max( pinmax, (100 - SOC)*capacity/timeTillSunset) gesetzt würde, sich also bis Sonnenuntergang schrittweise bis pixmax entwickelt. Ist das machbar? Oder spricht irgendetwas dagegen?

Ich halte dies für unnötig. Der Grund dafür folgt aus der Überlegung:

- Wird das Ladeziel als unerreichbar eingeschätzt, wird die mögliche Ladeleistung zur aktuellen! Zeit auf
  pinmax gesetzt um so jede mögliche PV Erzeugung den Batterien zuzuführen.
  Das war ein Grundanliegen der vorangangenen Diskussionen.

- beim nächsten Zyklus wird die Zielerreichbarkeit dynamisch neu kalkuliert. Sollte sich durch die eingestellte
  pinmax und verfügberer PV die Batterie soweit aufgeladen haben dass das Ladeziel erreicht werden kann wird
  sofort wieder umgeschaltet in den für diesen Fall vorgesehenen Berechnungsmodus

Die Festlegung der Ladeleistung auf "max( pinmax, (100 - SOC)*capacity/timeTillSunset)" solange die Nichterreichbarkeit des Ziel eingeschätzt wird, hat doch soweit ich sehe das gleiche Ergebnis. Ist der Ausdruck "(100 - SOC)*capacity/timeTillSunset)" < pinmax, wird pinmax genutzt. Ist dieser Ausdruck > pinmax wird theoretisch eine höhere Ladeleistung genutzt was aber durch die generell begrenzenden Eigenschaft des Parameters pinmax (dafür ist er ja definiert) nicht eintritt. Das Modul und die Physik lassen > pinmax nicht zu.   

[Parallix]

...

Ehrlich gesagt finde ich es unnötig, das Reading Battery_ChargeOptTargetPower_XX auf einen Wert zu setzen, der aus wenigen binären Readings (Battery_ChargeRequest_XX, Battery_TargetAchievable_XX, ...), Konstanten (pinmax, pinreduced) unmittelbar und ohne jede Rechnung abgeleitet werden kann. Daher mein Vorschlag in Battery_ChargeOptTargetPower_XX eine zweckdienlichere Info zum gesichert stressfreieren Laden (garantiert keine großen Leistungssprünge)  bereit zu stellen.

PS: Aktuell prüfe ich extern, ob SF auf Basis der o.g. binären Readings eine der o.g. Konstanten in Battery_ChargeOptTargetPower_XX verbracht hat und reche dann selber den o.g. für mich im Sinne der Ladestrategie (stressfreieren Laden) sinnvolleren Wert aus.

[klaus.schauer]

Derzeit an meinem Wallbox-Ladecontroller arbeitend, möchte anregen, SF wie folgt zu erweitern:

Um Wallboxen (aber auch andere Verbrauchseinrichtungen, deren Leistungsaufnahme gesteuert werden kann) besser in SF abbilden zu können, muss der entsprechende Consumer neben consumerXX→power (gem. Doku die (Nenn-) Leistung lt. Datenblatt)  auch noch durch eine minimale Ladeleistung  consumerXX→minPower beschrieben werden können, die angibt, ab welcher minimalen Leistung ein Betrieb möglich ist. Darüber hinaus sollte auch noch Mindestüberschussleistungen angegeben werden können, ab der der Consumer eingeschaltet wird (consumerXX→minOnPower) oder ab der die Einschaltung ausgeschaltet oder unterbrochen wird (consumerXX→minOffPower).

Alle Consumer erhalten eine Priorität (consumerXX→prio). Auf Basis dieser Prioritäten kann dann bei einem prognostizierter Überschuss in SF geplant werden, welche Can-Consumer in welcher Reihenfolge in der Verbrauchsprognose als eingeschaltet zu betrachten ist, um diesen Überschuss zu konsumieren. Besitzen zwei oder mehrere Can-Consumer die gleiche Priorität so werden diese planungstechnisch alternierend, jeweils für eine Zeit consumerXX→quantum < consumerXX→mintime  eingeschaltet, berücksichtigt.

Die Einstellungsmöglichkeiten des SMA HomeManagers 2.0 insbesondere zur Einschaltschwelle des Verbrauchers wären auch für SolarForecast überlegenswert, siehe Bildchen

[DS_Starter]

Ehrlich gesagt finde ich es unnötig, das Reading Battery_ChargeOptTargetPower_XX auf einen Wert zu setzen, der aus wenigen binären Readings (Battery_ChargeRequest_XX, Battery_TargetAchievable_XX, ...), Konstanten (pinmax, pinreduced) unmittelbar und ohne jede Rechnung abgeleitet werden kann.

Die Ladeleistungssteuerung ist mitnichten so simpel gebaut.
Vermutlich ist die gesamte Logik in ihrer gesamten Komplexität noch nicht klar geworden bzw. habe ich sie noch nicht hinreichend umfänglich erklärt. Deswegen empfehle ich nochmal die Texte im Wiki zu lesen oder aber den Code (subs _batChargeMgmt, __batChargeOptTargetPower) zu studieren.

Daher mein Vorschlag in Battery_ChargeOptTargetPower_XX eine zweckdienlichere Info zum gesichert stressfreieren Laden (garantiert keine großen Leistungssprünge)  bereit zu stellen.

Nichts dagegen, nur ist eine bessere und vor allem sinnvollere Variante für den Fall einer Nichterreichbarkeit des Ladeziels noch nicht kommuniziert wie du in meiner Darlegung in #4280 lesen kannst. Oder gibt es etwas was ich noch nicht verstanden habe?

Und wieso benutzt du nicht optPower anstatt smartPower? In dem Modus wird bei der Nichtereichbarkeit nicht auf pinmax gesetzt, grantiert keine großen Sprünge aber auch nicht gerantiert ohne eine Einspeisung im ungünstigsten Fall. Steht auch im Wiki.

PS: Aktuell prüfe ich extern, ob SF auf Basis der o.g. binären Readings eine der o.g. Konstanten in Battery_ChargeOptTargetPower_XX verbracht hat und reche dann selber den o.g. für mich im Sinne der Ladestrategie (stressfreieren Laden) sinnvolleren Wert aus.

Kein Problem, jeder wie er mag.

[DS_Starter]

Hallo Klaus,

ja das ist durchaus überlegenswert.
Wenn ich das Diagramm richtig interpretiere, kannst du mit dem Schieberegler einen Strommix (Anteil Netz + Anteil PV) festlegen ab dem der/die Verbraucher eingeschaltet werden können.
Sehe ich das richtig?
Zur Zeit haben wir quasi den Fall 100% PV (Überschuß) per default implementiert, damit ein Verbraucher einschalten kann/darf.

[klaus.schauer]

Wenn ich das Diagramm richtig interpretiere, kannst du mit dem Schieberegler einen Strommix (Anteil Netz + Anteil PV) festlegen ab dem der/die Verbraucher eingeschaltet werden können.
Sehe ich das richtig?
Zur Zeit haben wir quasi den Fall 100% PV (Überschuß) per default implementiert, damit ein Verbraucher einschalten kann/darf.

Genau. Der Regler hat einen praktischen Nebeneffekt für Verbraucher mit variabler Leistung. Im konkreten Beispiel erhält der Verbraucher bei 40 % PV Leistung also 2460 W das Einschaltsignal. Dies könnte auch dessen unterer Leistungsgrenzwert sein.

[DS_Starter]

Habe es mir mal notiert:

Die 100% sind dann vermutlich die maximal mögliche Anlagenleistung, oder?

[DS_Starter]

@Parallix,

PS: Du verwendest mit 70% aber eine richtig große Sicherheitsmarge. Habe vermutlich ähnliche Probleme mit den aktuelle sehr volatilen Wetterlagen, aber auch mit dem (für mich) nicht ganz determistischen Regelverhalten meines Hybriden und würde mir wünschen, wenn es in SF neben der PVdeviation auch eine auf einem 1h breiten "sliding window" bestimmte BatChargeDeviation_XX geben würde. Deren Wert könnte auf nach Klärung folgender Frage ermittelt werden: Welche an Energiemenge sollte lt. SF in den letzten 60 Minuten in den Speicher verbracht werden und welche Energiemenge wurde tatsächlich in ihn verbracht?

Die Edits sind schwierig zu verfolgen ...

Die 70% ist nur temporär. Ich muß/will ja alles Mögliche testen. Normal habe auf 20% stehen, das reicht bei mir im Prinzip.

Welche an Energiemenge sollte lt. SF in den letzten 60 Minuten in den Speicher verbracht werden und welche Energiemenge wurde tatsächlich in ihn verbracht?

So einen Wert kann man im Prinzip für jede Stunde ermitteln. Es kommt natürlich darauf an wo oft der Datenlieferant Batterie-In/Out Summen liefert. Aber prinzipiell sollte es kein Problem sein.