76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

grappa24

Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

Hallo Klaus,

nein, einfach ist das Ganze mit Sicherheit nicht.

Deine Routinen könnten ein Baustein in der klassischen Prognose des Hausverbrauches sein. Denn das neuronale Netz betrachtet den den gesamten E-Verbauch des Haus in Abhängigkeit von verschiedenen Randbedingunge. Die WP ist nur ein Bestandteil davon. Deswegen nicht allzusehr nur auf WP fokussieren.

Die Variante mit einer ctrlUserExitFn ähnlichen Schnittstelle ist m.M. nach am ehesten sinnvoll, sonst müsste ich im WP Consumerstammsatz alle benötigten Parameter zwingend angeben lassen.
Dieser Userfunktion würde übergeben werden:

- Stunde / Timestamp für den der E-Bedarf der WP benötigt wird
- die Temp Prognose für diesen Timstamp
- die Windprognose für diesen Timestamp

Als Antwort würde erwartet:

- der Energiebedarf als Prognose für den Timestamp als Stundenwert, d.h. in Wh


Das Ganze natürlich optional, denn nicht jeder User wird in der Lage sein dies umzusetzen.

LG,
Heiko

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@grappa24,

:) ... EV Laden wird mit ziemlicher Sicherheit nocht nicht abgebildet werden können, dazu fehlen die Triger wie z.B. aktueller Ladungsgrad der EV-Batterie.

Aber es geht schrittweise weiter.
 
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

klaus.schauer

Zitat von: DS_Starter am 04 Januar 2026, 19:16:22Die Variante mit einer ctrlUserExitFn ähnlichen Schnittstelle ist m.M. nach am ehesten sinnvoll, sonst müsste ich im WP Consumerstammsatz alle benötigten Parameter zwingend angeben lassen.
Dieser Userfunktion würde übergeben werden:

- Stunde / Timestamp für den der E-Bedarf der WP benötigt wird
- die Temp Prognose für diesen Timstamp
- die Windprognose für diesen Timestamp

Als Antwort würde erwartet:

- der Energiebedarf als Prognose für den Timestamp als Stundenwert, d.h. in Wh
Zur berechneten Energie müsste m. E. auch die Sollinnentemperatur zurückgemeldet und im KI-Modell berücksichtigt werden. Der aktuelle Energiebedarf eines Hauses hängt nun mal sehr entscheidend von der Differenz zwischen der Innen- und Außentemperatur ab. Abweichungen des tatsächlichen Verbrauchs von der Prognose könnten durch die KI so verlässlicher anderen Einflussfaktoren zugeordnet werden.

Ich bin gespannt, wie es weitergeht. Sobald Du soweit bist und die Schnittstellendefinition feststeht, werde ich eine passende Routine bereitstellen.

DS_Starter

ZitatZur berechneten Energie müsste m. E. auch die Sollinnentemperatur zurückgemeldet und im KI-Modell berücksichtigt werden.
Prinzipiell richtig. Die Sollinnentemp - es kann nur ein Wert sein - wäre in dem Kontext die "Prognose" für die angefragte Stunde.
Dann müsste es im setupEnvironment auch eine Temp-Erfassung des Ist-Wertes für eine Datenaufzeichnung geben.
Zur Erinnerung, bei der KI müssen die Trainingsfeatures mit den Features in der Abfrage übereinstimmen, also Anzahl und deren Aussage.
Weiß nicht so recht wo man diesen Wert hernehmen könnte, da die Räume oft unterschiedlich beheizt werden. Vllt. einen Raum (Wohnzimmer), der als Referenz dienen  kann.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@all,
als Motivation und Ansporn anbei der Verlauf meiner Verbrauchsprognose der letzten Stunden komplett KI generiert.
Ich habe einen Standardhaushalt ohne WP und EV. Es sind bereits weitere Features integriert, aber noch nicht im contrib enthalten...bitte noch etwas Geduld bis zum nächsten Update/Test.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

klaus.schauer

