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 darf 0 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.

[Parallix]

...

Schande über mich, denn ich hatte unsauber gelesen bzw. falsch im Kopf:
careCyle  = 0     : SoC-Management aus
careCycle = N > 0 : Es wird versucht, alle N Tage den SoC "wartungstauglich" zu bekommen.

Nicht im Leben hätte ich stepSoC = 0 für's Ausschalten des SoC-Managements verwendet. 

[DS_Starter]

So ... ich habe die letzten besprochenen Patches (auch von Lars) eingebaut und angetestet.
Das Update liegt im contrib.

Hier ein Überblick des Versionsinhalts:

## [v2.10.3]
xx.xx.xxxx Rev.

- Fix:
  * SOC-Prognose LR überschätzt erreichbaren Ladestand wenn aktueller SoC < batoptsocwh
    ___batClampValue snappte den prognostizierten SoC im Ladefall bedingungslos auf batoptsocwh,
    wodurch bpinmax wirkungslos war und 100% SoC bereits nach wenigen Stunden prognostiziert
    wurde. Im Ladefall (delta >= 0) wird nun nur noch auf [lowSocwh, batinstcap] begrenzt;
    der Snap-up auf batoptsocwh bleibt ausschließlich dem Entladefall vorbehalten.
     
  * readCacheFile - RAM-Peak beim Nachladen von KI-Modellen reduziert (Forum: https://forum.fhem.de/index.php?msg=1368934)
    Beim Reload von 'aitrained', 'airaw' und 'neuralnet' lagen kurzzeitig zwei vollständige
    Modelle gleichzeitig im Heap (altes Objekt + neu deserialisiertes). Auf speicherschwachen
    Systemen (z.B. Raspberry Pi 2, ~1 GB RAM) konnte dies den OOM-Killer triggern.
    Behoben durch gezieltes Freigeben der Vorgängerdaten unmittelbar vor fileRetrieve:
    'aitrained'/'airaw': delete der alten Hash-Referenz vor dem Retrieve (Guard: -s $file).
    'neuralnet': selektives Löschen der XS-seitigen FannModel-Objekte (nicht serialisierbar,
    dominanter RAM-Anteil); Blob-Daten und Validierungslogik bleiben unverändert.
   
- Add:
  * Kreuzvalidierung stepSoC * careCycle in ctrlBatSocManagementXX
    Das Produkt aus stepSoC und careCycle muss 100 ergeben (oder stepSoC=0
    zur Deaktivierung des SoC-Managements). Ungültige Kombinationen werden
    beim Setzen des Attributs abgewiesen. Gültige Paare: 1/100, 2/50, 4/25,
    5/20, 10/10, 20/5, 25/4, 50/2, 100/1.
    Der zulässige Wertebereich von stepSoC wurde auf die ganzzahligen Teiler
    von 100 im Bereich 1..100 erweitert (zuvor: 0..5).
     

Ein Hinweis in eigener Sache.
Um meine Entwicklungen an den Modulen die ich betreue einigermaßen im Griff zu behalten, habe ich mir in meinem Proxmox-Cluster Forgejo für das Releasemanagement installiert. Vllt. mache ich später einen Link zu Codeberg (Codeberg ist eine gemeinnützige, werbe- und trackingfreie Plattform aus Deutschland -> vs. GitHub) um Entwicklungen zu forwarden oder Entwicklungsversionen zu veröffentlichen, kommt darauf an was sinnvoll ist und die Nutzung vereinfacht.
Aktuell vereinfache ich mir die Arbeit und poste einfach einen Ausschnitt aus meinem in Forgejo geführten Changelog. Also bitte nicht wundern wenn ihr im Text technische Details lest die euch nichts sagen oder für den Nutzer nicht sooo interessant sind. Aber ich spare mir den Aufwand die Texte einzukürzen etc.
Ich hoffe auf euer Verständnis. 

LG,
Heiko