76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...
Für nach Deinem Urlaub habe ich einen Featurerequest:
Die Funktion get <Name> pVHistory exportToCsv finde ich sehr nützlich ...

Wäre es nicht einfacher, wenn Du eine eigene DB für solche Zwecke anlegst und die (gefilterten) Daten dann daraus ziehst?

[DS_Starter]

Hallo zusammen,

auch im Urlaub gibt es manchmal Regentage .... und nach einem Blick ins Forum habe ich ein bisschen was gemacht und die V 2.7.0 im contrib upgedated.

- @WDS, der Boot-Fehler sollte behoben sein

- @Peter, die Ausgaben bzw. Exporte der pvHistory können nun gefiltert werden wie im Anhang kurz dargestellt.
  Alles Weitere entnehmt bitte der Online-Hilfe die ich aktualisiert habe.

- Die Verbrauchsprognose FANN ist um weitere Features erweitert, die ich aber noch nicht produktiv gesetzt habe.
  Wer sie testen möchte, kann aiConProfile=v1_sandbox setzen und ausprobieren. Hierdurch wird ein
  erweitertes v1_common_active Profil aktiviert. Mit diesem Profil gelingt bei mir (bei Abwesenheit) eine
  Fehlerquote bei 1% mit sehr guten Slope, Bias und R2 Werten.


HINWEIS: Bei Einsatz der Version ist vermutlich ein Retraining nötig, was aber im Normalfall kein Thema ist.

Morgen geht hoffentlich bei Sonnenschein der Urlaub weiter. 

LG,
Heiko

[300P]

Na dann wünschen wir dir für die Resttage mal kein Regentage mehr, damit die Erholung 🏖�🤿🚤⛵️🌳😎👒 dabei nicht zu kurz kommt......

[grappa24]

Schönen Urlaub Heiko 

Ich bin jetzt auch extra mal 2 Wochen weg, damit das Haus mal in Ruhe trainieren kann 

[DS_Starter]

Viel Dank euch für die Wünsche und @grappa24 ebenso. 

[dieter114]

- @WDS, der Boot-Fehler sollte behoben sein

Ist behoben    Danke
und weiterhin einen schönen Urlaub.

[Gisbert]

Hallo 300P,
hallo Heiko (im Urlaub),

ich melde mich, weil meine Verbrauchsvorhersage aus dem Ruder läuft.

Code Auswählen Erweitern

aiControl
aiConActivate=1
aiConProfile=v1_heatpump
aiConHiddenLayers=64-32
aiConLearnRate=0.002
aiConMomentum=0.9
aiConBitFailLimit=0.34
aiConShuffleMode=1

Code Auswählen Erweitern

letztes KI-Training: 10.06.2026 08:18:45 / Laufzeit in Sekunden: 431
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 41.14 ms
Alpha: 1
Verbrauchernummer Wärmepumpe: 01

Trainingsbewertung: ok (ok)
Lernverhalten: ok gesundes Lernverhalten (19.7 % Epochenausnutzung)
Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
Drift Bewertung: fresh_model
Empfehlung für Retrain: keine
Der tägliche Verbrauch liegt derzeit stabil bei 10-13 kWh. Die Vorhersage für den nächsten Tag liegt tagsüber bei 20-24 kWh und aktuell bei 36 kWh.

Ich bin ohne Unterstützung nicht in der Lage, etwas Brauchbares aus der Verbrauchsvorhersage zu machen.

Viele Grüße Gisbert

[DS_Starter]

Hallo Gisbert,

ich nutze mal wieder eine kurze Regenphase ... 

Du hast eine Wärmepumpe und ich vermute die hohen Verbrauchserwartungen kommen daher. Das sind nur Annahmen, denn ich kenne deinen Haushalt nicht. Ich würde dir raten einzustellen:

aiConTrainLimit=5000 (bzw. testen mit 4000 ... 5000)

Dadurch schneiden wir ein Stück der saisonalen Einflüsse des Winters im Training weg.

Weiterhin erscheint mir das Momentum zu hoch. Ich es reduzieren auf:

aiConMomentum=0.5  (so zwischen 0.4 ... 0.7)

Dann gibt es den Hinweis "Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)".
Das bedeutet, das neuronale Netz kann einen beträchtlichen Teil des Verbrauches nicht anhand von Abhängigkeiten einorden. Das reguliere ich durch Features soweit ich es kann. Diese Features werden durch die Profile zu- oder abgeschaltet. Dir würde ich deswegen raten noch zu setzen:

aiConProfile=v1_heatpump_active_pv

Das passt nicht wirklich wegen dem Zusatz "_pv". Ich bemerke gerade, dass ein Profil v1_heatpump_active fehlt, was für dich und andere WP-User treffender wäre. Das bessere ich nach.

