76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

stefanru

Ich habe mich ja nicht getraut zu Fragen aber da Gisbert das Thema jetzt schon angesprochen hat.
Ich habe seit 3 Monaten auch eine Wärmepumpe, habe diese auch als Verbraucher im FHEM und habe mir auch schon gedacht eine Temperatur Kopplung wäre ideal.
Bei mir schwankt der Wert sogar noch mehr, bei tiefen minus graden über 100kWh am tag und jetzt wo es milder wird vielleicht 40kWH.
Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Eventuell könnte man hier dem Verbraucher noch eine Temperatur Reading mitgeben und dieses mit in die Vorhersage einfließen für diesen Verbraucher?
Ich wäre auch bereit zu helfen, wenn gewünscht, maintaine ja jetzt das vitoconnect Modul was zumindest Viessmann Wärmepumpen anbinden kann.
Dort könnte man auch COP und andere Werte bekommen, aber ich denke Temperatur wäre schon ein super Wert den man einfließen lassen könnte.

Danke und Gruß,
Stefan

Gisbert

Zitat von: DS_Starter am 29 Januar 2025, 22:45:33Ich habe eine SolarForecast Version in mein contrib geladen. Hole dir sie bitte und starte FHEM neu.
Dann schauen wir wie es damit aussieht.

Jetzt sieht es wohl gut aus:
2025.01.29 23:59:03.034 4:  mySolarForecast - Notification System - Message file >controls_solarforecast_messages_prod.txt< is retrieved non blocking
2025.01.29 23:59:03.422 4:  mySolarForecast - Notification System - new Message File updated to .//FHEM/controls_solarforecast_messages_prod.txt
2025.01.29 23:59:03.431 4:  mySolarForecast - Notification System - read local Message File >controls_solarforecast_messages_prod.txt< with 14 entries.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Skusi

Hallo zusammen, super hier mitzulesen wie dieses geniale Modul immer intelligenter wird.
Allerdings wird es auch zunehmend komplizierter zu verstehen wie man es richtig mit Infos füttert. Ich benutze das Modul schon ca 3-4 Jahre und meine Anlage hat sich in der Zeit auch etwas erweitert. Nun beobachte ich die Prognosen und bin nicht zufrieden mit der Genauigkeit. Einerseits liegt es sicher an den Wettervorhersagen des DWD die selten der der Realität entsprechen, andererseits mach ich mir Gedanken über die Richtigkeit der Einbindung meiner etwas speziellen Anlage.

Aufbau:
6x Microwechselrichter 320 Wp (1 Panel) als Feld auf Dach Süd Ausrichtung
1x Microwechselrichter 600 Wp (2 Panel) auf Schuppendach Süd Ausrichtung an Solix Akku 1600 Wh

Das 6er Feld heißt im Modul "Dach" und das auf dem Schuppen "Akku"

Der 600 Wp Wechselrichter speist am Tage ausschließlich den Solix Akku bis er voll ist und leitet danach alles am Akku vorbei ins Hausnetz. Ab 21:00 entlade ich dann den Akku mit konstant 180 Wh bis er lehr ist.

Die Daten aller Wechselrichter werden über eine DTU eingesammelt und in Fhem bereitgestellt. Der Solix Akku ist auch als Device per MQTT eingebunden und stellt die benötigten Daten bereit.

Definiert habe ich das derzeit im Modul so:(zusammen kopiert)
attr SolarForcast setupBatteryDev01 Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W intotal=statistics_1_total:kWh outtotal=statistics_2_total:kWh cap=1600:Wh charge=solarbank_info_solarbank_list_1_battery_power
attr SolarForcast setupInverterDev01 OpenDTU pv=Total_power:Wh etotal=Total_yieldtotal:kWh capacity=2400
attr SolarForcast setupInverterStrings Dach,Akku
attr SolarForcast setupStringPeak Dach=1.92 Akku=0.76

setstate SolarForcast 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
setstate SolarForcast 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10

Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.

Meine Frage nun: Ist das so in Ordnung, oder kann das Modul das so durcheinander bringen das die real Daten so von der Prognose abweichen.

Macht es Sinn den 600er Wechselerichter von dem InverterDev01 abzukoppeln und über ein Dummy ein InverterDev02 davon zu machen ?

Ich bin etwas Ratlos wie die Daten einer solchen Konstellation im Modul verarbeitet werden und ob es so zu Fehler in den Berechnungen kommt.
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

cwagner

Zitat von: stefanru am 29 Januar 2025, 23:40:13... habe diese [Wärmepumpe] auch als Verbraucher im FHEM und habe mir auch schon gedacht eine Temperatur Kopplung wäre ideal.
Bei mir schwankt der Wert sogar noch mehr, bei tiefen minus graden über 100kWh am tag und jetzt wo es milder wird vielleicht 40kWH.
Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Zitat von: Gisbert am 29 Januar 2025, 20:36:15Der Verbrauch [meiner Wärmepumpe] bei mir hängt stark von der Außentemperatur ab, da ich eine Wärmepumpe habe.
Beispiel:
Sehr milde Temperaturen: 15 kWh am Tag
Sehr kalten Temperaturen: 40 kWh am Tag
Der vom Modul prognostizierte Verbrauch ist 30 kWh für heute, der tatsächliche Verbrauch liegt bei 18 kWh.

Ich habe keine Verbraucher in SolarForecast angelegt. Das war mir bisher zuviel Aufwand.

Gibt es eine Möglichkeit eine bessere Prognose für den Verbrauch zu bekommen?

Mit dem vorausschauende Heizungssteuerung beschäftigte ich mich auch: SolarForecast hat nmM schon viel unter der Haube, um sich in diese Richtung weiterzuentwickeln. Ich verfolge zwei Ansätze: Auf der Ist-Seite empirisch eine Relation herstellen zwischen den tatsächlichen Verbräuchen und der Außentemperatur: Ganz stumpf über meine Logs. Dabei orientiere ich mich an der (über das Statistikmodul sehr leicht umsetzbaren) Definition der Wetterdienste einer "Tagesmitteltemperatur" (TM) als Ist gemessen auf unserem Grundstück. Die TM wird ja auch für Heizspiegel herangezogen.
Daraus konnte ich bei mir (noch keine Wärmepumpe, aber fahre die bisherige Heizung versuchsweise mit den Vorlauftemperaturen und der Trägheit einer Wärmepumpe über den bereits montierten Pufferspeicher) mit Hilfe der Logs eindeutige Korrelationen feststellen. Wenn für einen Tag mit 5° Tagesmitteltemperatur 80 kWh Heizleistung verbraucht wurden, dann finde ich diesen Wert auch für die anderen Tage mit einer ähnlichen TM. So beschreiben es ja auch Gisbert und Stefan. Abweichungen kommen hier in Norddeutschland eindeutig bei scharfem Nordwind. Zweiter Parameter ist der solare Gewinn durch starke Sonneneinstrahlung, der aber (außer in Hoch-Nebelphasen der letzten Wochen) mit Hilfe der SolarForecast-Werte gut einzubringen sein müsste. Müsste, weil ich für diesen Aspekt erst Daten sammeln muss.

Nach "Vorne" sehe ich dann SolarForecast. Es nutzt ja die Vorhersagemodell der Wetterdienste, die natürlich auch die TMs für die nächsten Tage rechnen. Für meinen Standort passen die auch gut: Also für heute sind 5° TM vorhergesagt, ich erwarte also einen Verbrauch von 80 kWh - leider sagt das Modul SolarForecast aber auch, dass ich heute nur etwa 4 kWh PV "ernten" werde...

Das Ganze hat für mich noch den zusätzlichen Nutzen, dass bei Anwendung dynamischer Stromtarife ebenfalls ein "Vorratsheizen" oder andersherum: "zuwartendes" Heizen geplant werden könnte. Wenn ich morgen nach TM 100 kWh (Korrektur Mehrbedarf wegen Sturm oder Minderbedarf wegen Sonne ist für mich noch Theorie) brauchen werde, kann ich in Billigphasen Netzstrom als Wärme im Puffer einlagern. Wenn Solarforecast aber voraussagt, dass ich von 11-15 Uhr 60 kWh PV ernte, lass ich die Heizung nicht auf Netzstrom pumpen, nehme vielleicht sogar in Kauf, von 9 bis 12 einen halben Grad unter meine Solltemperatur zu rutschen, um die WP dann von 11-15 durchheizen zu lassen, dabei den Puffer auch über das Benötigte zu erwärmen. Davon kann ich dann ohne Netzbezug von 16 bis vielleicht 20 Uhr aus dem Puffer "zehren". Damit wäre ich quasi automatisch wieder im günstigen dynamischen Tarif für den nächsten Tages-Turn. Ganz bewusst verbrate ich PV-Strom nicht über einen Heizstab, sondern nutze den Hub der Pumpe und lagere PV auch nicht vorrangig in eine Batterie (um die ich für den Sommer ja nicht rumkomme), um die Wandlungsverluste von etwa 20 Prozent (rein+raus) zu vermeiden.

Letzter Gedanke: für das Durchdringen auch der Reaktions-Trägheit des Systems und der Korrelationen/Einflussparameter halfen mir die in der FHEM-Datenbank gelogten Echtdaten über mehrere Jahre. Wer das nicht hat, könnte mMn sich auch hier näherungsweise bedienen: Gradtagszahlen. Seine eigenen Verbräuche sollte man aber schon auf Tages- besser noch auf Stundenbasis haben ;-)

Viele Grüße
Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

TheTrumpeter

Zitat von: stefanru am 29 Januar 2025, 23:40:13Ich denke Wärmepumpen sind Verbraucher die wir immer mehr sehen werden.
Eventuell könnte man hier dem Verbraucher noch eine Temperatur Reading mitgeben und dieses mit in die Vorhersage einfließen für diesen Verbraucher?
Schwierig...
Momentan lebe ich einfach damit, dass die Prognose entsprechend "unscharf" ist, insbesondere bei großen Temperaturschwankungen.
Nur, woran festmachen?
Außentemperatur alleine ist es nicht, auch die Sonnenstunden bzw. der solare Ertrag durch die Fenster kann je nach Haustyp relevant sein.

Im Sommer ist dann die Innentemperatur und der Taupunkt die "Führungsgröße" für die Verbrauchsprognose der "Kälte"pumpe... ob das einfach abzubilden ist?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

stefanru

Naja klar gibt es da noch mehr Parameter.
Und wenn man im Sommer kühlt mit der Anlage (habe ich nicht vor) ist es nochmal anders.
Ich sehe ein dass es nicht so einfach ist.

Man muss ja aber auch nicht gleich die allumfassende Lösung für alle Eventualitäten haben.
Ich hatte jetzt gehofft wenn man der KI ein paar Daten mehr gibt (z.B. Temp und Solarertrag) könnte sie sich über die Zeit hier eventuell doch eine ganz gute Abschätzung für diesen Verbraucher erzeugen.

Ich denke man solle / kann hier keine exakte Wissenschaft draus machen. Es gibt zu viele Einflussgrößen und selbst die Vorhersagen von Temperatur und Solarertrag sind ungenau.
Dann kommt noch persönliches Verhalten hinzu. Sollte einem besonders kalt sein (krank) und man dreht deswegen die Heizkörper mehr wie sonst auf oder man hat Besuch oder man duscht heute mehr, oder, oder, oder.
Ich würde hier wirklich nur die rudimentärsten Daten nehmen und hoffen dass eine entsprechend große Abhängigkeit besteht dass zumindest ein Trend ermittelt werden kann.