Zitat von: DS_Starter am 05 Januar 2026, 11:13:01
ZitatZur berechneten Energie müsste m. E. auch die Sollinnentemperatur zurückgemeldet und im KI-Modell berücksichtigt werden.
Prinzipiell richtig. Die Sollinnentemp - es kann nur ein Wert sein - wäre in dem Kontext die "Prognose" für die angefragte Stunde.
Dann müsste es im setupEnvironment auch eine Temp-Erfassung des Ist-Wertes für eine Datenaufzeichnung geben.
Zur Erinnerung, bei der KI müssen die Trainingsfeatures mit den Features in der Abfrage übereinstimmen, also Anzahl und deren Aussage.
Weiß nicht so recht wo man diesen Wert hernehmen könnte, da die Räume oft unterschiedlich beheizt werden. Vllt. einen Raum (Wohnzimmer), der als Referenz dienen  kann.
Für die Isttemperatur muss natürlich ein Messpunkt verwendet werden, bei dem die Solltemperarturvorgaben an die Heizung auch möglichst unmittelbar spürbar werden. Die Isttemperatur wird dann immer mehr oder weniger träge den Solltemperaturvorgaben folgen. Weiterhin lassen sich daraus auch andere externe thermische Effekte ableiten, z. B. die Aufheizung durch Sonneneinstrahlung. Bisher habe ich für diesen dynamischen Effekt keine einfache deterministische Berechnung gefunden. Da ja auch die Sonneneinstrahlung Bestandteil des KI-Modells werden soll, wäre das wohl eher ein Fall für die KI. 

300P

Hier meine aktuellen Verbrauchsvorhersage-Ergebnisse (mit WP):
====>>>> Screenshot Nr. 1
Vermutlich nur wegen noch tieferer Temperatur als "gedacht"

Kleine "unwichtige" Anfrage / Anpassung (====>>> Screenshot Nr.2)

Statt nur "Abweichung" (Ist/Soll) der PV-Ertrags-Vorhersage zukünftig mit gleicher Logik für "Abweichung" (Ist/Soll) der Verbrauchsvorhersage-Werte.
->Auch wenn ich mit fast 100 % daneben ja nur einige Watt heute unter Schnee geerntet habe  ;D



Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

Gisbert

Zitat von: 300P am 04 Januar 2026, 17:55:18Kurzanleitung:

Meist schreibe ich mir am Anfang von neuen Sachen alle Parameter mit default-Wert - egal ob ich Standart nutze oder nicht -  zur Übersicht mit in die jeweiligen Attribute hinein um dann den einen deren evtl. mal dann auszuprobieren.
=>> Aber das ist Ansichtssache

Zu Anfang aber mind. eintragen (m.W.n.)
!!hinzufügen !!
attr >Forecast< ctrlDebug aiProcess
!!hinzufügen !!
attr <Forecast> aiConActivate=1

Dann zum ersten Start des Trainings mittels
set Forecast aiDecTree runConTrain.....und das Logbuch beobachten....
Kann bis zu  2-4 Stunden dann dauern ehe dieser Lauf beendet ist.

Dann optimieren durch "Feintuning" und diverse Einstellungen............ ;D

Der Rest nach dem WIKI bzw. Infos aus dem Thread ;)

Hallo 300P,

ich scheitere schon daran, dass ich dieses Attribut und set-Befehl nicht setzen kann:

attr <Forecast> aiConActivate=1
set Forecast aiDecTree runConTrain

Mein Forecast-Device kennt das schlicht nicht. Ich hab diese Version:
ZitatFVERSION
76_SolarForecast.pm:v1.60.7-s30548/2025-11-22

Da ich wöchentliche Updates mache, hoffe ich, dass das Device aktuell ist.

Viele Grüße Gisbert
Proxmox | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome | Panasonic Heishamon

Gisbert

Ich hab gerade update 76_SolarForecast.pm, gefolgt von shutdown restart durchgeführt.
Die Datei erhält ein aktuelles Speicherdatum auf meinem Server, aber der Inhalt scheint gegenüber der Version vom November nicht verändert zu sein.

Mach ich gerade was falsch?
Proxmox | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome | Panasonic Heishamon

DS_Starter

Hallo Gisbert,

die ganze KI Verbrauchsprognose Entwicklung findet bis jetzt nur im contrib statt. (Wiki). Zur Veröffentlichung ist es noch zu früh.

