76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...
Manch einem User ist stepSoC zu granulareren Nutzung (Schrittweite) des optimalen SoC wichtiger und für ihn stepSoC der "führende" Wert und möchte diesen vorgeben.
...

Das bedeutet doch: Der User darf nur einen (Führungs-)Wert vorgeben und der jeweils andere wird daraus abgeleitet. Gibt er keinen Wert vor, dann wird das SoC-Management deaktiviert. Dann gilt die Forderung stepSoC * careCycle = 100 auch für alle Fälle. Problematische Konfigurationen, z.B. stepSoC=0 bei gleichzeitig gesetztem careCycle=0 sind nicht mehr zulässig. Genau diese Konfiguration führte nämlich zu dem o.g. Verhalten bei der SoC-Prognose. Die Ursache ist also endlich gefunden!

Vorschlagen würde ich übrigens careCycle in [1,28] und stepSoC in [1,100]

@300P: Meinerseits hatte ich nach grauen Icons gesucht und daher keins gesehen ...

[DS_Starter]

Wenn nicht gesetzt, haben stepSoC und careCycle (auch jetzt schon) defaults:

Code Auswählen Erweitern

careCycle=20
stepSoC  =5
Die Bedingung ist per default eingehalten. stepSoC darf 0 werden (auch jetzt bereits) um das SoC Management auszuschalten.
D.h. die Bedingung heißt exakt

Code Auswählen Erweitern

stepSoC * careCycle = 100 | 0
In dem Wertevorrat für careCycle 0 darf nicht (mehr) gesetzt werden, sondern die Auswahl lt. angehängter Tabelle. Der Wert 0 war nicht verboten, da ich nicht davon ausgegangen war dass jemand auf die Idee kommt es zu tun, d.h. nach 0 Tagen immer maxSoC erreichen zu wollen.