76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Genauso würde es Sinn machen sich die mittlere Helligkeit zu den Stundenwerten zu merken. rad1h bzw. wcc werden ja auch schon gespeichert, aber noch nicht mit einem realen Messwert untersetzt.

Im Prinzip ja. Allerdings wäre hier nur der Diffusionsstrahlungsanteil betroffen.
Manche API's liefern keine die Strahlung, sondern nur das erwartete Ergebnis pro String (SolCast z.B.). Deswegen gibt es dafür zur Zeit auch keine KI Unterstützung weil dieser wichtige Input fehlt.
D.h. es gibt keinen Helligkeitswert von den verwendeten API's (zumindest kenne ich keinen) und somit wäre dieser Wert ausschließlich bei einem installierten Helligkeitssensor vorhanden.
In allen anderen Fällen wäre er nur 1 bei Tag und 0 bei Nacht ... etwas zu undifferenziert.

Möglicherweise meinst du aber einen echten Strahlungssensor, wie den von Victron: https://www.victronenergy.de/upload/documents/Datasheet-SolarSense-750-DE.pdf

Damit hätte man vermutlich ein echtes Pendant zur prognostizierten Einstrahlung. Zumindest in Verbindung mit API's die sie liefern.

[yvl]

Hallo,

ich habe eine Frage zur Visualisierung:

Wie kann ich einstellen,
das 1. die gesamte Anzeige linksbündig ist,
und 2. die Balkendiagramme linksbündig sind oder mittig, aber nicht am rechten Rand kleben...

Hat da jemand eine Idee ?
Bei mir sieht das immer so aus, wie im Bild anbei.

[bombardi]

Ich bin noch neu im Umgang mit solarforecast und gebe zu nicht alle 482 Seiten gelesen zu haben. Hier meine Frage:
Ich benutze Solarforecast nur zur Visualisierung meiner PV-Anlage und der Verbraucher, darum möchte ich die zweite Zeile unter den Verbrauchern mit der Restlaufzeit ausblenden. Geht das und falls ja, wie?

[DS_Starter]

Wie kann ich einstellen,
das 1. die gesamte Anzeige linksbündig ist,
und 2. die Balkendiagramme linksbündig sind oder mittig, aber nicht am rechten Rand kleben...

Dafür gibt es keine spezifischen Einstellungen in SF. Das Bild ist in der Horizontale zentriert.
Vermutlich ist es ein Spezifikum oder Einstellung deines verwendeten Styles?
Der Screenshot zeigt FHEMWEB F18 und F11. Vergleiche deine Darstellung mit diesen Styles.

[DS_Starter]

darum möchte ich die zweite Zeile unter den Verbrauchern mit der Restlaufzeit ausblenden. Geht das und falls ja, wie?

Das geht mit

Code Auswählen Erweitern

attr ... flowGraphicControl showconsumerremaintime=0

[bombardi]

Danke, das war genau was ich wollte. Hatte ich übersehen.

[TheTrumpeter]

D.h. es gibt keinen Helligkeitswert von den verwendeten API's (zumindest kenne ich keinen) und somit wäre dieser Wert ausschließlich bei einem installierten Helligkeitssensor vorhanden.

Im Endeffekt geht es darum, falsche Wetterprognosen auszusieben, damit keine falschen Korrekturfaktoren eingelernt werden bzw. sich das NN in der Prognose nicht völlig falsche historische Daten als Grundlage nimmt.
Aber das haben wir vor einiger Zeit ohnehin schon mal diskutiert.

[DS_Starter]

@all,

die v2.10.11 in meinem contrib ist upgedatet.

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, vor dem Checkin der v2.10.11 werde ich das Reading Battery_OptimumTargetSoC_XX entfernen. In der Contrib-Version ist es noch nicht der Fall.
Stellt bitte eure eigenen Codes auf Battery_OptimumBaseSoC_XX um falls nötig.

Hier das komplettierte Changelog dieser Version:

Code Auswählen Erweitern

## [v2.10.11]
03.11.2026 Rev. xxxxx

- **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.

- **Change:**
  * Parser __parseAttrEnvironment gehärtet


[Parallix]

Eine Frage an diejenigen, die via dayAfterTomorrowPVforecast in ctrlSpecialReadings  gesetzt haben und die OpenMeteoDWD_D2-API verwenden: Bekommt ihr (derzeit) auch:

Code Auswählen Erweitern

special_dayAfterTomorrowPVforecast 0 (no data available)

[DS_Starter]

Bei mir ganz normal (SolCast:

Code Auswählen Erweitern

special_dayAfterTomorrowPVforecast   22997 Wh

OpenMeteo bei mir auch ok.
Vermutlich liefert dein Strahlungslieferant gerade nicht so weit aus bzw. die Kommunikation zu der API ist gestört?

[Parallix]

Bei mir ganz normal (SolCast:

Code Auswählen Erweitern

special_dayAfterTomorrowPVforecast   22997 Wh

OpenMeteo bei mir auch ok.
Vermutlich liefert dein Strahlungslieferant gerade nicht so weit aus bzw. die Kommunikation zu der API ist gestört?

In der Tat bekomme ich jetzt wieder einen Wert:

Code Auswählen Erweitern

special_dayAfterTomorrowPVforecast 3784 WhUnschön ist natürlich, dass zeitweise gar keine Werte zur Verfügung gestellt werden, was ich verstehen kann, wenn vom Lieferant bislang noch nichts für den betreffenden Tag geliefert wurde.  Was macht SF eigentlich, wenn der Lieferant keinen Wert liefert nachdem er zuvor für den betreffenden Tag (hier übermorgen) die erforderlichen Werte bzw. einen Summenwert geliefert hat. Bleibt dann der alte Wert erst mal bestehen, sodass zumindest eine Planungsgrundlage vorhanden ist?

[DS_Starter]

Was macht SF eigentlich, wenn der Lieferant keinen Wert liefert nachdem er zuvor für den betreffenden Tag (hier übermorgen) die erforderlichen Werte bzw. einen Summenwert geliefert hat. Bleibt dann der alte Wert erst mal bestehen, sodass zumindest eine Planungsgrundlage vorhanden ist?

SF hat einen Zwischenspeicher, aus dem geschöpt wird solange es geht. D.h. API-Ausfälle sind nicht relevant solange es genug Daten für den zukünftigen (interessierenden) Zeitraum gibt.

Den Zwischenspeicher kann man sehen mit:

Code Auswählen Erweitern

get ... radiationApiData

Der sieht bei mir aktuell so aus:

Code Auswählen Erweitern

Schleppdach => 2026-11-07 07:00:00 => pv_estimate50: 46
               2026-11-07 08:00:00 => pv_estimate50: 187
               2026-11-07 09:00:00 => pv_estimate50: 211
               2026-11-07 10:00:00 => pv_estimate50: 676
               2026-11-07 11:00:00 => pv_estimate50: 793
               2026-11-07 12:00:00 => pv_estimate50: 242
               2026-11-07 13:00:00 => pv_estimate50: 222
               2026-11-07 14:00:00 => pv_estimate50: 212
               2026-11-07 15:00:00 => pv_estimate50: 86
               2026-11-07 16:00:00 => pv_estimate50: 6
               2026-11-08 07:00:00 => pv_estimate50: 8
               2026-11-08 08:00:00 => pv_estimate50: 57
               2026-11-08 09:00:00 => pv_estimate50: 172
               2026-11-08 10:00:00 => pv_estimate50: 274
               2026-11-08 11:00:00 => pv_estimate50: 319
               2026-11-08 12:00:00 => pv_estimate50: 294
               2026-11-08 13:00:00 => pv_estimate50: 217
               2026-11-08 14:00:00 => pv_estimate50: 120
               2026-11-08 15:00:00 => pv_estimate50: 41
               2026-11-08 16:00:00 => pv_estimate50: 4
               2026-11-09 07:00:00 => pv_estimate50: 11
               2026-11-09 08:00:00 => pv_estimate50: 99
               2026-11-09 09:00:00 => pv_estimate50: 404
               2026-11-09 10:00:00 => pv_estimate50: 701
               2026-11-09 11:00:00 => pv_estimate50: 870
               2026-11-09 12:00:00 => pv_estimate50: 956
               2026-11-09 13:00:00 => pv_estimate50: 910
               2026-11-09 14:00:00 => pv_estimate50: 687
               2026-11-09 15:00:00 => pv_estimate50: 351
               2026-11-09 16:00:00 => pv_estimate50: 16
               2026-11-10 07:00:00 => pv_estimate50: 6
               2026-11-10 08:00:00 => pv_estimate50: 49
               2026-11-10 09:00:00 => pv_estimate50: 170
               2026-11-10 10:00:00 => pv_estimate50: 284
               2026-11-10 11:00:00 => pv_estimate50: 394
               2026-11-10 12:00:00 => pv_estimate50: 222
Süddach => 2026-11-07 07:00:00 => pv_estimate50: 143
           2026-11-07 08:00:00 => pv_estimate50: 520
           2026-11-07 09:00:00 => pv_estimate50: 514
           2026-11-07 10:00:00 => pv_estimate50: 1974
           2026-11-07 11:00:00 => pv_estimate50: 2334
           2026-11-07 12:00:00 => pv_estimate50: 591
           2026-11-07 13:00:00 => pv_estimate50: 543
           2026-11-07 14:00:00 => pv_estimate50: 536
           2026-11-07 15:00:00 => pv_estimate50: 214
           2026-11-07 16:00:00 => pv_estimate50: 15
           2026-11-08 07:00:00 => pv_estimate50: 19
           2026-11-08 08:00:00 => pv_estimate50: 136
           2026-11-08 09:00:00 => pv_estimate50: 415
           2026-11-08 10:00:00 => pv_estimate50: 672
           2026-11-08 11:00:00 => pv_estimate50: 783
           2026-11-08 12:00:00 => pv_estimate50: 720
           2026-11-08 13:00:00 => pv_estimate50: 529
           2026-11-08 14:00:00 => pv_estimate50: 286
           2026-11-08 15:00:00 => pv_estimate50: 102
           2026-11-08 16:00:00 => pv_estimate50: 11
           2026-11-09 07:00:00 => pv_estimate50: 25
           2026-11-09 08:00:00 => pv_estimate50: 250
           2026-11-09 09:00:00 => pv_estimate50: 1178
           2026-11-09 10:00:00 => pv_estimate50: 2106
           2026-11-09 11:00:00 => pv_estimate50: 2631
           2026-11-09 12:00:00 => pv_estimate50: 2926
           2026-11-09 13:00:00 => pv_estimate50: 2821
           2026-11-09 14:00:00 => pv_estimate50: 2168
           2026-11-09 15:00:00 => pv_estimate50: 1160
           2026-11-09 16:00:00 => pv_estimate50: 51
           2026-11-10 07:00:00 => pv_estimate50: 14
           2026-11-10 08:00:00 => pv_estimate50: 119
           2026-11-10 09:00:00 => pv_estimate50: 411
           2026-11-10 10:00:00 => pv_estimate50: 705
           2026-11-10 11:00:00 => pv_estimate50: 1040
           2026-11-10 12:00:00 => pv_estimate50: 601

D.h. wenn die API ausfallen würde, sind Daten bis in drei Tagen verfügbar. Das ist auch der Abfragebereich in die Zukunft. Das die dann natürlich nicht aktualiert sind, steht auf einem anderen Blatt, aber darum geht es jetzt ja nicht.

Der konrete Wert für Übermorgen kommt aus der Summierung der Nexthours-Daten.

Code Auswählen Erweitern

get ... nextHours

Die enden jetzt Übermorgen in der letzten Stunde:

Code Auswählen Erweitern

NextHour59 => starttime: 2026-11-09 23:00:00, day: 09, weekday: Mo, holiday: 0, hourofday: 24, today: 0
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, pvfcfeedlim: 0, aihit: 0
              conlegfc: 661, conaifc: 644, confc: 644, conbiascorr: -37, confcEx: 661, weatherid: 145, wcc: 95, rr1c: 0.00
              temp: 3.20, windspeed: 0.71, windspeed_fast: 0.71, rad1h: -, sunaz: 349.10, sunalt: -55.30, DoN: 0
              rrange: 0.00, crange: 95, DaysInRange: 2, correff: 1.00/-
              soc01: 69.0, soc02: -, soc03: -, socprogwhsum: 22042
              rcdchargebat01: 1, rcdchargebat02: -, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
              strategybat01: smartPower, strategybat02: -, strategybat03: -