76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

Mein Hauptproblem bzgl. PV-optimierter Steuerung liegt in der Übergangszeit bzw. an eher warmen oder sonnig-kalten Tagen, weil dann die nötige Laufzeit deutlich kleiner als die Anzahl der möglichen Sonnenstunden ist oder der Start schon vor 09:00 erfolgen sollte.
Derzeit schaltet sich die Wärmepumpe  mittels Tagprogramm wie gesagt um ca. 09:00 ein an eher warmen Tagen nach 2-3 h schon wieder aus. Wenn es bis Mittag nebelig ist, wäre es besser erst später einzuschalten.
Umgekehrt wäre es an sehr kurzen Tagen mit nötiger Laufzeit > der Sonnenstunden sinnvoll, schon vor 08:45 einzuschalten, um einen etwaigen Überschuss davor "auch noch mitzunehmen". (Ich habe keine Batterie.)

So, da die letzten Wochen ausreichend Datenmaterial für sehr kalte Temperaturen geliefert haben, hab' ich nun eine "Laufzeit-Vorhersage" erstellt.
Nun wollte ich das nach SolarForecast füttern und hab' mit Freude festgestellt, dass man die "mintime" bereits aus einem Reading eines anderen Geräts auslesen kann.

Allerdings habe ich dann weitergelesen und festgestellt, dass (wohl seit der KI-Verbrauchsprognose) "Heatpump" nur noch" noSchedule" erlaubt ist. 


Wie ist der weitere Plan?
Wird SolarForecast künftig die Laufzeit selbst vorhersagen und dann den optimalen Zeitpunkt auch einplanen können? (Wenn ich 5h Laufzeit vorhersage (oder künftig die KI mit höherer Trefferrate als oben...), möchte ich, dass SF diese 5h in ein "optimales Fenster" legt...)

Und da kommt gleich das nächste Problem:
Soweit ich weiß priorisiert SF die Geräte anhand ihrer Consumer-Nummern? D.h. ich müsste dann wohl die Wärmepumpe als "Consumer01" definieren. Beim damaligen Anlegen der Consumer habe ich darauf keine Rücksicht genommen. Kann ich die Nummern irgendwie "tauschen" ohne die Lernwerte zu verlieren?

[TheTrumpeter]

Mit der neuen Version werden (bei mir) die Umlaute in den Tooltips zu den Wettersymbolen nicht mehr korrekt angezeigt.

Bei mir unverändert richtig, z.B. "bewölkt" oder "Höhe" wird genau so angegeben.

[Parallix]

Mit der neuen Version werden (bei mir) die Umlaute in den Tooltips zu den Wettersymbolen nicht mehr korrekt angezeigt.

Bei mir unverändert richtig, z.B. "bewölkt" oder "Höhe" wird genau so angegeben.

Habe einen Nachtrag meinen Beitrag von soeben angeführt, denn es sind nur einige Umlaute. Die Worte "Höhe" und "bewölkt" sind auch bei mir richtig. Das Symbol, das um 8:09 MEZ bei mir noch da war und dessen Tooltip falsch geschrieben war, ist jetzt leider weg. 

[300P]

weitergelesen und festgestellt, dass (wohl seit der KI-Verbrauchsprognose) "Heatpump" nur noch" noSchedule" erlaubt ist.

A:
Wenn du AI:FANN für die Wärmepumpe nutzen willst, wird mit diesem speziellen Typ "Wärmepumpe" innerhalb des NN der Verbrauch "ermittelt".
Der wird speziell dazu gebraucht um anzuzeigen das hier die Daten der Wärmepumpe als Quelle für das NN genutzt werden sollen.

B:
Wenn du die Legagy nutzt und bzw. oder die Wärmepumpe doch selber steuern möchtest .... aktuell dann (derzeitig) einfach nicht den speziellen Typ "Wärmepumpe" nutzen.


Oder habe ich dich falsch verstanden und du nutzt aktuell NN.

