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

[reisner]

Hi,
ich habe nun die Änderungen vorgenommen, das Ergebnis ist aber nicht IO
Meine Definitionen sind:

Code Auswählen Erweitern

ctrlLanguage DE
   event-on-change-reading .*
   plantControl plantCoordinates=latitude->53.804925,longitude->13.188967 cycleInterval=120
   room       WW48
   setupBatteryDev01 PVSF pin=BattCharge:W
pout=BattDisCharge:W
cap=16000
charge=SOC_value
show=2
   setupInverterDev01
   PVSF
     dc2ac=dc2ac:W
     ac2dc=ac2dc:W
     capacity=5000
     strings=none
     asynchron=0
   setupInverterDev02 PVSF feed=bat asynchron=0 pvIn=SCPowerIN_value:W pvOut=SCPowerOUT_value:W etotal=DCEnergie:Wh capacity=4000
   setupInverterStrings KI-based
   setupMeterDev Batt_values gcon=GenCharge_value:W contotal=GenEnergie:kWh feedtotal=ft:kWh gfeedin=gfi:W conprice=0.16:€
   setupRadiationAPI VictronKI-API
   setupStringAzimuth WW48=S
   setupStringDeclination WW48=50
   setupStringPeak KI-based=5.0
   setupWeatherDev1 OpenMeteoWorld-API
In der VRM Sicht von Victron ist die Situation zu sehen und die FTUI Sicht bildet diese auch nach.
Leider nicht im SolarForecast. Die Readings für die Devices waren wie folgt:

Code Auswählen Erweitern

READINGS:
     2026-11-11 14:20:40   BattCharge      46
     2026-11-11 14:20:40   BattDischarge   0
     2026-11-11 14:20:42   DCEnergie       1047.13918385235
     2026-11-11 14:20:40   DCPower_value   46
     2026-11-11 14:20:42   SCPowerIN_value 186
     2026-11-11 14:20:42   SCPowerOUT_value 186
     2026-11-11 14:20:16   SOC_value       45
     2026-11-11 14:20:42   ac2dc           46
     2026-11-11 14:20:42   dc2ac           120
Die Werte stimmen nicht mit dem Flow überein, das ich noch nicht gefunden habe, wie ich das state des Forecast Devices triggern kann, ein fhem "setreading PVfc state updated"; funktioniert nicht. Die Flow Übersicht ist mir nicht so wichtig, da ich den Forecast aber zur Batterieladesteuerung nutzen will, um einen reduzierten Nachtstrom zwischen 00:00 und 05:00 zu nutzen, sollten die berechneten Werte stimmen. Der Verbrauch wird nicht richtig abgebildet. Wo ist mein Fehler?

Danke

[DS_Starter]

Du bist schon nahe dran.

Der Reihe nach.

Die Werte stimmen nicht mit dem Flow überein, das ich noch nicht gefunden habe, wie ich das state des Forecast Devices triggern kann, ein fhem "setreading PVfc state updated"; funktioniert nicht.

Da must du gar nichts machen. state wird automatisch mit jedem Zyklus upgedated. Du darfst die Events von state nur nicht verhindern mit event-on-change-reading z.B.

Diese zwei Readings sehen komisch aus:

Code Auswählen Erweitern

     2026-11-11 14:20:42   ac2dc           46
     2026-11-11 14:20:42   dc2ac           120
Der Batteriewechselrichter lädt und entlädt die Batterie zur gleichen Zeit? Kann ich nicht glauben.

Dann

Code Auswählen Erweitern

setupMeterDev Batt_values gcon=GenCharge_value:W
Ich kenne deine Anlage nicht, aber GenCharge_value klingt nach einer Ladeleistung, der Meter soll an der Stelle nur den Bezug ins Hausnetz liefern (gcon = Grid Consumption).
Das Device heißt auch "Batt_values", bisschen eigenartig für einen Netz-Meter.

Damit man mehr sieht schalte ctrlDebug=collectData ein. Im Log werden mit jedem Zyklus die gemessenen Daten geschrieben.
Da sieht man was rein und raus geht und bei welchem Device.

[reisner]

Hi, anbei noch einmal eine Sicht auf meine Verdrahtung.

Code Auswählen Erweitern

Diese zwei Readings sehen komisch aus:


     2026-11-11 14:20:42   ac2dc           46
     2026-11-11 14:20:42   dc2ac           120
Der Batteriewechselrichter lädt und entlädt die Batterie zur gleichen Zeit? Kann ich nicht glauben.Wenn der Verbrauch am AC Ausgang des MultiplusII niedriger ist als die bereitgestellte Leistung des Ladereglers, dann wird sowohl die Batterie geladen (ac2dc) und auch das Haus versorgt (dc2ac).

Code Auswählen Erweitern

Dann

setupMeterDev Batt_values gcon=GenCharge_value:W

Ich kenne deine Anlage nicht, aber GenCharge_value klingt nach einer Ladeleistung, der Meter soll an der Stelle nur den Bezug ins Hausnetz liefern (gcon = Grid Consumption).
Das Device heißt auch "Batt_values", bisschen eigenartig für einen Netz-Meter.

Die Anlage stand einst autark auf dem Feld und die Batterie wurde bei Bedarf, durch einen Generator geladen -> GenCharge , ist nun ein wenig irreführend. Das Reading enthält nun den Netzbezug für das Batterieladen über den MultiplusII.
Hier das Log zum Flow unten:

Code Auswählen Erweitern

2026.11.11 17:14:20 1: PVfc DEBUG> collect Inverter 01 data - device: PVSF, source: bat, delivery: default =>
2026.11.11 17:14:20 1: PVfc DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 153 W, etotal: 0 Wh
2026.11.11 17:14:20 1: PVfc DEBUG> collect Inverter 02 data - device: PVSF, source: pv, delivery: bat =>
2026.11.11 17:14:20 1: PVfc DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 1188 Wh
2026.11.11 17:14:20 1: PVfc DEBUG> summary data of all Inverters - pv: 0 W, this hour Generation: 0 Wh
2026.11.11 17:14:20 1: PVfc DEBUG> State of Plant derating: 0, info: reductionState not set
2026.11.11 17:14:20 1: PVfc DEBUG> currently saved 'pvrlvd' value: 1
2026.11.11 17:14:20 1: PVfc DEBUG> current percentage pvrl/pvapifc deviation of hod 18: 100 % -> pvrlvd: 1
2026.11.11 17:14:20 1: PVfc DEBUG> collect Energy Meter data - device: Batt_values =>
2026.11.11 17:14:20 1: PVfc DEBUG> gcon: 0 W, gfeedin: 0 W, contotal: 0 Wh, feedtotal: 0 Wh
2026.11.11 17:14:20 3: PVfc - WARNING - 'Batt_values' - the total energy drawn from grid was reset and is registered with >0<. Check Reading 'GenEnergie'
2026.11.11 17:14:20 3: PVfc - WARNING - 'Batt_values' - the total energy feed in to grid was reset and is registered with >0<.
2026.11.11 17:14:20 1: PVfc DEBUG> collect Battery 01 Readings data: device=PVSF =>
2026.11.11 17:14:20 1: PVfc DEBUG> pin: 0 W, pout: 0 W, totalin: 0 Wh, totalout: 0 Wh, soc: 43
2026.11.11 17:14:20 1: PVfc DEBUG> EnergyConsumption input -> PV: 0 Wh, PP: 0 Wh, GridIn: 0 Wh, GridCon: 0 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2026.11.11 17:14:20 1: PVfc DEBUG> EnergyConsumption result -> 0 Wh
2026.11.11 17:14:20 1: PVfc DEBUG> current Power values -> PV2Node: 0 W, PV2Bat: 0, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 0 W
2026.11.11 17:14:20 1: PVfc DEBUG> current Power Battery (all) -> BatIn: 0 W (Node2Inv2DC: 0 W), BatOut: 0 W (DC2Inv2Node: 153 W)
2026.11.11 17:14:20 1: PVfc DEBUG> current Consumption result -> 153 W

Gruß

[DS_Starter]

Deine Anlage mit Paneelen -> MPPT -> Batterie-WR -> Hausnetz sieht meiner Anlage sehr ähnlich.
Aktuell würde dein Haus 153W verbrauchen, die ausschlielich von der Batterie kommen.
Kein Netzbezug.

Ist das richtig?

Das Debug gibt genau das wieder und ist konsistent.
Mich stört aber:

Code Auswählen Erweitern

2026.11.11 17:14:20 1: PVfc DEBUG> gcon: 0 W, gfeedin: 0 W, contotal: 0 Wh, feedtotal: 0 Wh
2026.11.11 17:14:20 3: PVfc - WARNING - 'Batt_values' - the total energy drawn from grid was reset and is registered with >0<. Check Reading 'GenEnergie'
2026.11.11 17:14:20 3: PVfc - WARNING - 'Batt_values' - the total energy feed in to grid was reset and is registered with >0<.
Das bedeutet, dass contotal und feedtotal keine aufsteigenden Zähler sind. Das muß aber sein, denn zumindest der Netzbezug contotal, also die Summe der jemals bezogenen Energie, wird nicht 0 sein sondern immer mal etwas steigen sofern du Energie vom Netz beziehst. Und wenn es 0 ist und 0 bleibt wäre das auch ok. Nur hier der Wert anzusteigen (vermutlich contotal) und dann wieder zu sinken.