76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[tomcat.x]

Den Parameter hatte ich dann wohl nicht richtig verstanden, als ich ihn vor längerer Zeit beim Hinzufügen des Speichers gesetzt hatte. Sonsts wären mir auch die 90 % klar gewesen. Mit 50 sieht es besser aus. Aber eigentlich macht das auch keinen Sinn, wenn ich das gar nicht regeln will. Hatte dann erst stepSoC=0 gesetzt, aber schließlich das Attribut komplett enfernt. Macht das einen Unterschied?

Aber ich glaube, bei mir steht noch was schief. Vor Deiner Antwort hatte ich die Balkengrafik erweitert, um die Verbrauchsvorhersage besser sehen zu können. Die Balken für consumptionForcast sehen gut aus, aber consumption ist tagsüber zu niedrig, in der Zeit wenn Strom erzeugt wird.

Nur zum Verständnis, consumptionForcast soll den Verbrauch aller Verbraucher vorhersagen, nicht nur der registrierten? Und consumption entsprechend den realen Verbrauch aller Verbraucher in Sunne anzeigen, egal wo der Strom herkomnt? Die Balken bei gridConsumption sollten dann in Zeiten ohne PV-Erzeugung und ohne Strom aus der Batterie mit denen von consumption übereinstimmen?

[300P]

Nur zum Verständnis, consumptionForcast soll den Verbrauch aller Verbraucher vorhersagen, nicht nur der registrierten?

Ja

Und consumption entsprechend den realen Verbrauch aller Verbraucher in Sunne anzeigen, egal wo der Strom herkomnt?

Ja

Die Balken bei gridConsumption sollten dann in Zeiten ohne PV-Erzeugung und ohne Strom aus der Batterie mit denen von consumption übereinstimmen?

Ja

Einschränkung : Es kann möglicherweise "Überlappungen" geben - es wird in SF alles auf eine volle Stunde dargestellt / bezogen !!

[DS_Starter]

Moin,

Aber eigentlich macht das auch keinen Sinn, wenn ich das gar nicht regeln will. Hatte dann erst stepSoC=0 gesetzt, aber schließlich das Attribut komplett enfernt. Macht das einen Unterschied?

Wenn du das Attribut entfernst und die Batterie nicht aktiv durch SF steuerst bekommst du auch keine schlüssige Batterie SoC Vorhersage da SF Grenzwerte und die Steuerung durch dein BMS bzw. deine Batterieanlage nicht kennt.

Wenn du das nicht brauchst/möchtest kannst du das Attr löschen, darfst dann natürlich keine sinnvolle SoC-Prognose erwarten.

Einschränkung : Es kann möglicherweise "Überlappungen" geben - es wird in SF alles auf eine volle Stunde dargestellt / bezogen !!

Und nicht nur das.
Die Wertelieferanten (Zählerdevices etc.) in FHEM laufen nicht synchron. D.h. die diversen Summierungen sind zum Zeitpunkt X in den seltensten Fällen exakt stimmig oder heben sich exakt zu "0" auf.

[tomcat.x]

Ist schon klar, dass die Werte nicht hundertprozentig übereinstimmen, aber die Richtung sollte passen. Das ist auch für letzte Nacht so (kein PV, Batterie auf 10 % runter). Auch jetzt in den Morgenstunden ergibt PV + Grid zusammen ungefähr das, was der Balken bei consumption anzeigt. Gestern tagsüber war der Balken aber teilweise unter 10 Wh. Das dürften die Stunden gewesen sein, als die Batterie ins Spiel kam. Ich werde das mal heute beobachten. Wobei es schon seltsam ist, denn wenn der Verbrauch nicht richtig ermittelt würde, dürfte auch die Verbrauchsvorhersage nicht passen. Das tut sie aber. Wie gesagt, habe ich consumption + consuptionForecast erst seit gestern in der Balkengrafik und vorher nie drauf geschaut (auf die stündlichen Verbrauchswerte in SF).

Wenn du das nicht brauchst/möchtest kannst du das Attr löschen, darfst dann natürlich keine sinnvolle SoC-Prognose erwarten.

Ja, ich habe schon gesehen, dass der SoC dann teilweise mit unter 10 % vorhergesagt wird, was die Batterie aber gar nicht macht. Also dann Werte eintragen, aber stepSoC=0? Denn nur so kann ich erreichen, dass lowSoc=upSoC ist und SF nicht davon ausgeht, die Batterie steuern zu können. Denn das kann es nicht. Weder kann es der Batterie sagen, ob sie laden soll oder nicht, noch gibt es relevante Verbraucher, über die das beeinflusst werden könnte.

