76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Ralph,

SF kennt drei Invertertypen:

- PV-Wechselrichter
- Solar-Ladegerät
- Batterie-Wechselrichter

Du hast einen PV-Wechselrichter definiert, was zunächst ok ist. Aber pvIn ist definitiv falsch gesetzt, denn pvIn muß bei diesem Typ sein (Zitat aus Comref):

Ein Reading, welches die aktuelle DC PV-Eingangsleistung in W liefert (Summe aller angeschlossenen Strings).
    Es wird ein positiver numerischer Wert erwartet.

nichts anderes!
Das müsstest du korrigieren.

Dann brauchst du einen weiteren Wechselrichter vom Typ Batterie-Wechselrichter.
Dieser WR ist in deinem Victron eingebaut, wir arbeiten also mit zwei Funktionalitäten; dem PV-WR und dem Batterie-WR; die sich bei deinem Victron physisch in einem Gerät befinden. Dort wird dann ac2dc und dc2ac definiert.

Wenn alles richtig ist, sieht es dann aus wie auf meinem Bild. Der PV-WR ist ein SMA Inverter und der Batterie-WR ein (bzw. drei im Verbund) Victron MultiPlusII.
Der dritte Inverter (ganz rechts) ist ein reiner Batterie-Loader (MPPT) der nur die Batterien PV DC-DC lädt.

LG,
Heiko

[reisner]

Hi Heiko,
vielen Dank für die schnelle Antwort, ich mache mich an die Umsetzung und werde berichten.

Gruß Ralph

[reisner]

Hi,
ich muss noch einmal nachfragen, da mir das Zusammenspiel der verschiedenen Invertertypen nicht klar ist. Anbei noch eine bessere Übersicht meiner Anlage. Die PV Energie des Ladereglers geht in den Wechselrichter und in die Batterie, wobei der Verbrauch des Wechselrichter Vorrang hat und nur der Überschuss zum Laden der Batterie zur Verfügung steht. Brauche ich hier 2 SolarInverterDev und muss mir per Dummy Readings basteln, die den Enegiefluß-Splitt abbilden?

Danke

[reisner]

noch eine Frage, wie wird die Flow-Grafik getriggert? Die Aktualisierung scheint nicht an den Readings zu hängen.

[DS_Starter]

ich muss noch einmal nachfragen, da mir das Zusammenspiel der verschiedenen Invertertypen nicht klar ist. Anbei noch eine bessere Übersicht meiner Anlage.

Das sieht nun doch etwas anders aus als gedacht. Du hast offensichtlich eine Kombination aus MultiplusII und einem MPPT.
Dann definierst du keinen! PV-WR, sondern einen Batterie-Wechselrichter und ein Solar-Ladegerät. Das ist vergleichbar mit meinen setupInverterDev02 (MPPT) und setupInverterDev03 (MuliPlusII):

Code Auswählen Erweitern

setupInverterDev02 = MQTT2_cerboGX_c0619ab34e08_solarcharger_Common feed=bat asynchron=0 pvIn=Yield_Power_value:W pvOut=Yield_Power_value:W limit=100 capacity=2080 etotal=Yield_System_value:kWh strings=Schleppdach
setupInverterDev03 = MQTT2_cerboGX_c0619ab34e08_vebus 
                     dc2ac=DC_IN:W
                     ac2dc=DC_OUT:W
                     capacity=7200
                     strings=none
                     asynchron=0


noch eine Frage, wie wird die Flow-Grafik getriggert? Die Aktualisierung scheint nicht an den Readings zu hängen

Die Grafik wird bei einem Update von "state" aktualisiert. state muß also Events generieren.
Eine Änderung erfolgt nur in der Raumansicht, nicht in der Datailansicht.

[DS_Starter]

@all,

die neue Version ist nun mit der v2.11.0 eingecheckt.

Wir erfassen seit geraumer Zeit beim Laden der BEV die verwendete Phasenanzahl zzgl. der Ladeleistung.
Nun werden diese Information (Phasenzahl) beim CON KI-Training mit verwendet. Bedeutet, der Input steigt um einen Wert wenn man "bev" in seinem aiConProfile-Schlüssel verwendet.

In diesem Fall ist ein NEUTRAINING erforderlich da sonst CON KI Inferenz auf Fehler läuft und die Legacy Prognose als Fallback verwendet.

Nochmal der Hinweis, in dieser Version ist das Reading Battery_OptimumTargetSoC_XX entfernt.
Verwendet statt dessen bitte das Reading Battery_OptimumBaseSoC_XX in euren eigenen Codes.

Hier das komplettierte Changelog dieser Version:

Code Auswählen Erweitern

## [v2.11.0]
09.11.2026 Rev. 31886