Wenn du damit arbeiten und ausprobieren möchtest, musst du dir bitte die contrib Version laden.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

300P

Zitat von: Gisbert am 05 Januar 2026, 16:47:52Ich hab gerade update 76_SolarForecast.pm, gefolgt von shutdown restart durchgeführt.
Die Datei erhält ein aktuelles Speicherdatum auf meinem Server, aber der Inhalt scheint gegenüber der Version vom November nicht verändert zu sein.

Mach ich gerade was falsch?
@Gisbert:
...und das geht aktuell z.B. per CLI mit :
"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
Das muss du aber nach jeden normalen "update" dann wiederholen und danach erst wieder ein "restart" von FHEM ausführen.
Oder du setzt temporär in ein "attr global exclude_from_update 76_SolarForecast.pm" speziell für SF.  ;)

PS:
Ich mache es deshalb schon länger so wie von mir in #3550 beschrieben da ich öfters "mit teste".
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

DS_Starter

#4752
Hallo zusammen,

in meinem contrib gibt es ein Update der 2.0.0.
Darin enthalten ist auch:

- ctrlSpecialReadings->careCycleViolationDays_XX  : Anzahl Tage seit Überschreitung des definierten careCycle-Zyklus von Batterie XX

Es wird ein Special Reading special_careCycleViolationDays_XX erstellt.
Die Info sollte funktionieren. Testen konnte ich das Feature noch nicht real, da ich bisher keine Überschreitung von careCycle hatte, lasse es aber mitlaufen. Vllt. schlägt es ja mal zu.

Weiterhin sind interne Features unseres NN ergänzt. Dadurch ändert sich deren Struktur und es muss! ein neues Training durchgeführt werden. Wenn das Modul ein benötigtes neues Training feststellt, wird der Zustand über die Ampel im UI signalisiert. Die Verbrauchsprognose fällt dann automatisch in den Legacy Mode zurück - es entstehen keine Leaks.

Beim Klick auf die Ampelanzeige wird ein Popup mit den Kennwerten geöffnet.

Ich habe bereits eine Idee für Semantiken, die den WP Betrieb unterstützen (unabhängig von der Legacy Integration lt. Vorschlag von Klaus Schauer).
Vllt. kann ich schon morgen ein weiteres Update bereitstellen.

Der weitere Screenshot zeigt die VB Prognose von heute mit der kommenden Nacht. Man sieht auch deutlich die "Ausreißer" bedingt heute durch Waschmaschine und Trockner. In gewisser Weise wird durch die eingebaute Trendfolgelogik (sichtbar 14 - 15 Uhr und 18 - 19 Uhr) der Tagesverbrauchswert stabilisiert.

LG,
Heiko

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

grappa24

Trendfolgelogik:

Nur damit ich es verstehe: Wenn das NN einen "unerwarteten" Verbrauch feststellt (hier: Haushaltsgeräte), dann passt "es" die prognostizierten Verbräuche der nächsten Stunden an?

Mal auf ein EV bezogen, woher kann "es" wissen, wann es das nächste mal zu einem erhöhten Verbrauch kommt?

Aber vlt. denke ich zu einfach  ;)
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

ZitatNur damit ich es verstehe: Wenn das NN einen "unerwarteten" Verbrauch feststellt (hier: Haushaltsgeräte), dann passt "es" die prognostizierten Verbräuche der nächsten Stunden an?
Nur der nächsten Stunde! direkt. Zumindest wenn nicht weitere Logiken, z.B. Temperatur/PV/Zeit-Semantiken stärkeren Einfluß haben. Dadurch nivelliert sich die Tagesgesamtverbrauchsprognose in gewisser Weise aus.

ZitatMal auf ein EV bezogen, woher kann "es" wissen, wann es das nächste mal zu einem erhöhten Verbrauch kommt?
Kann es nicht. Es fehlen momentan die Zusammenhänge (Semantiken) und Trigger. Die müssen noch gefunden und implementiert werden. Eine kann/wird der Ladezustand der EV-Batterie sein und die PV Vorhersage da ich/wir unterstellen, dass man möglichst bei PV Überschuß laden wird.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter