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 von mir betreuten Modulen 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

[DS_Starter]

[Off-Topic]
Weil ich gerade Erleichterungen angerissen habe ...
Ich lasse mir das FHEM-Log täglich neu erstellen damit es nicht so groß wird. Um jedoch Informationen auch längere Zeit zurück komfortabel durchsuchen und auswerten zu können, habe ich mir in Proxmox einen Graylog-Logserver installiert.

Graylog ist eine Open-Source Lösung zum Zusammenführen, Analysieren und Organisieren großer Mengen an Systemlogs aus unterschiedlichen Quellen. Es basiert auf der bewährten Such- und Speicherlösung Elasticsearch. Die Logdaten werden geparst, korreliert und mit Zusatzinformationen versehen. Informationen über bestimmte Ereignisse können gezielt an ausgewählte Empfänger weitergeleitet werden. Graylog sorgt für die visuelle Darstellung der so aufbereiteten Daten. So bleibt der Admin immer informiert über das, was in seinen Systemen vorgeht.

Die FHEM Log-Datensätze übertrage ich mit meinem Log2Syslog-Modul per UDP zu Graylog. Aktuell aggregiere ich nur die Log-Datensätze, aber auch Events kann man mit Log2Syslog zu Graylog übertragen lassen und dort auswerten oder in der Vergangenheit nachforschen. Auch meine Pi-hole Logs sende ich zu Graylog.

Im Anhang seht ihr ein paar Screenshots wie man sich sowas vorstellen kann.
[/Off-Topic]