- **Neu:**
  * **Eigener Regenmengenmesser**: Im Attribut 'setupEnvironment' kann mit dem neuen Schlüssel 'rainAmount=<Device>:<Reading>' ein eigener Regenmesser angegeben werden. Das Reading muss die Regenmenge der aktuellen Stunde in mm (l/m²) liefern.
    - Der Messwert überschreibt für die aktuelle Stunde (NextHour00) den Niederschlagswert 'rr1c' der Wetter-API. Er wird damit auch in 'nexthours', 'circular' und 'pvHistory' übernommen, und damit auch in den AI-Rohdaten.
    - Ist das Device oder Reading nicht vorhanden, nicht numerisch oder negativ, bleibt der API-Wert erhalten.
  * **Header-Anzeige**: 'rainAmount' ist als Wert in 'graphicControl' → 'headerShowEnv' auswählbar.
      Angezeigt wird die Regenmenge der aktuellen Stunde in mm, mit dem Messwert oder ohne eigenen Messer mit dem API-Wert.
  Das Symbol wechselt nach Menge zwischen 'rain_light' (< 2,5 mm), 'rain' (2,5 bis < 7,6 mm) und 'rain_heavy' (≥ 7,6 mm).
  Bei 0 mm wird das Symbol grau dargestellt.
    - Commandref (DE/EN) für 'setupEnvironment' und 'headerShowEnv' ergänzt.
  * Patch Subs _aiFannBevConsumerAggregate, _aiFannBevHistArray, _aiFannBuildLagFeatures, aiFannConDataLoad, aiFannConInfer,
    _aiFannFeatureBuilder, FEATURE_BLOCKS
  * **KI Verbrauchsprognose**: BEV Phasenanzahl (bevcsmPhasesXX, Consumer-Schlüssel phases) als Lag1-Feature bev_phases_lag1
      (mittlere Phasenanzahl der ladenden EVs relativ zu 3 Phasen, nur Stunden mit Ladung), neuer Feature-Block bev_phases in
  allen Profilen mit BEV
      Hinweis: der Eingangsvektor wächst bei BEV-Profilen um ein Feature -> neues Training der KI erforderlich

- **Fix:**
  * Die Hilfsfunktionen _aiFannBevHistArray, _aiFannHpOpmodeHistArray und _aiFannCycleConsumerHistArray haben ihre Ergebnis-Arrays als Referenz sowohl in den
    pvHistCache gelegt als auch an den Aufrufer zurückgegeben. Da aiFannConInfer diese Arrays im Prognosehorizont per push fortschreibt, wurden die gecachten Arrays bei
    jedem Lauf innerhalb derselben Stunde verlängert (Speicherwachstum). Folgeläufe arbeiteten zudem mit verlängerten, nicht mehr zu @flat_targets ausgerichteten
    BEV-/WP-Serien, was die lag1-Features verfälschen konnte. Cache und Rückgabewert verwenden jetzt getrennte Kopien (Cache-Hit und Cache-Insert).
  * getPvHistTargetArray: im Cache-Miss-Fall werden nun ebenfalls Kopien gecacht, sodass der Aufrufer nie dieselben Arrays wie der Cache erhält (konsistent zum Cache-Hit-Pfad).
  * timestringsFromOffset: Cache-Hit und Cache-Insert verwenden eine Kopie des Hashes, damit Änderungen des Aufrufers den Cache nicht verändern können.
  * Speicher: Die LRU-Caches der History-Arrays ('BEVHISTARR', 'CYCLECSMHISTARR',
    'HPOPMODEHISTARR', 'PVHISTARR') behielten pro Stunde einen neuen Eintrag und
    hielten dadurch bis zu 16 Stundenversionen vor, von denen nur die aktuelle noch
    gelesen wird. Veraltete Stunden-Einträge derselben Serie werden jetzt beim
    Anlegen des neuen Eintrags entfernt (neue Funktionen 'LRU_delete' und
    'LRU_purge_stale').
  * Speicherleck: '___ownSpecGetFWwidget' fügte versteckte Readings bei jedem Aufruf erneut
    in das globale Array '@widgetreadings' ein. Das Array wuchs dadurch unbegrenzt
    und verursachte beim Tageswechsel (Task 2) einen RSS-Sprung. Die Merker werden jetzt als Hash je Device
    ('%widgetreadings') geführt, Duplikate entfallen und jedes Device löscht nur seine eigenen Hilfsreadings.

- **Änderung:**
  * Parser __parseAttrEnvironment gehärtet
  * Reading **Battery_OptimumTargetSoC_XX** entfernt
  * Speicher: Serien, die nur aus Nullen bestehen (z. B. BEV- oder Wärmepumpen-Historie
    bei Anlagen ohne entsprechenden Verbraucher), werden im Cache nur noch als Länge
    abgelegt und beim Lesen wieder zu einem Array expandiert ('_aiPackSeries',
    '_aiUnpackSeries'). Der Aufrufer erhält weiterhin eine eigene Kopie.
  * Speicher: Die Größe des 'TS_OFFSET_Cache' wurde von 4000 auf 700 Einträge
    reduziert. Der Cache legte pro Sekunde einen neuen Eintrag an, der praktisch nur
    innerhalb derselben Sekunde wiederverwendet wird.
  * Performance: Die Debug-Prüfung in 'LRU_get', 'LRU_insert' und 'LRU_evict_tail'
    verwendet 'index()' statt eines bei jedem Zugriff neu kompilierten regulären
    Ausdrucks.

- **Diagnose**
  * Neue Zähler 'CNT_BEVHIST_HIT' und 'CNT_BEVHIST_MISS' in '$hash->{HELPER}' für die
    Aufrufe von '_aiFannBevHistArray'.
  * Neue Hilfsfunktion '__logDailyTask': Protokollierung des Prozessspeichers (VmRSS) zu Beginn
    und Ende der täglichen Sonderaufgaben (Tasks 2 bis 7), Verbose 4. RSS nur auf Linux verfügbar, sonst nur Signaltext.

LG,
Heiko