Gruß,
Stefan

Gisbert

Zitat von: TheTrumpeter am 30 Januar 2025, 13:58:26Schwierig...
Momentan lebe ich einfach damit, dass die Prognose entsprechend "unscharf" ist, insbesondere bei großen Temperaturschwankungen.
Nur, woran festmachen?
Außentemperatur alleine ist es nicht, auch die Sonnenstunden bzw. der solare Ertrag durch die Fenster kann je nach Haustyp relevant sein.

Im Sommer ist dann die Innentemperatur und der Taupunkt die "Führungsgröße" für die Verbrauchsprognose der "Kälte"pumpe... ob das einfach abzubilden ist?

Die Außentemperatur hat den überwiegenden Einfluss auf die benötigte Wärmemenge. Nicht alle Fenster sind gleichzeitig zur Sonne gerichtet, wenn sie im Winter denn ausnahmsweise mal scheint, also auch aus diesem Grund ist dieser Faktor untergeordnet.
Eine verbesserte Verbrauchsprognose im Winter ist hilfreich für die Lade/Entladestrategie des Speichers auch im Hinblick auf eine strategischen Reserve für den Brown/Blackout-Fall. Bei entsprechenden solaren Überschuss gegenüber dem Verbrauch entlade ich den Speicher auf ein sinnvolles Minimum, um den Speicher voll nutzen zu können.
Im Sommer ist die Verbrauchsprognose eher nicht so wichtig, da da viel Sonne vorhanden ist und der Speicher meist nie leer wird.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

cwagner

Zitat von: Gisbert am 30 Januar 2025, 14:13:13Die Außentemperatur hat den überwiegenden Einfluss auf die benötigte Wärmemenge. Nicht alle Fenster sind gleichzeitig zur Sonne gerichtet, wenn sie im Winter denn ausnahmsweise mal scheint, also auch aus diesem Grund ist dieser Faktor untergeordnet.
Eine verbesserte Verbrauchsprognose im Winter ist hilfreich für die Lade/Entladestrategie des Speichers ...

Genau das ist auch meine Erfahrung - die Außentemperatur hat den entscheidenden Einfluß auf den Wärmebedarf des ganzen Hauses, auch wenn einzelne Räume durch solaren Eintrag stark beeinflusst werden können (vernünftigerweise gehen dann dort die Heizkörperthemostaten zu, soweit man eine Einzelraumregelung hat, was mit Wärmepumpen ohne Speicher ja gerne vermieden wird, um den Mindestvolumenstrom garantiert zu erreichen). Bei der von mir bevorzugten Tagesmitteltemperatur ist die Wärmewirkung der Sonne indirekt auch dadurch berücksichtigt,das kräftiger Sonnenscheinn üblicherweise die Temperaturen mittags hochtreibt. An solch klaren Wintertagen sind aber üblicherweise durch die fehlende Schutzwirkung der Wolken die Nächte auch besonders kalt, weswegen ich vor einigen Jahren das als zweiten Grund fand, die TM zu benutzen.
Die Genauigkeit der Temperaturvorhersage ist auch nicht so erheblich: in meinem aktuell verwendeten Modell bedeutet ein Grad Vorhersage-Fehler im Bereich -5 bis +5° eine Veränderung der Mindesttemperatur meines Speichers um gut 0,5 Grad, das ist ein Wärmeinhalt von 5,8 kWh, die herzustellen braucht meine Referenz-WP-Installation in dem Temperaturfenster gerade mal 1,5 kWh Strom... Bei der Verlässlichkeit der PV-Prognose stelle ich da höhere Ansprüche, weil die Auswirkungen eines Fehlers auch finanziell deutlicher sind.