damit

[TheTrumpeter]

Oder habe ich dich falsch verstanden und du nutzt aktuell NN.

Genau, nutze das NN...

[DS_Starter]

Moin zusammen,

Was mir aufgefallen ist: In der Nacht gibt es keine (langen) Lernzyklen mehr, es wird zwar was getan/gestartet, aber das ist umgehend wieder aus:
Code Auswählen
2026.01.26 02:15:02 1: mySolarForecast DEBUG> AI Raw delete data equal or less than index >2021012700<
2026.01.26 02:15:02 1: mySolarForecast DEBUG> AI AddInstance & Training BlockingCall PID "5091" with Timeout 7200 s started
2026.01.26 02:15:04 1: mySolarForecast DEBUG> AI Instance add - Tree: 1 -> 6511 entities added for training (set verbose 4 for output more detail)
2026.01.26 02:15:04 1: mySolarForecast DEBUG> AI Instance add - Tree: 2 -> 6511 entities added for training (set verbose 4 for output more detail)
2026.01.26 02:15:05 1: mySolarForecast DEBUG> AI Instance add - Tree: 3 -> 6511 entities added for training (set verbose 4 for output more detail)
...

Das ist die KI Unterstützung der PV Prognose (AI::DecisionTree) und hat mit AI::FANN der Verbrauchsprognose nichts zu tun.
Für mehr Info -> set verbose 4 for output more detail

Seit dem letzten Update (das mit den fhemweb-Fehlermeldungen, bzw. die Korrektur danach) ist meine Verbrauchsprognose deutlich schlechter geworden.

Lass das Training mit unveränderten Parametern einfach nochmal laufen. Es waren Anwesenheitserkennung, Temoeratursensorik und Kalenderauswertungen dazugekommen.
Ich kann nicht sagen mit welchem Stand dein letztes Training war.

Mit der neuen Version werden (bei mir) die Umlaute in den Tooltips zu den Wettersymbolen nicht mehr korrekt angezeigt.

Bei mir alles iO. An diesen Dingen hat sich auch nichts geändert.
Möglicherweise eine Wettersymbolik, die bisher nicht verwendet wurde (weil nicht eingetreten).
Vielleicht hilft die pvHistory weiter. Die fragliche Stunde mal aufrufen und "weatherid" rausholen. Dann bekommen wir evtl. raus welches Symbol angezeigt war.

weitergelesen und festgestellt, dass (wohl seit der KI-Verbrauchsprognose) "Heatpump" nur noch" noSchedule" erlaubt ist.

Nicht "nur noch" sondern "nur" weil es "heatpump" bisher nicht gab und mit der FANN Prognose eingebaut wurde und zwar sofort mit "noSchedule".
Ich gehe aktuell davon aus, dass eine Wärmepumpe nicht durch FHEM/SF aktiv gesteuert wird.
Sollte jedoch die Intension bestehen - was ich mangels eigener Erfahrung nicht ausschließen möchte, obwohl ich es vermutlich nicht tun würde - kann ich "noSchedule"
perspektivisch auch gern wegnehmen.
Allerdings gebe ich zu bedenken, dass eine WP doch ganz anders geplant werden muß als ein normaler Verbraucher den wir im SF Kontext nach PV Optimierungsgesichtspunkten
nutzen. Eine Wp jedoch soll vor allem die geforderte Temp bereitstellen. Wenn sie dann noch PV nutzt ist das sicherlich erstrebenswert, aber wenn nicht dann ist es eben so.

Wie ist der weitere Plan?
Wird SolarForecast künftig die Laufzeit selbst vorhersagen und dann den optimalen Zeitpunkt auch einplanen können?

Wie oben geschrieben war eine aktive Planung/Steuerung der WP durch SF nicht im Plan weil sie sich eben nicht nach PV optimieren lässt.
Der aktuelle use Case bezieht sich darauf den Energieverbrauch inkl. des WP-Anteils möglichst gut zu prognostizieren.

