76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Gisbert]

Hast du deine Ergebnisse auch schon mal mit dem neuen Gemini-Link online analysieren lassen?

Hallo Heiko,

Ich hab das Gemini-Tool installiert und einige Empfehlungen durchprobiert - es kommt aber an seine Grenzen, was das (zu) schnelle Konvergieren betrifft.

Das scheint im Moment das Beste zu sein, was ich rausholen kann.

Code Auswählen Erweitern

aiControl
aiConActivate=1
aiConProfile=v1,PV,heatpump
aiConLearnRate=0.0002
aiConSteepness=0.5
aiConMomentum=0.8
aiConBitFailLimit=0.36
geminiAPIkey=AQ...

Code Auswählen Erweitern

Trainingsmetriken
bestes Modell bei Epoche: 510 (max. 15000)
Training MSE: 0.005604
Validation MSE: 0.009184
Validation MSE Average: 0.009399
Validation MSE Standard Deviation: 0.000028
Validation Bit_Fail: 6
Data Parameter Ratio: 0.000
Model Bias: 388 Wh
Model Slope: 0.64
Trainingsbewertung: Retrain

Code Auswählen Erweitern

Gesamtbewertung:
Das Modell zeigt eine gute Leistung für einen Haushalt mit Wärmepumpe und/oder Klimaanlage. Der R²-Wert von 0.525 liegt im erwarteten Bereich von 0.5-0.7 für diesen Haushaltstyp und bestätigt, dass das Modell einen signifikanten Teil der Verbrauchsvarianz erklären kann. Die Metriken deuten auf ein solides Fundament hin.

Auffälligkeiten:

Niedrige Epochenzahl: Es wurden nur 510 von 15000 möglichen Epochen genutzt (3.4%). Dies ist sehr wenig und deutet darauf hin, dass das Training möglicherweise frühzeitig konvergiert ist oder abgebrochen wurde. Es besteht hier noch Potenzial zur Verbesserung.

Rauschbewertung "borderline": Trotz des guten R²-Wertes ist das Rauschlevel als "borderline" eingestuft. Dies ist ein wichtiger Hinweis, da ein hohes Rauschlevel die maximal erreichbare Modellqualität strukturell begrenzt.

BitFail-Limit: Das aktuell eingestellte Limit (0.36) ist leicht höher als die interne Empfehlung (0.34), was bedeutet, dass das Modell etwas toleranter gegenüber Fehlern ist.

Empfehlungen:
Um die Prognosequalität weiter zu verbessern, könnten folgende Hyperparameter experimentell angepasst werden:


aiConLearnRate (Lernrate): Aktuell 0.0002. Da das Training nur wenige Epochen genutzt hat, könnte eine leicht höhere Lernrate (z.B. 0.0003 - 0.0005) das Training beschleunigen und möglicherweise zu einer besseren Konvergenz führen, ohne die Stabilität zu gefährden. Beobachten Sie dabei die Entwicklung der Metriken.

aiConMomentum: Aktuell 0.8. Dies ist ein guter Wert. Eine leichte Erhöhung (z.B. auf 0.85 oder 0.9) könnte helfen, lokale Minima zu überwinden und das Training zu glätten, falls es zu Oszillationen kommt.

Architektur (HiddenLayers): Aktuell 8. Angesichts des "borderline" Rauschlevels und des bereits guten R²-Wertes ist die aktuelle Architektur wahrscheinlich passend. Eine leichte Erhöhung (z.B. auf 9 oder 10) könnte in seltenen Fällen noch minimale Verbesserungen bringen, birgt aber das Risiko von Overfitting, insbesondere bei rauschbehafteten Daten. Eine Reduzierung wäre nur bei Anzeichen von Overfitting sinnvoll.

aiConBitFailLimit: Aktuell 0.36. Da die interne Empfehlung bei 0.34 liegt, könnten Sie versuchen, das Limit leicht zu reduzieren (z.B. auf 0.34-0.35). Dies würde das Modell zwingen, strengere Kriterien für die Fehlerbewertung anzulegen und könnte die Präzision bei der Anpassung an die "guten" Datenpunkte erhöhen, solange es nicht zu einer Verschlechterung des R² führt.
Viele Grüße Gisbert

