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.