Bitte meine Beiträge gerne kritisch hinterfragen, ich bin mir sicher, dass ich längst nicht alles richtig bedacht habe.

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Parallix

Meinerseits möchte ich anregen, hier eher einen sehr generischen Weg zu gehen, um u.a. auch andere (künftige) Anwendungsfälle gleich mit berücksichtigen zu können.

Für ein besseres Forecasting müssten dem Forecaster alle als wesentliche erkannten Einflussgrüßen in quantifizierter Form (Vektor mit Einflussgrößen) vorliegen. Diese müsste man dem Forecaster als solche bekanntmachen. Für den Fall ,,Wärmepumpe" dürfen das neben der Außentemperatur auch Raumtemperaturen sowie die zu solare Strahlungsmenge sein. Auf dieser Basis ließe sich dann klassische oder aber KI-basiertes Forecasting durchführen. Der Einsatz der KI-basierten Lösung erscheint mir für diesen Zweck geeigneter als eine klassische modellbasierte Lösung, da erstere universeller ist und daher für den oben genannten generischen Weg äußerst prädestiniert ist.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Guten Abend zusammen,

die rege Diskusion zeigt mir wie stark doch das Interesse auch an einer wertigen Verbrauchsvorhersage ist.

Ich habe mir auch ein paar Gedanken zu einem gangbaren Weg gemacht und ein wenig im Netz gestöbert.
Dabei bin ich heute auf diese Seite gestoßen:

Optimierte KI-Prognose für Stromverbrauch und -erzeugung: Nachhaltige Energieeffizienz

Ich will nicht sagen das Digitalzentrum Hannover hätte bei SolarForecast abgeschaut  :), aber wenn ihr euch den Beitrag durchlest, werdet ihr sicherlich auch schnell Parallelen zum SolarForecast Modul erkennen.
Mich bestärkt es in der Ansicht, dass wir uns auf einem guten Weg Weg befinden und auch schon sehr gut "im Rennen" liegen.

Also was die Verbruchsprognose betrifft, werde ich die AI Raw-Daten (get ... valDecTree aiRawData) um Verbrauchswerte anreichern. Temepraturen sind bereits vorhanden. Mit diesen Daten kann eine zweite KI Instanz installiert werden, die die Verbrauchsprognose unterstützt. Alternativ schaue ich mir auch mal den in dem Link verwendeten K-Nearest-Neighbor (KNN) Algorithmus an.
Der erste Schritt ist zunächst eine erweiterte Datensammlung die ich im Modul implementiere.

@Skusi
ZitatDa die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.
Das ist ein nicht so glückliches Setup. Abgesehen davon dass ich nicht verstehe wieso per DTU auch in der Nacht eine PV Leistung übermittelt wird, ist es problematisch wenn die erzeugte WR Leistung nicht in den setupInverterDevXX - Readings ankommt. Nur dort wird die PV-Leistung auch als solche gewertet.
Im BatteryDev01 gemeldete Leistungen können im Fall des BatIn auch eine Beladung aus dem Netz sein.
Hier müsstest du schauen, ob du mittels userReadings ein genaueres Input dem Modul bereitstellen kannst.

@Gisbert,
danke für deine Rückmeldung. Die Änderung checke ich ein und ist dann morgen früh im Update.

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

Parallix

Zitat von: DS_Starter am 30 Januar 2025, 19:11:38...
Also was die Verbruchsprognose betrifft, werde ich die AI Raw-Daten (get ... valDecTree aiRawData) um Verbrauchswerte anreichern. Temepraturen sind bereits vorhanden. Mit diesen Daten kann eine zweite KI Instanz installiert werden, die die Verbrauchsprognose unterstützt.
...

Hast Du mal über meine Vorschlag in Richtung Generalisierung nachgedacht?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Moin Parallix,

ja habe ich. In diese Richtung will ich ja durch den Einsatz/Unterstützung einer KI für diese Prognose gehen.
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

Parallix