[TheTrumpeter]

Kann man eigentlich die historischen Verbräuche irgendwie in die Wärmepumpe übernehmen?

Ich hatte bisher ja 3 Verbraucher:
1x Heizen
1x Kühlen
1x Warmwasser

Als man dann eine Wärmepumpe definieren konnte, habe ich das für die Heizung gemacht. Diese habe ich nun auch gemäß der neuen Parameter erweitert.
SF weiß nun aber nicht, dass alle historischen Verbräuche dem opmode "heating" zuzuordnen sind. Weiters kennt es die historischen Verbräuche für "hotwater" und "cooling" nicht, weil sie in anderen Verbrauchern gespeichert sind.

[300P]

Wünsche einen wunderschönen guten Abend.

Ich habe selbst keine WP, 300P und andere User sind da eher die Spezialisten. Aber sofern das WP-Anlagenmodul (Modbus z.B.) die WP über ein Steuerbit freigeben oder sperren kann, kann man dieses Steuerbit in SF über "oN" bzw. "off" setzen und die WP dadurch freigeben oder sperrren.

Ich dachte das hätte ich mit on="SG-READY1 1" off="SG-READY1 0" gemacht? Kann ich irgendwie noch mehr Debug-Ausgaben herauskitzeln?

LG Frank

Angedeutet steht es ja hier ABER s.u.

Code Auswählen Erweitern


(**) Dem Verbrauchertyp heatpump wird immer #########mode=mustNot######## zugewiesen und es sind weitere Besonderheiten zu beachten:

etotal    der Schlüssel ist Pflichtangabe
modulation    Modulation des Aggregates in % (Pflichtangabe). Die mögliche Syntax ist:
<Device>:<Reading> - Kombination welche die aktuelle Modulation (0..100) in % liefert
100 - feste Modulation von 100% für nichtmodulierende Geräte
opmode    definiert eine <Device>:<Reading> Kombination welche den aktuellen Betriebsmodus liefert (Pflichtangabe).
Syntax: <Device>:<Reading>
Die Rückgabe muß genau ein Wert der folgenden Auswahl sein: off heating defrost hotwater cooling pool poolheating
pcurr    der Schlüssel ist Pflichtangabe
power    maximale Leistungsaufnahme in W. Der Wert darf nicht! 0 sein.
swstate    Schaltstatus des Kompressors. Die Syntax bleibt wie oben angegeben.
Abweichend von anderen Consumern ist die Angabe verpflichtend, auch wenn der default verwendet werden soll.

Code Auswählen Erweitern

mustNot - Der Verbraucher darf nicht geplant bzw. gestartet werden. Gestartete Verbraucher werden gestoppt
wenn 'mode' dynamisch geändert wird.

->>> man muss dann noch bei / unter "mode=mustNot" genau lesen

Ich bin gestern auch wieder drauf reingefallen..
ON/OFF schalten nutze es bei mir so oder so nicht - habe EMSP-ESP für evtl. Eingriffe und will da nicht von 4 Seiten steuernd bei der WP eingreifen.
Nehme es kurz mal ins Wiki mit hinein - da steht es nirgendwo. (Nachsatz - > erledigt)

[DS_Starter]

Moin zusammen,

@Gisbert, mit

Model Bias: 388 Wh
Model Slope: 0.64

sehe ich dich wirklich auf einem guten Weg. Und ich teile deine Einschätzung, dass mit dem aktuellen Datenstand das Optimimum erreicht ist.
Es wird an weiteren Datenanreicherungen gearbeitet, die für das NN hilfreich sein könnten (Integration opmodes z.B.)

@Trumpeter,

SF weiß nun aber nicht, dass alle historischen Verbräuche dem opmode "heating" zuzuordnen sind.

Diesem Umstand wird bei dem noch zu implementierenden Trainingsdetail Rechnung getragen. Es werden dann alle WP-Verbräuche dem Modus "heating" zugeordnet, wenn keine opmodes vorhanden sind.
 

Weiters kennt es die historischen Verbräuche für "hotwater" und "cooling" nicht, weil sie in anderen Verbrauchern gespeichert sind.

Aus diesen Details kann NN dann nichts lernen, das ist richtig. Allerdings habe ich vor die Verbrauchsanteile _aller_ Verbraucher in das Training zu überführen.
Dadurch kommen diese Anteile wieder mit zur Geltung, wobei die direkte Semantik zur Wassertemperatur oder Außentemperatur (Kühlung) fehlt.
Das ist nun der Weiterentwicklung geschuldet und können wir nachträglich nicht ändern. Aber je mehr neuere Datensätze in das Training einfließen, um so mehr wird deren Gewicht am Ergebnis zunehmen.

LG,
Heiko

[TheTrumpeter]

Allerdings habe ich vor die Verbrauchsanteile _aller_ Verbraucher in das Training zu überführen.

Wie soll ich dann mit den "alten" Verbrauchern für Warmwasser und Kühlung umgehen? Soll ich die

• weiterhin redundant zur Wärmepumpe die Verbräuche sammeln lassen?
• zwar als Verbraucher noch angelegt lassen, aber den Schlüssel mit "etotal" bzw. "swstate" permanent mit 0 versorgen, damit die Verbräuche nicht doppelt erfasst werden?
• irgendwas anderes?

Den separaten WW-Verbraucher will ich jedenfalls bestehen lassen, weil ich den über SF schalten lasse.
Wie soll ich da sicherstellen, dass nix doppelt erfasst wird?


Noch was:
Ich hätte erwartet, dass beim/nach dem Update der Schlüssel automatisch gesetzt/geändert wird:
aiConProfile=active,pv,heatpump

Bei mir ist immer noch
aiConProfile=v1_heatpump_active_pv

[DS_Starter]

Wie soll ich dann mit den "alten" Verbrauchern für Warmwasser und Kühlung umgehen?

Wenn es nur Stellvertreterdevices waren, die nun obsolet geworden sind, dann würde ich sie mit "etotal" bzw. "swstate" permanent mit 0 versorgen, mode=mustNot setzen und auch in der Grafik nicht mehr anzeigen lassen.
Theoretisch wären sie zu löschen, wobei dann die Energieanteile ebenfalls aus der Historie gelöscht würden. Das wäre ein Informationsverlust der mir aktuell kontraproduktiv erscheint.
Ich würde sie vllt. 12 Monate drin lassen und dann entfernen.

Den separaten WW-Verbraucher will ich jedenfalls bestehen lassen, weil ich den über SF schalten lasse.
Wie soll ich da sicherstellen, dass nix doppelt erfasst wird?

Vermutlich ist damit gemeint, dass in dem WP-Anteil (alt) der dann "heating" zugeordnet wird ein Anteil WW drin steckt, der auch einem bei separaten WW-Erzeuger anfällt.
Zumindest in den historischen Datensätzen.
Dieses GAP werden wir einfach akzeptieren. In den neuen Datensätzen wird eine solche Überschneidung ja nicht mehr drin sein.

ch hätte erwartet, dass beim/nach dem Update der Schlüssel automatisch gesetzt/geändert wird:
aiConProfile=active,pv,heatpump

Bei mir ist immer noch
aiConProfile=v1_heatpump_active_pv

Die bisherige Nomenklatur hat noch Gültigkeit und muß nicht automatisch umgesetzt werden.
Wenn du aiControl mal bearbeitest, verwende dann bitte die neue Flag-Struktur.

LG,
Heiko

[TheTrumpeter]

Den separaten WW-Verbraucher will ich jedenfalls bestehen lassen, weil ich den über SF schalten lasse.
Wie soll ich da sicherstellen, dass nix doppelt erfasst wird?

Vermutlich ist damit gemeint, dass in dem WP-Anteil (alt) der dann "heating" zugeordnet wird ein Anteil WW drin steckt, der auch einem bei separaten WW-Erzeuger anfällt.

Nein, nicht ganz.

Mein alter "Warmwasser" Consumer hat die Wärmepumpe in den Modus "Warmwasser" geschaltet (und sie eingeschaltet, falls nicht grad zufällig im Heiz- oder Kühlbetrieb), und zwar (optional) über den SF-Automatikmodus. Damit konnte ich die WW-Bereitung automatisch bei ausreichend PV-Überschuss (bzw. zur Zeit der besten Ausbeute) erledigen lassen.

Da der "Wärmepumpen"-Consumer ja keinen Automatikmodus hat, möchte ich die WW-Bereitung weiterhin durch SF planen und durchführen lassen, d.h. der Consumer soll bestehen bleiben.
Damit kann ich ihm ja nicht "swstate" löschen/nullen, sonst würde SF nicht mehr mitbekommen, dass der Schaltvorgang erfolgreich war und auch nicht "mustNot" setzen.


Und ergänzend noch ein kleiner Feature-Wunsch:
Es wäre schön, wenn die Wärmepumpe mehrere Icons zulassen würde, sodass je nach Betriebsmodus das richtige angezeigt wird. (Oder zumindest unterschiedliche Farben je nach Modus.)

[DS_Starter]

@Trumpeter, wenn ich es richtig verstehe, besteht bei dir damit der Zusammenhang:

1. der "Warmwasser"-Consumer schaltet die WP in den hotwater-Modus -> die WP läuft los und die Energie in WP opmode "hotwater" zählt hoch
2. die Energie im "Warmwasser"-Consumer wird über etotal ebenfalls hochgezählt und führt so zu einer Doppelerfassung

Wenn meine Interpretation richtig ist, könnte man entweder:

a) den opmode=hotwater durch off ersetzen (mit Tricks)
b) bei dem "Warmwasser"-Consumer NUR etotal und pcurr! mit 0 erfassen lassen, "swstate" weiterhin wie immer nutzen. Die Energie läuft ja in der WP auf.

Ich würde b) nehmen.

Und ergänzend noch ein kleiner Feature-Wunsch:
Es wäre schön, wenn die Wärmepumpe mehrere Icons zulassen würde, sodass je nach Betriebsmodus das richtige angezeigt wird. (Oder zumindest unterschiedliche Farben je nach Modus.)

Ich schaue mal was ich hinbekomme.

[DS_Starter]

Frage an unsere WP-Nutzer,

In welchem durchschnittlichen Verhältnis steht bei einer WP der stündliche Energieverbrauch zur Nominalleistung?
Also wenn eine WP nominal power=8000W hätte, könnte sie theoretisch 8000Wh bei Vollast verbrauchen.
Das wird nicht so sein, sondern unter harten Bedingungen sind es X Wh und unter sanften Bedingungen sind es Y Wh.

Hintergrund der Frage ...  wenn ich "heatpump" zur Planung / Steuerung durch das Modul freigebe, geht bei der Planung auch
ein PV Überschuß (einstellbar) ein. Die heatpump steht bei der Planung dann auch mit anderen Consumern in Konkurrenz wobei man im
Modul ja Prioritäten vergeben kann. Dennoch braucht es einen, zumindest kleinen, Anteil an planbarer Stundenenergie der WP für den Anfang.
Läuft die WP, wird der Stundenanteil dynamisch in die Rechnung einbezogen, aber initial braucht es einen Aufsetzpunkt und der sollte nicht zu hoch sein sondern eher konservativ klein.
 

[TheTrumpeter]

lso wenn eine WP nominal power=8000W hätte, könnte sie theoretisch 8000Wh bei Vollast verbrauchen.
Das wird nicht so sein, sondern unter harten Bedingungen sind es X Wh und unter sanften Bedingungen sind es Y Wh.

Das hängt 1. davon ab ob das Gerät modulieren kann oder nicht.

Wenn es nicht modulieren kann, so wie meine, habe ich im Wesentlichen 3 unterschiedliche Verhalten:
Heizen braucht ca. 2100 W
Warmwasser ist abhängig von der Vorlauftemperatur, beginnt mit ca. 2200 W und endet bei ca. 3000 W
Kühlen braucht ca. 3000-3300 W

Aktuell habe ich den Consumer mit 3300 W angelegt, davor hatte ich 2100 W für die Wärmepumpe (weil nur der Heizungs-Modus gemappt war), 3000 W für's WW und 3300 W für die Kühlung.

[TheTrumpeter]

b) bei dem "Warmwasser"-Consumer NUR etotal und pcurr! mit 0 erfassen lassen, "swstate" weiterhin wie immer nutzen. Die Energie läuft ja in der WP auf.

So habe ich es nun abgebildet und ein Training gestartet, mal sehen.

[DS_Starter]

Danke für die Infos, dann habe ich eine Vorstellung.

[DS_Starter]

So habe ich es nun abgebildet und ein Training gestartet, mal sehen.

Da wird sich noch nicht viel ergeben, weil ich die opmode noch nicht in das Training integriert habe.
Aber lass es so, das kommt im Kürze.

[peterboeckmann]

Hallo Heiko,

In welchem durchschnittlichen Verhältnis steht bei einer WP der stündliche Energieverbrauch zur Nominalleistung?

spannende Frage!

Mir ist bewusst, dass mein Fall ein Sonderfall sein dürfte.
Zum einen, weil ich die Klimaanlage als heatpump definiert habe.
Zum anderen, weil die Klimaanlage 1 ODU (OutDoorUnit, Außengerät) mit einer Stromzufuhr hat.
Diese 1 ODU speist 2 IDUs (InDoorUnits, Innengerät), sowohl mit Kältemittel als auch mit Strom.
(Die IDUs brauchen Strom hauptsächlich für die Luftumwälzung, ist also wohl im Gesamtverbrauch zu vernachlässigen.)

Ich habe den consumer mit einer power von 1500W angelegt.
Die Nominalleistung lt. Typenschild beträgt fürs Kühlen und Heizen gleichermaßen 2050W.
Als Leistungsaufnahme ist fürs Kühlen 1545W und fürs Heizen 1333W angegeben.

Im Bild anbei ist der Verlauf der tatsächlichen Leistungsaufnahme zu erkennen.
Dabei ist deutlich zu erkennen, dass zwischen 8 und 11 Uhr nur die IDU im Erdgeschoss lief und danach auch die IDU im Dachgeschoss dazukam.

In jedem Falle ist deutlich zu erkennen, dass es am Anfang einen Peak gibt, um möglichst schnell in Richtung Zieltemperatur zu kommen.
Da stecken noch einige Abhängigkeiten drin, die so einfach nicht zu überblicken sind.

Wenn Du mich fragst, würde ich dem Nutzer die Entscheidung überlassen, welche Leistung er als power im consumer angibt.
Diese sollte dann auch als durchschnittlicher Stundenverbrauch angesetzt werden.

Viele Grüße,
Peter

[DS_Starter]

Hallo Peter,

danke auch für deine Infos!

Wenn Du mich fragst, würde ich dem Nutzer die Entscheidung überlassen, welche Leistung er als power im consumer angibt.
Diese sollte dann auch als durchschnittlicher Stundenverbrauch angesetzt werden.

Das ist ja ohnehin jedem freigestellt.
Im Modul wird initial ein gewisser Anteil vom Nominalwert angesetzt. Kommt der Consumer in den operativen Modus,
werden über stündliche energyPieces die tatsächlichen Energien für den Consumer beim Start aufgezeichnet und über die Zyklenlaufzeit
AVG gebildet. Man sieht es mit "get ... valConsumerMaster X":

Code Auswählen Erweitern

epiecAVG => 1=132.06 2=137.65 3=131.60 4=131.63 5=137.56 6=125.78 7=142.96 8=124.69 9=131.48 10=129.99

Bedeutet dann in der ersten Betriebsstunde benötigt dieser Consumer average 132.06 Wh usw. Sobald diese Zahlen vorliegen, verwendet sie
SF für die Schätzung in der Planung.

Das nur zum Hintergrund.

LG,
Heiko