Soweit ich weiß priorisiert SF die Geräte anhand ihrer Consumer-Nummern? D.h. ich müsste dann wohl die Wärmepumpe als "Consumer01" definieren. Beim damaligen Anlegen der Consumer habe ich darauf keine Rücksicht genommen. Kann ich die Nummern irgendwie "tauschen" ohne die Lernwerte zu verlieren?

Das ist in der Tat ein Problem, aber nur sobald eine aktive Steuerung für die WP verwendet werden soll was ich aktuell mit einem (großen) Fragezeichen versehen würde.

[TheTrumpeter]

Lass das Training mit unveränderten Parametern einfach nochmal laufen. Es waren Anwesenheitserkennung, Temoeratursensorik und Kalenderauswertungen dazugekommen.
Ich kann nicht sagen mit welchem Stand dein letztes Training war.

Hab's grad gestartet... Kalender hatte ich noch nicht drin bzw. nutze ich dzt. nicht, der Rest war eigentlich unverändert.

Ich gehe aktuell davon aus, dass eine Wärmepumpe nicht durch FHEM/SF aktiv gesteuert wird.
Sollte jedoch die Intension bestehen - was ich mangels eigener Erfahrung nicht ausschließen möchte, obwohl ich es vermutlich nicht tun würde - kann ich "noSchedule"
perspektivisch auch gern wegnehmen.
Allerdings gebe ich zu bedenken, dass eine WP doch ganz anders geplant werden muß als ein normaler Verbraucher den wir im SF Kontext nach PV Optimierungsgesichtspunkten
nutzen. Eine Wp jedoch soll vor allem die geforderte Temp bereitstellen. Wenn sie dann noch PV nutzt ist das sicherlich erstrebenswert, aber wenn nicht dann ist es eben so.

Allgemein gesprochen gebe ich Dir Recht.
ABER: Ich habe ein sehr gut isoliertes Haus (8,5 kWh/m2a) mit einer (zu) starken Wärmepumpe und beobachte bzw. optimiere die Wärmepumpensteuerung schon seit einigen Jahren auf möglichst wenig Zyklen ohne signifikanten Komfortverlust (Temperaturschwankungen). Nach der PV-Installation habe ich das dann auf die Spitze getrieben und den Wärmeeintrag tagsüber angehoben, um ohne weiteren Heizungseinsatz nachts durchzukommen.
Das läuft bisher wie gesagt über Tag/Nachtprogramm, was aber die PV-Ausbeute nicht optimal nutzen kann wie letztes Jahr schon beschrieben.

Mit meiner "Laufzeitprognose" könnte ich das Einschalten an SF übergeben, indem ich diese Zeit als "mintime" übergebe. SF würde dann gemäß der Planung auf Tagbetrieb umschalten, das Zurücksetzen auf Nachtbetrieb passiert dann außerhalb von SF nach Ende des Heizzyklus.

Wie oben geschrieben war eine aktive Planung/Steuerung der WP durch SF nicht im Plan weil sie sich eben nicht nach PV optimieren lässt.

Wie gesagt, allgemein richtig; für Häuser mit sehr geringem Wärmeenergiebedarf & tendenziell überdimensionierter Wärmepumpe allerdings schon möglich.

[klaus.schauer]

weitergelesen und festgestellt, dass (wohl seit der KI-Verbrauchsprognose) "Heatpump" nur noch" noSchedule" erlaubt ist.

Nicht "nur noch" sondern "nur" weil es "heatpump" bisher nicht gab und mit der FANN Prognose eingebaut wurde und zwar sofort mit "noSchedule".
Ich gehe aktuell davon aus, dass eine Wärmepumpe nicht durch FHEM/SF aktiv gesteuert wird.
Sollte jedoch die Intension bestehen - was ich mangels eigener Erfahrung nicht ausschließen möchte, obwohl ich es vermutlich nicht tun würde - kann ich "noSchedule"
perspektivisch auch gern wegnehmen.
Allerdings gebe ich zu bedenken, dass eine WP doch ganz anders geplant werden muß als ein normaler Verbraucher den wir im SF Kontext nach PV Optimierungsgesichtspunkten
nutzen. Eine Wp jedoch soll vor allem die geforderte Temp bereitstellen. Wenn sie dann noch PV nutzt ist das sicherlich erstrebenswert, aber wenn nicht dann ist es eben so.

Wie ist der weitere Plan?
Wird SolarForecast künftig die Laufzeit selbst vorhersagen und dann den optimalen Zeitpunkt auch einplanen können?

Wie oben geschrieben war eine aktive Planung/Steuerung der WP durch SF nicht im Plan weil sie sich eben nicht nach PV optimieren lässt.
Der aktuelle use Case bezieht sich darauf den Energieverbrauch inkl. des WP-Anteils möglichst gut zu prognostizieren.

Bei Wärmepumpen gibt es neben dem bedarfsgesteuerten Betrieb noch die Option Pufferspeicher gezielt aufzuheizen oder eben andere Effekte wie die Engergiespeicherfähigkeit des Gebäudes auszunutzen. Dafür benötigt man Steuersignale, die überschüssige PV-Energie oder Niedrigtarifzeiten signaliseren. In https://forum.fhem.de/index.php?topic=137058.msg1353068#msg1353068 habe ich grob dargestellt, wie SolarForecast dies sowohl bei festen als auch bei variablen Energiekosten unterstützen könnte.

[DS_Starter]

Dafür benötigt man Steuersignale, die überschüssige PV-Energie oder Niedrigtarifzeiten signaliseren. In https://forum.fhem.de/index.php?topic=137058.msg1353068#msg1353068 habe ich grob dargestellt, wie SolarForecast dies sowohl bei festen als auch bei variablen Energiekosten unterstützen könnte.

Was Steuersignale usw. angeht stimme ich dem voll zu.

Die aktuell aufgeworfene Frage betrifft die direkte Steuerbarkeit, d.h. aktive Einplanung der WP als Consumer. Die implementierte Steuerungslogik für
alle Verbraucher ist an die Auswertung des PV Überschusses gekoppelt bzw. stützt sich darauf.
Diese Logik wäre für WP nur bedingt brauchbar, mal abgesehen von dem von TheTrumpeter beschriebenen Sachverhalt.

Unter der Vorraussetzung, dass die Planung der WP wie bei TheTrumpeter nur auf dem PV-Überschuß basiert, wäre eine solche Einplanung durch SF durchaus möglich
denke ich. Allerdings befürchte ich, dass User dann auf die Idee kommen, SF könnte eine WP komplett optimiert steuern, was sicherlich nicht der Fall ist.

Die konkrete Frage für mich lautet also ob ich dem Consumer "heatpump" die Möglichkeit einräumen sollte automatisch durch SF geplant werden zu können.
TheTrumpeter wird diese Frage sicherlich mit "Ja" beantworten.

[300P]

Wenn man die WP nach eigenen besonderen Regeln aktiv ON/OFF (und auch nur das sollte in / durch maximal SF dabei geschehen) steuern will, so ist dies nichts anderes als wenn man einen E-Heater oder eine Klimaanlage zusätzlich nach eigenen besonderen Regeln aktiv ON/OFF ansteuern will, das macht SF intern auch nicht mit besonderen Verbrauchern.

Dazu sollte im Normalfall weiterhin ein passender "schaltbare normaler" Consumertyp genutzt werden.

Code Auswählen Erweitern

dryer              90 Minten
dishwasher        180 Minuten
washingmachine    120 Minuten
heater            240 Minuten
charger           120 Minuten
other              60 Minuten
heatpump          Sonderfall
                  KI-Prognose (ab V2.0.0) beachten
(siehe auch Wiki heatpump)