[Parallix]

Hallo Heiko,

Findest du dort einen absurd hohen Wert?

Ja, da finde ich einen 19Mio-Wert in der achten Zeile ...

Da der Verbrauch vermutlich auf Basis von Readings bestimmt wird, deren Werte streng monoton wachsend sein sollten, müsste sich in SF doch eigentlich eine automatische Löschung über ein Median-Filter auf einbauen lassen.

Nun könnte man anführen, dass bei Einsatz eines Filters Probleme nicht mehr sichtbar werden. Das ist aber nur solange richtig, wie es kein geeignetes Reading gibt, in dem Abnormalitäten (hier z.B. die Abweichung von der Monotonie) gemeldet werden.

Mein Vorschlag zur Weiterentwicklung von SF ist es daher, den o.g. Weg zu beschreiten.

PS: Bei der PV-History könnte und sollte man natürlich den gleichen Weg gehen.

[peterboeckmann]

Hallo Heiko,

ich erinnere mich dunkel, dass man früher mal max. 16 Consumer definieren konnte. Aktuell können 20 Consumer definiert werden.
Gibt es einen technischen Grund für diese Begrenzung oder ließe sich die Grenze auch auf 30 erhöhen?

Wem die Flussgrafik oder die Legende damit zu unübersichtlich wird, der kann die Consumer dort ja einzeln ein- oder ausblenden.

noshow   Verbraucher bzw. bestimmte Elemente ausblenden oder einblenden (optional). Die Werte können kombiniert werden (siehe Beispiel).
0 - der Verbraucher wird eingeblendet (default)
1 - der Verbraucher wird ausgeblendet
2 - der Verbraucher wird in der Verbraucherlegende ausgeblendet
3 - der Verbraucher wird in der Flußgrafik ausgeblendet
9 - das Schaltelement des Verbrauchers wird in der Verbraucherlegende ausgeblendet
[Device:]Reading - Reading im Verbraucher oder (optional) einem alternativen Device.
Hat das Reading den Wert 0 oder ist nicht vorhanden, wird der Verbraucher eingeblendet.
Die Wirkung der möglichen Readingwerte 1, 2 und 3 ist wie beschrieben.

Viele Grüße,
Peter

[alkazaa]

@Parallix, Du schriebst kürzlich

Vor diesem Hintergrund habe ich längere Zeit mit der Programmierung eines auf SF aufsetzenden Ladecontroller beschäftigt, der dafür sorgt, dass auch bei hohen SOC-Ständen keine Zellspannung über einem konfigurierbaren Maximalwert (bei mir mit meinem LiFePO4-System auf 3500 mV eingestellt) liegt.
...
Seit vielen Wochen betreibe ich nun diesen Controller, möchte kurz über meine Erfahrungen damit berichten und daraus ggf. ableitbare zukünftige SF-Features  mit Euch gemeinsam entwickeln.

Ich bin an diesem controller sehr interessiert, aber in SF ist er ja wohl noch nicht integriert(?). Würdest Du den code im jetztigen Zustand schon teilen wollen? (Ich habe eine BYD HVS 10.2, die einzelnen Zellspannungen sind damit auslesbar).

[Parallix]

@Parallix, Du schriebst kürzlich

Vor diesem Hintergrund habe ich längere Zeit mit der Programmierung eines auf SF aufsetzenden Ladecontroller beschäftigt, der dafür sorgt, dass auch bei hohen SOC-Ständen keine Zellspannung über einem konfigurierbaren Maximalwert (bei mir mit meinem LiFePO4-System auf 3500 mV eingestellt) liegt.
...
Seit vielen Wochen betreibe ich nun diesen Controller, möchte kurz über meine Erfahrungen damit berichten und daraus ggf. ableitbare zukünftige SF-Features  mit Euch gemeinsam entwickeln.

Ich bin an diesem controller sehr interessiert, aber in SF ist er ja wohl noch nicht integriert(?). Würdest Du den code im jetztigen Zustand schon teilen wollen? (Ich habe eine BYD HVS 10.2, die einzelnen Zellspannungen sind damit auslesbar).

Aktuell ist der Controller noch sehr sehr eng auf mein Setup ausgerichtet. Sobald ich wieder etwas Luft habe, werde ich den Code überarbeiten und dann hier auch teilen.

Ein Einbau in SF ist grundsätzlich denkbar, widerspricht meines Erachtens aber dem Ansatz von SF, was perfekt zu Steuerung geeignet ist, ggf. auch zur Regelung, dann aber mit einer sehr geringen Abtastfrequenz.

Der Controller muss insb. in den Grenzbereichen, in denen sich der Innenwiderstand der Zellen stark variiert, recht schnell sein, sodass er beim Ausbrechen einer Zelle sofort die Ladeleistung reduzieren oder gar auf Null setzen kann. Das passiert bei mir in einem DOIF, hauptsächlich mit folgendem Codeschnipsel:

Code Auswählen Erweitern

if( $maxCellmVoltage > $lowerTermVoltage + $voltageOffset ) {
  $current *= 1.0 - ($maxCellmVoltage - $lowerTermVoltage) / $termVoltageRange;

  $current = $current < $batMinChgCurrent ? $batMinChgCurrent : $current;
     
  if( $maxCellmVoltage > $upperTermVoltage ) {
    $current = 0.0;
  }
}

Hier auch gleich eine kurze Beschreibung der Variablen:

• current: Ladestrom, aus der von SF angegeben Ladeleistung und der akt. BAT-Spannung abgeleitet
• maxCellmVoltage: Größte aktuelle Zellspannung der Batterie
• lowerTermVoltage: Zellspannung, ab der der Controller die Ladestrom im Controller verändert wird
• upperTermVoltage: Höchste Zellspannung, oberhalb derer keine weitere Ladung mehr erfolgt
• voltageOffset: Spannungsabfall am Innenwiderstand der Zelle für ein SOC in [20,90] andernfalls voltageOffset=0
• termVoltageRange = upperTermVoltage - lowerTermVoltage
• batMinChgCurrent: Kleinster am Wechselrichter einstellbarer Ladestrom

Wichtig:

• upperTermVoltage muss deutlich unterhalb der Ladeschlussspannung der in der BAT verbauten Zellen liegen. Andernfalls muss darauf geachtet werden, dass mit current ein geeigneter Ladeschlussstrom in der Ladeschlussphase vorliegt.
• SF setzt Battery_ChargeOptTargetPower_XX auf pinmax, sofern Battery_ChargeUnrestricted_XX == 1. Wenn pinmax nicht so eingestellt wird, dass in diesem Fall mit deutlich weniger als 1C geladen wird, muss current, insb. für der Ladeschlussphase, reduziert werden.

Bei meinem LiFePO4-BAT verwende ich

• lowerTermVoltage = 3375
• upperTermVoltage = 3475

wobei diese Angaben natürlich in mV sind.

PS: Mit ist bewusst, dass die Variablennamen noch nicht ganz konsistent gewählt wurden.

[DS_Starter]

@tomcat.x,

Ja, ich habe schon gesehen, dass der SoC dann teilweise mit unter 10 % vorhergesagt wird, was die Batterie aber gar nicht macht. Also dann Werte eintragen, aber stepSoC=0?

stepSoC=0 deaktiviert das SoC-Management für diese Batterie. Die Prognose für den SoC wird weiterhin funktionieren, wobei dann bestimmte Grenzen nicht aktiv sind, aber vermutlich durchaus brauchbar.
Es ist für temporäre Deaktivierungen gedacht wenn man das Attribut nicht löschen möchte weil man es später wieder aktivieren möchte.

Da der Verbrauch vermutlich auf Basis von Readings bestimmt wird, deren Werte streng monoton wachsend sein sollten, müsste sich in SF doch eigentlich eine automatische Löschung über ein Median-Filter auf einbauen lassen.

Ein automatischer! Median-Filter ist dafür leider nicht geeignet, denn ich möchte ja die realen Zahlen haben. Wenn der User Besuch hat und 2 EV geladen werden kann der Verbrauch schonmal ungewöhnlich hoch sein, ist aber dann kein Fehler.
Auch ein rein empirische obere Grenze ist dafür m.M. nach ungeeignet.
Auf der anderen Seite bekommt man nur so eventuelle Probleme im eigenen FHEM Universum überhaupt mit und kann gezielt gegensteuern. SF bügelt vieles weg, aber es gibt Situationen wo man auf Modulautoren einwirken sollte damit
an der Quelle schon Einfluß genommen wird. Das fördert allgemein die Datenqualität auch für SVG's und andere Anbhängigkeiten.

@peterboeckmann,

Gibt es einen technischen Grund für diese Begrenzung oder ließe sich die Grenze auch auf 30 erhöhen?

