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]

[DS_Starter]

Jetzt habe ich noch einen Fix eingebaut den ich schon fast vergessen hatte.
Er bezieht sich auf die Beiträge #6932 (herble) und #6936 und hat Bedeutung für das Training von BEV-Usern.

  * _aiFannPercentileBasedLimits: der overshoot-Faktor (raw_max / p999) hob den
    Percentile-Clip rechnerisch auf raw_max zurück, womit der Double-Percentile-Filter
    wirkungslos wurde; targmaxval wird jetzt korrekt als p999 * 1.05 berechnet
 
  * bugfix: _aiFannNormAsymFixRange: fehlender Hard-Clamp [0,1] ließ normierte Werte > 1.0
    ins Netz laufen wenn Targets den targmaxval überschritten; Werte werden jetzt hart auf
    [0,1] begrenzt
   
  * beide Fixes zusammen aktivieren das Percentile Clipping für BEV-bedingte Heavy-Tail-
    Verteilungen im Trainingstarget korrekt


Update liegt im Contrib.

LG,
Heiko

[Parallix]

Möglicher Bug:

Bei mir ist plantControl wie folgt eingestellt:

Code Auswählen Erweitern

cycleInterval=35
consForecastInPlanning=1
consForecastLastDays=0
consForecastIdentWeekdays=0
genPVdeviation=continuously
conEnergyHourLimit=25000
consForecastBase=1-7->250,8-22->300,23-24->250
Außerdem consumer03 wie folgt:

Code Auswählen Erweitern

WebastoNext
type=charger
power=4200
mode=WebastoNext:PlanningMode4SF
icon=wallbox
mintime=180
notbefore=8
notafter=18
surpmeth=median
pcurr=Charge_Active_Power_W:W
etotal=Energy_Meter_Wh:Wh
swstate=Charge_Point_State_TXT:^charging$:^(?!charging$).*
interruptable=0
SF plant consumer 03 lt. Grafik aktuell von in den Uhrzeit-Bins 10, 11, 12 und 13 ein. Folglich müsste in consumptionForecast in diesem Zeitraum eigentlich 4200 + 300 = 4500 stehen. Tatsächlich steht dort aber

Code Auswählen Erweitern

special_todayConsumptionForecast_08  300 Wh
special_todayConsumptionForecast_09  300 Wh
special_todayConsumptionForecast_10  300 Wh
special_todayConsumptionForecast_11 4200 Wh
special_todayConsumptionForecast_12 4200 Wh
special_todayConsumptionForecast_13 4200 Wh
special_todayConsumptionForecast_14 4200 Wh
special_todayConsumptionForecast_15  300 Wh
special_todayConsumptionForecast_16  300 Wh
special_todayConsumptionForecast_17  300 WhZum einen irritiert, die Einplanung von consumer03 in der Grafik um eine Stunde gegenüber den Angaben der Readings versetzt ist und darüber hinaus die Grundlast (hier 300W) in beiden Ausgaben nicht aufaddiert steht. Ein Bug?

[DS_Starter]

Moin,

Zum einen irritiert, die Einplanung von consumer03 in der Grafik um eine Stunde gegenüber den Angaben der Readings versetzt ist und darüber hinaus die Grundlast (hier 300W) in beiden Ausgaben nicht aufaddiert steht. Ein Bug?

Bezüglich der 300 W arbeitet es wie designed. Auszug aus commandref:

consForecastBase    Die Verbrauchsprognose wird mindestens auf den angegebenen Basiswert erhöht. Höhere Verbrauchsprognosen bleiben unberührt.

Was den Stundenversatz angeht, gibt es das ctrDebug=consumerPlanning um mehr zu sehen bzw. überhaupt etwas dazu sagen zu können.
Zu eachten ist aber, dass eine Einplanung nicht gleichbedeutend mit der Prognose sein muß. Zum z.B. kann ein Consumer 10:50 (in Stunde 11) eingeplant sein, was seine Verbrauchsleistung aber erst in Stunde 12 (als Stundenwert) voll wirksam werden lässt.
Aber wie gesagt, Debuglog anschauen, sonst ist es sehr schwierig etwas konkretes sagen zu können.

[Parallix]

...
consForecastBase    Die Verbrauchsprognose wird mindestens auf den angegebenen Basiswert erhöht. Höhere Verbrauchsprognosen bleiben unberührt.
...

Ja, mindestens. Vorliegend wird zusätzlich zu der Grundlast von 300W aber ein Verbraucher mit 4200W eingeplant. Also sollten in der Prognose doch 4500W auftauchen, oder?

[DS_Starter]

Also sollten in der Prognose doch 4500W auftauchen, oder?

Nein, weil wie oben gekennzeichnet -> Höhere Verbrauchsprognosen bleiben unberührt.

[Parallix]

Also sollten in der Prognose doch 4500W auftauchen, oder?

Nein, weil wie oben gekennzeichnet -> Höhere Verbrauchsprognosen bleiben unberührt.

Da stand ich gerade wohl selber auf dem Schlauch!

Wie dem auch sei wäre es super, wenn Die Grundlast stets mit den weiteren prognostizierten Verbräuchen zu einer Gesamtlast zusammengerechnet würde. Das jedenfalls war ja die ursprüngliche Idee, warum ich den Request, so etwas wie ConsForecastBase zu haben, gestellt und du das Feature netterweise eingebaut hast.

[DS_Starter]

Wie dem auch sei wäre es super, wenn Die Grundlast stets mit den weiteren prognostizierten Verbräuchen zu einer Gesamtlast zusammengerechnet würde. Das jedenfalls war ja die ursprüngliche Idee, warum ich den Request, so etwas wie ConsForecastBase zu haben, gestellt und du das Feature netterweise eingebaut hast.

Das kann ich machen, würde mir aber dennoch etwas für diesen Schlüssel überlegen. Denn consForecastBase trägt schon den Sinn eines unteren Clamp im Namen. Würde ich die Logik jetzt einfach ändern, wäre es u.U. nicht so schön.
Möglichweise wäre ein Zusatz für consForecastBase möglich, um die Wirkweise optional anpassen zu können. Muß ich sehen.