Mit einem reinen ON/OFF ist doch auch in der Vergangheit mit diversen Abhängigkeiten (evtl. erweitert und abhängig durch eigenen Code) alles ermöglicht worden.

Das NN geht n.m.M so oder so davon aus, das eine WP (temperaturgeführt - daher auch die Angabe comforttemp=20) mit diesem extra geschaffenem Typ "heatpump" verbrauchsmäßig gesondert betrachtet und so in die Consumer "heatpump" geschaffenen NN-Verbrauchsberechnung in einem speziellen Versiontyp eingehen soll. Nicht mehr und nicht weniger !
Wenn diese Betrachtung dann mit eigenen sporadischen besonderen ON/OFF Schaltungen "über den Haufen geworden werden sollte" - dann ist die NN Berechnung nicht wärmepumpentypisch sondern eher wie eine sprunghafte Ladung eines EV anzusehen.
Das war von Heiko ja für später so oder so als evtl. zukünftige weitere Möglichkeit innerhalb von NN evtl. ja noch angedacht.

[TheTrumpeter]

Unter der Vorraussetzung, dass die Planung der WP wie bei TheTrumpeter nur auf dem PV-Überschuß basiert, wäre eine solche Einplanung durch SF durchaus möglich
denke ich. Allerdings befürchte ich, dass User dann auf die Idee kommen, SF könnte eine WP komplett optimiert steuern, was sicherlich nicht der Fall ist.

Da gebe ich Dir Recht. SF soll einfach das "optimale Fenster" für die vorgegebene Laufzeit ermitteln, d.h. an der Stelle würde ich dafür plädieren die "noSchedule"-Einschränkung zu entfernen.
Theoretisch wäre es sogar denkbar eine WP "unterbrechbar" zu machen, was ich persönlich aus Lebensdauergründen aber nicht tun würde/werde.

TheTrumpeter wird diese Frage sicherlich mit "Ja" beantworten.

Volltreffer 


Ein Problem würd' sich mit der von mir angedachten Logik aber noch ergeben:
SF würde die Betriebsart der WP ändern/vorgeben. Je nach Außentemperatur kann es dann aber noch einige Zeit dauern bis die Wärmepumpe tatsächlich anläuft. (Mein Gerät ermittelt periodisch durch kurzes Einschalten der Umwälzpumpe die Heizkreis-Temperatur, um daraus einen Soll-Ist-Abgleich zu machen. Die Häufigkeit dieser "Schnüffelzyklen" lässt sich natürlich parametrieren, kostet aber unnötig Energie.)

Wenn ich es richtig weiß, versucht SF ja mit dem "On"-Befehl den Verbraucher einzuschalten und prüft dann (nach einer sehr kurzen Wartezeit) anhand des "swstate", ob das Einschalten geklappt hat. Ich könnte den "swstate" nun einfach auf die Betriebsart umstellen, aber dann stimmen die Verbrauchswerte und Laufzeiten für die Verbrauchsprognose nicht mehr.
Wie könnte das abgebildet werden?

Dazu sollte im Normalfall weiterhin ein passender "schaltbare normaler" Consumertyp genutzt werden.

Wie würdest Du dann die Prognose und die Verbrauchsplanung "zusammenführen" wollen?
Ich kann natürlich ein zusätzliches Gerät für's Umschalten des WP-Betriebsmodus definieren, das ist kein Problem. Die Verbrauchsprognose vom "heatpump"-Gerät kommt dann aber durcheinander, weil die Einschaltzeiten "willkürlich" variieren. (Die Korrelation zu Laufzeit & Außentemperatur wäre weiterhin gegeben, aber warum das Einschalten heute wg. sonnigem Vormittag um 09:00 passiert und gestern am Nebeltag trotz gleicher Außentemperatur erst um 11:00 war, kann das NN wohl nicht ermitteln.)

dann ist die NN Berechnung nicht wärmepumpentypisch sondern eher wie eine sprunghafte Ladung eines EV anzusehen.

Das kann man meiner Meinung nach nicht vergleichen. Beim EV sind ja noch weitere Einflussfaktoren vorhanden, die aus NN-Sicht "zufällig" sein können. Die Wärmepumpe reduziert sich in erster Näherung immer auf die außentemperaturabhängige nötigen Tages-Laufzeit.
Ob man die Einplanung dieser voraussichtlich nötigen Tages-Laufzeit der Wärmepumpensteuerung, die typischerweise nix von der PV-Anlage - geschweige denn der erwarteten solaren Erträge - weiß, überlässt oder das Zeitfenster möglichst geschickt wählt, muss dann jeder selbst entscheiden.

[300P]

Wie würdest Du dann die Prognose und die Verbrauchsplanung "zusammenführen" wollen?

Ich würde so ähnlich vorgehen wie es bei der Wärmepumpe für den Pool im WIKI als Beispiel existiert.
Poolsteuerungsbeispiel ->>>> Heatpump: (consumer05)

Code Auswählen Erweitern

Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800
asynchron=0
icon=sani_heating_heatpump
auto=heatpump_auto
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
etotal=Pool_Pin32_monotonic_count_EnergyMeter:kWh
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=1
swoffcond=dum_valve:sf_true:{main::CheckWPOff}


Erläuterungen:
Der Verbrauch ist hier wieder etwas zu hoch angegeben (1800W statt realen 1500W), um eine Hysterese zu erreichen.
Da es sich hier um eine Wärmepumpe handelt, die nicht getaktet werden sollte, ist die locktime in beide Schaltrichtungen mit 10 Minuten relativ hoch.
Die Ermittlung des Medians ist mit 13 Minuten recht lang, um den Überschuss über lange Zeit zu glätten, damit möglichst selten geschaltet wird. Diese 13 Minuten in Kombination mit der Locktime und der Hysterese führten bei dieser Anlage bisher dazu, dass höchstens 5 Zyklen am Tag geschaltet wurden. -> Hier kann das individuelle Schaltverhalten optimiert werden. Besseres Verfolgen des Überschusses vs. weniger Taktungen der Wärmepumpe.
swoncond und swoffcond -> siehe 99_mySolarForecastUtils.pm

Als Grundlage würde ich es (natürlich angepasst auf meine <Device>:<Reading>) nehmen, die zusätzlichen Regulierung / Berechnung / Abhängigkeiten aber dann innerhalb einer speziell auf diesen Sonderfall "WP-ON/OFF" 99_myUtilsSF-Code-Routine unterbringen.
Zusätzlich - ich meine es gibt diese Option irgendwo bei den normalen Consumer - aber die Verbräuche HIER aus dem Hausverbrauch rauslassen und sie nur in bzw. mit dem dem speziellen "heatpump"-Consumer mit in die NN-Berechnung eingehen lassen.
 
Da wären mir dann theoretisch eigentlich keine Grenzen für die Regulierungen dieses gewünschtem besonderen  ON/OFF gesetzt....

[stefanru]

Hi,

kurze Frage bei mir kommt relativ oft diese Meldung im Log:
2026.01.26 20:37:36 1: Forecast - WARNING - FANN Model 'con' did not return a valid result. New training is required.
Ist das normal?
Meine Einstellung ist sehr simple gehalten:
aiControl aiConActivate=1 aiTrainStart=4

Gruß,
Stefan

[DS_Starter]

Hallo Stefan,

ja. Dein Modell ist noch mit einem "alten" Feature-Set trainiert.
Einfach "set ... aiDecTree runConTrain" ausführen (oder warten bis aiTrainStart greift).

Grüße,
Heiko

[stefanru]

Hmm,
ok ich dachte ich hatte "set ... aiDecTree runConTrain" nach dem letzten Update gemacht, Auch ist das sicher schon 2 - 3 Tage her.
Ich probiere es trotzdem nochmal, ich melde mich.

Danke,
Stefan