Nein, nur einmal die Problematik in der Flußdarstellung und weiterhin entsprechend viele Attribute in der Attributliste.
Natürlich werden die gasammelten Daten und Ausdrucke in den Datenspeichern ebenfalls mehr.
Aber sonst fällt mir eigentlich nichts weiter ein.




 

[300P]

Rückfrage zum Thema NN:

Ab wann wurde noch eine Driftbedingte Rekalibrierung (evtl.) vorgenommen?
24 h / 48 h oder >= 48 h nach dem Contrain ?

Ich habe jetzt 48 h nach dem letzten Training und bekomme keine Rekalibrierungswerte in der Anzeige.

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 17.03.2026 15:43:59 / Laufzeit in Sekunden: 853
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 80.8 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 8095 Datensätze (Training=6476, Validation=1619)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.6, BitFail-Limit=0.25
Aktivierungen: Hidden=GAUSSIAN_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20
Modellalter: 48 h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 560 (max. 15000)
Training MSE: 0.002994
Validation MSE: 0.004155
Validation MSE Average: 0.006353
Validation MSE Standard Deviation: 0.000276
Validation Bit_Fail: 2
Model Bias: -134 Wh
Model Slope: 1.0
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 381.76 Wh
MedAE: 309.07 Wh
RMSE: 432.36 Wh
RMSE relative: 20 %
RMSE Rating: good
MAPE: 19.75 %
MdAPE: 14.74 %
R²: 0.67

=== Rauschen ===

Rauschen Bewertung: low
Empfehlung für Bit_Fail: 0.28 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: 2.01
Drift RMSE ratio: 3.15
Drift Slope: 0.385
Drift Bias: 600.37
Drift Bewertung: mild
Slope recalibrated: -
Bias recalibrated: -
letzte Rekalibrierung: -


Code Auswählen Erweitern

2026.03.19 17:00:17 1: Forecast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_Forecast
2026.03.19 17:00:18 1: Forecast DEBUG> DRIFT [con]: Flag=mild | Block=0 | SlopeLive=0.371 | DriftSlope=0.383 | BiasLive=469.47 | DriftBias=603.31 | RMSErelLive=63.3 | RMSErelRatio=3.16 | BiasVarNorm=0.24 |DriftScore=1.97 | Zone3Hours=1 | Hist=[mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild]
2026.03.19 17:00:18 1: Forecast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_Forecast

Screenshot -> aktuelles Bild von =>> ConForecast (rot) und realerVerbrauch (gelb)

[DS_Starter]

Ab 24h ist das freigeschaltet.
Aber du hast ja:

Code Auswählen Erweitern

Hist=[mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild,mild]

Nur wenn hinreichend oft moderate oder severe auftritt wird rekalibriert.

[tomcat.x]

Gestern tagsüber war der Balken aber teilweise unter 10 Wh. Das dürften die Stunden gewesen sein, als die Batterie ins Spiel kam. Ich werde das mal heute beobachten

Das war heute wieder so. Ich habe das auch mal längere Zeit beobachtet. Die Balken für consumption scheinen nichts mit den Werten im Reading Current_Consumption zu tun zu haben. Zumindest zeitweise nicht, nachts und früh morgens passt das. In einer Stunde habe ich einen Balken mit 130 Wh, bei einem Grundbedarf von über 150 Wh und zusätzlich hatte ich Rechner, Monitor an und die Waschmaschine laufen. Und Current_Consumption war immer auf ein paar hundert W. Auch an den anderen Current-Readings kann ich auch nichts auffälliges feststellen, das scheint alles zu passen.

[300P]

Nur wenn hinreichend oft moderate oder severe auftritt wird rekalibriert.

Na denn warte ich weiter wenn soweit alles einigermaßen paßt.

[DS_Starter]

@Parallix,

was evtl. ein Weg sein könnte, wäre die Verwendung eines Percentils (z.B. 99.5 % oder 99.9 %). Das wäre eine Maßnahme die z.B.einmal im Monat als Nachtverarbeitung laufen könnte und würde außergewöhnlich starke Ausreißer elimenieren können. Jeden Tag wäre kontraproduktiv weil nicht erkannt würde ob es ein einmaliger Ausreißer ist oder dieser Wert sich zukünftig wiederholt.

[DS_Starter]

Die Balken für consumption scheinen nichts mit den Werten im Reading Current_Consumption zu tun zu haben

Stimmt, haben sie nicht. Current_Consumption ist der aktuelle Verbrauch (W/kW). consumption ist der Verbrauch der entsprechenden Stunde (Wh/kWh).