Zitat von: DS_Starter am 31 Januar 2025, 07:44:17Moin Parallix,

ja habe ich. In diese Richtung will ich ja durch den Einsatz/Unterstützung einer KI für diese Prognose gehen.

Hatte Dein vorheriges Posting so verstanden, dass Du ein ein einmal fixiertes Set an Readings nutzen möchtest. Meinerseits hatte ich angeregt, dass Du dem User die Möglichkeit gibst. dieses Set selber zu definieren. Aus meiner Sicht wäre es vielleicht sogar sinnvoll, dem User gleich die Möglichkeit zu geben, Forecastings für unterschiedliche Verbraucher (auf Basis unterschiedlicher Readings) erstellen zu lassen. Vielleicht sollte man die Gelegenheit nutzen, die damit verbundenen Codeanteile aus SF (Solar Forecasting) zu ziehen und in einem neuen Modul CF (Consumer Forecasting) zu bündeln, oder?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

ZitatHatte Dein vorheriges Posting so verstanden, dass Du ein ein einmal fixiertes Set an Readings nutzen möchtest.
Nicht Readings, aber entsprechende Inputdaten mit denen die verwendete KI trainiert werden kann.
Diese Inputdaten finden sich im "get ... valDecTree aiRawData" visualisiert. Diese Daten können bei Bedarf angereichert/ergänzt werden, benötigen aber eine Struktur damit AI::DecionTree damit etwas anfangen kann (z.B. diskrete Daten in Bins organisieren).
Deswegen ist das nicht so "frei" machbar.
Möglicherweise setze ich auch nochmal eine andere KI ein, z.B. AI::MxNet. Das ist dann nochmal eine andere Hausnummer.

Für einzelne Verbraucher eine KI-Prognose zu erstellen bedarf nochmal deutlich mehr Daten, nämlich die Stundenwerte für jeden einzelnen Verbraucher über eine lange Zeit speichern und natürlich auch managen wenn z.B. ein Verbraucher sich ändert oder seine Kenngrößen ändert.
Man kann sicher alles erdenkliche erschaffen, es braucht nur sehr viel Zeit. Irgendwann braucht man vllt. auch einen Datencontainer (z.B. ein Redis) um die immer größer werdenden Mengen performant zur Verfügung zu haben. So kommt eins zum Anderen und ich muß aufpassen dass ich mich vor mir selbst schütze. ;)
Deswegen in kleinen Schritten voran...


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

Parallix

Zitat von: DS_Starter am 31 Januar 2025, 10:47:16...
Diese Daten können bei Bedarf angereichert/ergänzt werden, benötigen aber eine Struktur damit AI::DecionTree damit etwas anfangen kann (z.B. diskrete Daten in Bins organisieren). Deswegen ist das nicht so "frei" machbar.

Zitat...
So kommt eins zum Anderen und ich muß aufpassen dass ich mich vor mir selbst schütze. ;)

Das Problem kenne ich und man sollte es auch ernst nehmen!

Hatte mich eben nur gefragt, ob man SF (weil es ja für "Solar Forecasting" steht) nicht durch Herausnahme des "Consumer Forecasting"-Teils  etwas entschlacken könnte und damit vielleicht für Dich aber auch die User handhabbarer machen könne. Bei nochmaligem Betrachten müsste man dann - insb. wenn man in Richtung eines EMS gehen will - wahrscheinlich auch noch mehr machen, weil die BATs (als besondere Consumer, die auch liefer können) ja einen wichtigen Anteil ausmachen.

Ergo: Dein Modul ist super, vom Funktionsumfang ist unglaublich viel drin und da es wird wahrscheinlich immer schwieriger wird, Teilfunktionalität (wie das Forecasting für "normale" Consumer) auszulagern, würde ich es hier (u.a. auch aus Selbstschutzgründen) an Deiner Stelle auch nicht mehr anreichern.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS