76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Gisbert]

Beim SetupMeterDev waren gcon und gfeedin gleich definiert.
Das steht auch so falsch im WiKi (hat noch keiner bemerkt  )

Hallo WDS,

in der commandref (also den Erklärungen im Device) findet man diese Beschreibung - meinst du etwa das?

Code Auswählen Erweitern

Special cases: If the reading for gcon and gfeedin should be identical but signed, the keys gfeedin and gcon can be defined as follows:

    gfeedin=-gcon    (a negative value of gcon is used as gfeedin)
    gcon=-gfeedin    (a negative value of gfeedin is used as gcon)

Das sieht zwar etwas wild aus, aber wenn es richtig im Modul umgesetzt ist, dann ist es nachvollziehbar. Es wird nur Bezug auf ein Reading gemacht. Der positive Wert des Readings (als Beispiel) ist gcon (=Bezug) und der negative Wert des Readings wird als Einspeisung (gfeedin) in Form des Absolutwertes identifiziert. Das ganze geht dann auch, falls die Vorzeichen für Bezug und Einspeisung gegenüber dem Beispiel vertauscht sind. Es ist schon ein Gehirnverzwirner, aber nur ein kleiner .

[peterboeckmann]

Moin Heiko,

der Entladevorgang der Batterien sieht in v2.6.7 gut aus.

auch der Ladevorgang sieht in der v2.6.7 gut aus.
Screenshot anbei.

Viele Grüße,
Peter

[dieter114]

EDIT:
SF-Wiki ? - dann kann ich es korrigieren

Nö im WiKi Fronius Komplettbeispiel.
Das mache ich wenn alles endlich mal richtig läuft.

LG WDS

[DS_Starter]

Moin @all,

danke für die Rückmeldung Peter.
Da können wir nun einen Haken dran machen denke ich. Auch bei mir passt alles nach wie vor.

LG,
Heiko

[300P]

Gestern hab ich NN neu trainiert
Grund:
Mein WW-Programm in der WP läuft seit mehr als 1 Woche total anders um während der WW-Aufbereitung die WW-Arbeitszahl der WP höher zu bekommen....
- verschiedene Zeiten mit verschiedenen Temperaturen
- Legionellenprogramm aktiv mit 63 °C und 1x / Woche am SA um 14:00 Uhr
- wenig Komforverlust
Ergebnis ist im Schnitt ca. 2-2.7 kWh/Tag weniger Energieverbrauch bei der WW-Aufbereitung
(vorher 1 x täglich Mittagszeit auf 57 Grad und da war schon Potential (3 kWh/Tag) gegenüber vorher rausgekommen)


NN-Ergebnis leider grad erst angeschaut:
=>>> WOW - wenns wirklich stimmt und dauerhaft bleibt

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 09.05.2026 21:38:52 / Laufzeit in Sekunden: 5168
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 78.03 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6770 Wh
Trainingsdaten: 12069 Datensätze (Training=9655, Validation=2414)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.002, Momentum=0.8, BitFail-Limit=0.28
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Period=20
Modellalter: 11 h

=== Trainingsmetriken ===

bestes Modell bei Epoche: 5706 (max. 15000)
Training MSE: 0.000634
Validation MSE: 0.000073
Validation MSE Average: 0.000094
Validation MSE Standard Deviation: 0.000011
Validation Bit_Fail: 0
Model Bias: -7 Wh
Model Slope: 1.0
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 44.38 Wh
MedAE: 33.76 Wh
RMSE: 48.59 Wh
RMSE relative: 4 %
RMSE Rating: excellent
MAPE: 3.88 %
MdAPE: 2.41 %
R²: 1.00

=== Rauschen ===

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

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: 1
Drift Bias: 0
Drift Bias Live: -
Drift Index: -
Drift Bewertung: fresh_model
Slope recalibrated: 1.0
Bias recalibrated: -7
letzte Rekalibrierung: -




Meine neueste aktuelle Einstellung in attr aiControl:

Code Auswählen Erweitern

aiConAbsOversample=0.25
aiConActFunc=ELLIOT_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.28
aiConHiddenLayers=80-40
aiConLearnRate=0.002
aiConMomentum=0.8
aiConProfile=v1_heatpump_active_pv
aiConShuffleMode=2
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConTrainStart=7:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30


Mal sehen was nach 24 Stunden an Ergebnis kommt

[DS_Starter]

Wow, das wäre natürlich der Hit. So richtig glauben kann ich es noch nicht    ... aber lassen wir uns mal überraschen.
Wenn das Ergebnis sich bewahrheitet mußt du aber eine Runde ausgeben. 

[Mikel2906]

ch habe das Problem, dass die Variablen GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer zeigen. Ich lese die Daten direkt über Tasmota MQTT am Zähler ab. Meine Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht.

Ich habe meine Konfiguration angehängt. Ich benötige diesbezüglich Hilfe, ich bin mit meinem Latein am Ende.

Viele Grüße

[DS_Starter]

Hallo Mikel2906,

willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.

Zunächst sind die von dir beschriebenen Sachverhalte:

a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht

zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.

Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen

- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?

Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.

LG,
Heiko

[DS_Starter]

@all,
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.

Mit der V 2.6.6 bis 2.6.7 kommen folgende Fixes und Änderungen ins System.

Consumersteuerung:

- pro SF-Zyklus wird ein PV-Überschußbudget geführt, aus welchem sich die Verbraucher beim Einschaltvorgang bedienen.
  Ist er aufgebraucht, wird kein Verbraucher im laufenden Zyklus mehr eingeschaltet und wird erst im nächsten wieder geprüft.
  Das Verfahren verhindert "Toggling" von Verbrauchern weil im nächsten Zyklus PV-Überschuß überzogen wurde und Verbraucher
  deshalb wieder abgeschaltet werden
 
- neuer Schlüssel swprio zur Prioritätssteuerung von Consumern


Flußgrafik:

- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)


Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
 
 
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.

- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
  Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.

- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
  Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
  das nächste freie Fenster.

- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
  Niedriger priorisierte Consumer weichen automatisch aus.

- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.

Die V 2.6.8 habe ich ins contrib geladen.

LG,
Heiko

[Mikel2906]

Hallo Heiko,

danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.

Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar

Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.

Beispiele:

    Today_Hour02_GridConsumption: 17516200 Wh
    Today_Hour04_GridFeedIn: 11315700 Wh

Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.

Das Skript für die Ladesteuerung ist im Anhang.

Viele Grüße
Michael