Dann trainiere damit und schau dir die Ergebnisse an.

Weiterhin kann es hilfreich sein, die Contrib Version 2.7.0 zu laden und dort einzustellen:

aiConProfile=v1_sandbox

Das aktiviert Features die ich demnächst produktiv einführen werde. Vllt. führt das bei dir bereits etwas näher zum Ziel.

EDIT: Hilfreich wäre auch uns kurz deinen Haushalt hinsichlich der maßgeblichen Verbrauchstreiber zu beschreiben. Vllt. gibt es Warmwasser Heizpatronen oder etwas ähnliches. Daraus kann ich evtl. noch fehlende Environment Bestanteile oder Features ableiten.

LG,
Heiko

[300P]

aiConProfile=v1_heatpump_active_pv

Das passt nicht wirklich wegen dem Zusatz "_pv". Ich bemerke gerade, dass ein Profil v1_heatpump_active fehlt, was für dich und andere WP-User treffender wäre. Das bessere ich nach.

Wenn du schon da nach dem Urlaub dann dort "anfasst".....hier der Wunschtraum des WP-Besitzers:

Die Abhängigkeiten für die 6 verschiedenen Betriebsmodi einer WP per Device-Reading optional (als höhenwertig) mitgeben zu können, anstatt die programmtechnisch irgendwie einem Modus zuzuordnen (Höchste Modi-Minuten-Wert pro Stunde zählt ).
Dies wird mir bei jeder Analyse bei den verschiedenen "KI-Freunden" im Netz immer wieder sehr stark zur Besserung der Werte nahegelegt...... 

Beispiel:
user_wpmodus {if(ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "heating") {return "heating"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "defrost") {return "defrost"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "hot water") {return "hotwater"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "off") {return "off"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "cooling") {return "cooling"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "pool") {return "pool"}
elsif (ReadingsVal("MQTT_EMSwp","boiler_data_hpactivity","") eq "pool heating") {return "poolheating"}
else {return 0}},

Ich meine die - die n.m.M. aktuell durch andere Parameter bei der WP die derzeitig im Code damit als bestimmter Betriebsmodi dann "zugeordnet" werden, können dann dem realen Status zugeordnet werden.

Zitat eines anderen KI-Freundes:

Code Auswählen Erweitern

17. Höchster Hebel bleibt daher wahrscheinlich
Zusätzliche Zustandsfeatures.
Insbesondere:
Feature erwarteter Nutzen
compressor active extrem hoch
minutes since ON extrem hoch
minutes since OFF extrem hoch
WW mode                 hoch
heating mode         hoch

Zitat eines anderen KI-Freundes

Code Auswählen Erweitern

12. Die eigentliche Ursache bleibt wahrscheinlich
Das Modell kennt den thermischen Zustand nicht explizit genug.
Das sehe ich inzwischen ziemlich klar.
Besonders fehlen vermutlich:
Feature Relevanz
compressor runtime extrem hoch
minutes_since_on extrem hoch
minutes_since_off extrem hoch
heating state         hoch
WW state         hoch

und:

Code Auswählen Erweitern

16. Höchster Hebel: explizite Zustandsfeatures
Du brauchst wahrscheinlich mindestens eines davon:
Feature Wirkung
WP compressor active sehr hoch
heating mode         hoch
WW mode                 hoch
runtime since start extrem hoch
runtime since stop extrem hoch
hysteresis state hoch

17. Besonders wirkungsvoll
Laufzeit seit Zustandswechsel
Beispiel:
minutes_since_on
minutes_since_off
Das wäre für thermische Systeme oft wertvoller als z.B. zusätzliche Wetterdaten.

oder hier

Code Auswählen Erweitern

12. Die wichtigste Erkenntnis bleibt aber
Selbst bessere Aktivierungen lösen das Kernproblem vermutlich nicht vollständig.
Denn:
Wärmepumpen sind zustandsgetriebene Systeme
kein glattes kontinuierliches Signal.


13. Höchster Hebel bleibt daher wahrscheinlich
Zusätzliche Zustandsfeatures.
Insbesondere:
Feature erwarteter Nutzen
compressor active extrem hoch
minutes since ON extrem hoch
minutes since OFF extrem hoch
WW mode                 hoch
heating mode         hoch


Edit/Zusatz:
Wenn der WP-Mode alles außer "Off" ist naturgemäß gegeben das der "compressor" immer an sein wird .
Man könnte noch die Modulationswerte oder die aktuelle Leistung auswerten (beides mir vorhanden) aber "compressor on" sollte reichen. 

[Shadow3561]

Moin, bei mir läuft seit dem letzte update nichts mehr wirklich rund.
Seit Tagen bekomme ich die Meldung

Code Auswählen Erweitern

The AI for forecasting con is not yet operational.
Cause: Training aborted: insufficient number of valid datasets (141 < 2000)Nun habe ich aus laute Verzweiflung ein "reset aiData" ausgeführt.
Hier mal mein aiControl

Code Auswählen Erweitern

aiConActivate=1 aiConProfile=v1_common_active_pv aiTrainStart=7 aiStorageDuration=3000 aiTreesPV=3 aiConHiddenLayers=50-25 aiConTrainStart=5:2 aiConLearnRate=0.005 aiConBitFailLimit=0.34
Was kann ich tun um wieder eine halbwegs aussagekräftige Vorhersage ui bekommen?
Gruss

[300P]

Nun Ja   

Code Auswählen Erweitern

The AI for forecasting con is not yet operational.
Cause: Training aborted: insufficient number of valid datasets (141 < 2000)
=

Code Auswählen Erweitern

Die KI für die Prognose ist noch nicht betriebsbereit.
Ursache: Training abgebrochen: unzureichende Anzahl gültiger Datensätze (141 < 2000)

Deine historischen Daten (CON) sind scheinbar irgendwie nicht mehr okay. Das sieht irgendwie nach einem Datenfehler / -problem in den SF-Datendateien aus.
Wenn du hast - Backup dieser Daten von vor dem Update noch einmal versuchen..... ob's klappt ?

Falls nicht - Daten sammeln - warten bis 2000 zusammen sind und solange Legacy nutzen....

[bismosa]

Moin!
Ich habe nach langer Zeit mal wieder mein System aktualisiert 
Ich bekomme seit dem Update minütlich folgende Log-Einträge:

Code Auswählen Erweitern

2026.06.13 15:32:13 3: SF - switching Consumer 'MQTT2_zigbee_plug_Klimaanlage' to 'on', command: "set MQTT2_zigbee_plug_Klimaanlage on" (Automatic = 1)
2026.06.13 15:32:13 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4796.
2026.06.13 15:32:13 1: stacktrace:
2026.06.13 15:32:13 1:    main::__ANON__                      called by fhem.pl (4796)
2026.06.13 15:32:13 1:    main::AttrVal                      called by ./FHEM/76_SolarForecast.pm (33849)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::getDebug      called by ./FHEM/76_SolarForecast.pm (35363)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::LRU_get        called by ./FHEM/76_SolarForecast.pm (32029)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::timestringsFromOffset called by ./FHEM/99_mySolarForecastUtils.pm (41)
2026.06.13 15:32:13 1:    main::pumpControl                  called by (eval 73860) (2)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::__ANON__      called by ./FHEM/76_SolarForecast.pm (34467)
2026.06.13 15:32:13 1:    (eval)                              called by ./FHEM/76_SolarForecast.pm (34467)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::userExit      called by ./FHEM/76_SolarForecast.pm (11178)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::centralTask    called by ./FHEM/76_SolarForecast.pm (10866)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::runTask        called by fhem.pl (4002)
2026.06.13 15:32:13 1:    main::CallFn                        called by fhem.pl (854)
2026.06.13 15:32:13 1: PERL WARNING: Use of uninitialized value $title in regexp compilation at ./FHEM/76_SolarForecast.pm line 35363.
2026.06.13 15:32:13 1: stacktrace:
2026.06.13 15:32:13 1:    main::__ANON__                      called by ./FHEM/76_SolarForecast.pm (35363)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::LRU_get        called by ./FHEM/76_SolarForecast.pm (32029)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::timestringsFromOffset called by ./FHEM/99_mySolarForecastUtils.pm (41)
2026.06.13 15:32:13 1:    main::pumpControl                  called by (eval 73860) (2)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::__ANON__      called by ./FHEM/76_SolarForecast.pm (34467)
2026.06.13 15:32:13 1:    (eval)                              called by ./FHEM/76_SolarForecast.pm (34467)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::userExit      called by ./FHEM/76_SolarForecast.pm (11178)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::centralTask    called by ./FHEM/76_SolarForecast.pm (10866)
2026.06.13 15:32:13 1:    FHEM::SolarForecast::runTask        called by fhem.pl (4002)
2026.06.13 15:32:13 1:    main::CallFn                        called by fhem.pl (854)
2026.06.13 15:32:13 1: SF - ERROR executing userExitFn: Can't use an undefined value as a SCALAR reference at ./FHEM/76_SolarForecast.pm line 35482.


Ich könnte mir vorstellen das es damit zusammenhängt, das die Steckdose derzeit nicht erreichbar ist. Das ist aber meisten so. Das läuft eigentlich nur ein paar Tage im Jahr.
state der Steckdose steht auf set_on.
Geändert habe ich sonst nichts. Vielleicht könnt ihr mir hier auf die Sprünge helfen?
Gruß
Bismosa

[300P]

Von welcher V auf welche V war das Update.
Es gab da was mit einem fehlendem "$name" in den userExitFN was vorher intern dort nicht sein musste (soweit ich mich erinnere......)


Ich meine z.B. dies hier:
ConsumerVal ('<Name>', '<Nr>', '<Key>', <default>

[bismosa]

Update. Fehler (endlich) gefunden.
Ich hatte nicht mitbekommen (ich lese auch nicht die ganze Zeit mit), das das Beispiel Pumpensteuerung am 22.04. angepasst wurde:
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung

hier musste ich $name hinzufügen

Code Auswählen Erweitern

my $dt    = FHEM::SolarForecast::timestringsFromOffset ($name, $startts, 0);
Damit läuft hier schon wieder alles. 
Gruß
Bismosa

@Autor 300P
Danke. Exakt. War gerade dabei die Antwort zu schreiben 

[DS_Starter]

Hallo zusammen,
Urlaub geht langsam zu Ende und ich bin auf der Rückfahrt.

@300P,
ja diese Statusinformationen sind sehr wertvoll für das NN. Vor einer Implementierung müssen noch ein paar Designfragen geklärt werden.
Die WP ist in SF als Consumer eingebaut und es wird ein oder mehrere neue Schlüssel dafür benötigt.

1. Variante mit nur einem Schlüssel (z.B. opmode):
Wenn es nur einen Schüssel gibt, muß das referenzierte Reading (oder ggf. Code) genau einen der möglichen Werte     
           
            heating, defrost, hotwater, cooling, pool, poolheating

zurückgeben. Intern werden daraus binäre Informationen abgeleitet die jeden Status eindeutig kennzeichnen. Außerdem muß der Status (0|1) als Momentaufnahme auf einen Stunde integriert werden. Alles in SF ist auf eine Stunde bezogen. Einfach nur den Wert zu lesen ist nicht sinnvoll, denn wenn heating am Anfang der Stunde 1 war und am Ende der Stunde 0, bleibt 0 als Wert im Speicher. Das darf natürlich nicht sein. Aber das ist Logikimplementierung die ich leisten muß.

Vorteil der Variante ist, dass ein Schlüssel ausreicht und die Übersicht gewahrt bleibt. Nachteil besteht darin, dass nur einer der Status aktiv sein kann und z.B. heating und hotwater nicht gleichzeitig ohne besonderes zusätzlichen Parsings.


2. Variante mit separaten Schlüssel für jeden Status:
Alles oben gesagte bleibt erhalten bis auf die Tatsache, dass die Übersichtlichkeit (stark) leidet wobei verschiedene Status gleichzeitig ohne besondere Logik parallel aktiv sein können.


Ich persönlich würde die Variante 1 bevorzugen, auch wenn es eventuelle Zusatzparsings nötig werden lässt.
Die Info "compressor active" kann bereits jetzt durch den Schlüssel swstate abgebildet werden. Die Hilfe dazu werde ich anpassen um den Bezug besser herzustellen.
Die Infos "minutes since ON" und "minutes since OFF" werden so nicht erfasst, aber im Stunderaster wird der Energieverbrauch der WP erfasst. Zusammen mit der Info des Working Mode ist eine wertvolle Kombination vorhanden welche Modus wieviel an Energie in der Stunde verbraucht hat.
Nicht ganz sauber ist es wenn mehrere Status parallel existieren. Dann kann die KI aber auf die bisher bereits implementierten synthetischen Features zurückgreifen die weiterhin im System verbleiben.

Bezüglich der Modulationswerte gilt der Hinweis zur Integration des gemesssenen Wertes auf eine Stunde als Durchschnittswert. Inwieweit es hilfreich ist kommt auf einen Versuch an. Aber wahrscheinlich ist es wichtiger die Kontextwerte wie Brauchwassertemperatur Soll/Ist (deltaT zur Aufheizung) in die Environments mit einzubauen. Für einen Pool gilt dies ebenfalls. Für die Raumtemperatur haben wir bereits das Soll drin und Außentemperatur Ist. Wenn die KI diese Werte UND dazu noch die Arbeitsmodi im Training hat, sollte es für die Inferenz ebenfalls gut klappen bzw. hilfreich sein.

Nun würde mich interessieren wie du/ihr die Variante 1 gegenüber Variante 2 einschätzt.

LG,
Heiko