76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Ehe ich es vergesse :

DANKE an Heiko !!!!


Ich habe zwar eigentlich von NN keine Ahnung - aber du bringst mich auf den richtigen Weg zum Ziel

[DS_Starter]

Hallo 300P,

Also lasse ich jetzt laufen - außer Heiko schickt uns wieder "Was neues in Contrib"     

Ja vielleicht ... aber erstmal keine neuen Profile oder Feature-Blocks. Jetzt sind erstmal wieder Grundlagen für den nächsten Step EV usw. auf dem Plan, also herkömmliche Programmstücke.

prima Arbeit! 
Wir werden alle noch zum FANN Experten. 

Mit neuronalen Netzen so intensiv umzugehen, ist für mich auch vollkommen neu und habe mich die letzten Wochen/Monate reingestürzt -> von NN eigentlich auch keine Ahnung, aber durch diese Beschäftigung werden die Dinge immer ein bisschen klarer. Ich finde auch, dass die Lernkurve unglaublich steil ist wenn der schmerzhafte Einstieg erstmal geklappt hat und langsam Spaß macht.

LG,
Heiko

[DS_Starter]

Im contrib liegt ein Update für WP Nutzer.

Im Consumer Typ "heatpump" ist der Schlüssel swstate nun obligatorisch:

swstate   
Abweichend von anderen Consumern ist die Angabe verpflichtend, auch wenn der default verwendet werden soll. Durch Erstellung eines passenden
   userReadings kann gesteuert werden, ob man sowohl Laufzeiten für Heiz- und Kühlbetrieb, Warmwassererzeugung und Heizstabbetrieb zusammenfassen
   will, oder ob man ausschließlich die Laufzeiten des Heiz- und Kühlbetriebs als Zeiten für die Heizung separieren möchte.


Das ist eine wichtige Kleinigkeit, weil ich dadurch die On-Minuten für jede einzelne Stunde erfassen und in entsprechenden Semantiken der KI verfügbar machen kann.
Es dauert natürlich erstmal vllt. einen Monat bevor genügend Daten gesammelt sind das wirksam wird. Deswegen aktiviert bitte swstate in dem Consumer, ggf. vorher ein entsprechendes userReading für den on- bzw. off-Zustand erstellen.

[TheTrumpeter]

Es gibt nun das Attribut setupEnvironment. Hier können Umweltsensoren eingebunden werden, aktuell nur die real gemessene Außentemperatur z.B.:

Code Auswählen Erweitern

setupEnvironment   outsideTemp=MQTT2_ebusd_bai:1_Aussentemperatur_rounded


TOP, werd' ich dann gleich einbauen, aber gleich noch eine kleine Diskussion dazu:

Meine Wärmepumpe, vmtl. auch viele weitere Modelle, "arbeiten" für die Heizbedarfsberechnung nicht mit der Außentemperatur, sondern mit dem Durchschnitt der letzten x Stunden. x sollte dabei auf die Charakteristik des Hauses abgestimmt sein: wenig Speichermasse => geringe Dämpfung, große Speichermasse => große Dämpfung.

Nun ist es so, dass für die Berechnung der Heizkurve (d.h. Abweichung SOLL zu IST) eben diese Durchschnittstemperatur verwendet wird, für die Wärmeleistung, die die Wärmepumpe gerade liefern kann, ist aber die tatsächliche Außentemperatur relevant.

Was macht für die KI nun Sinn "bekanntzumachen"?
(Ich arbeite mit einer Durchschnittsbildung von 16h, d.h. Tag-/Nacht-Schwankungen werden relativ stark gedämpft.)

[TheTrumpeter]

Mit der kommenden Version wird beim Consumertyp "heatpump" der Schlüssel swstate Pflicht. Dadurch kann ich der KI explizit die Laufzeit der WP mitteilen was ich für die weiteren Semantiken benötige.
Wenn man, wie du es getan hast, nur in dem heatpump-Consumer die Schaltzeiten für Wärmeerzeugung erfasst und die anderen Zweige für WW und Heizstab nicht als Consumertyp "heatpump" definiert, dann fallen diese Zeiten in der expliziten Betrachtung des Heizverhaltens (oder Kühlverhaltens) in den vorgesehenen Semantiken heraus.
Also ich denke das wird die KI verstehen.

Genau so habe ich das auch von Anfang an umgesetzt, damit die Solarprognose die WW-Bereitung steuern kann.

Was ist künftig mit der Kühlung über die Wärmepumpe? Auch die habe ich in einem separaten Gerät abgebildet. Zum Einen, weil die Leistungsaufnahme im Kühlbetrieb höher ist, und zum Anderen um der Prognose die Chance zu geben die Abhängigkeiten richtig zu lernen.
Allerdings - und das ist der große Unterschied zum Heizen - ist der Kühlbetrieb da auch "ein", wenn der Verdichter nicht läuft:
Im Kühlbetrieb wird permanent das Wasser durch die Kühlkreise gepumpt, der Verdichter schaltet zyklisch ein, um es abzukühlen. Ein/Aus über "swstate" zu erkennen, wäre dann eher kontraproduktiv, weil das die Info zum Stromverbrauch ad absurdum führt. Hierfür wäre dann doch die Schwelle des Energiebedarfs sinnvoll, von mir aus auch eine Kombination aus beidem?

[300P]

Meine Wärmepumpe, vmtl. auch viele weitere Modelle, "arbeiten" für die Heizbedarfsberechnung nicht mit der Außentemperatur, sondern mit dem Durchschnitt der letzten x Stunden. x sollte dabei auf die Charakteristik des Hauses abgestimmt sein: wenig Speichermasse => geringe Dämpfung, große Speichermasse => große Dämpfung.

Bei den aktuellen Modellen ist / sollte diese Charakteristik des Hauses in den Werten zur Temperaturführung so einberechnet / enthalten sein.
->> Die Charakteristik des Hauses wird in der Steuerung der WP bei der Installierung hinterlegt / dort abgeändert.
Meist sind dies 3 oder 4 einstellbare "Punkte".
Dadurch werden von der internen Steuerungslogik der WP bereits gedämpfte Temperaturen (bei mir je nach Heizkreis möglich) zur Eigensteuerung berechnet.
Die gedämpften Aussemtemperaturwerte je Heizkreis sind bei mir gleich - sind ja im gleichen Gebäude.

Hier zwei Grafiken als Anlage bei mir:
1 x Aussentemperatur 24 h
1 x gedämpfte Aussentemperatur 24 h

[TheTrumpeter]

Dadurch werden von der internen Steuerungslogik der WP bereits gedämpfte Temperaturen (bei mir je nach Heizkreis möglich) zur Eigensteuerung berechnet.

Genau, ist bei mir auch so.

Die Frage ist, ob es besser ist diese gedämpfte Temperatur für SolarForcast zu "registrieren" oder doch eher die ungefilterte Außentemperatur?

Die WP steuert ja mit der gedämpften Temperatur, d.h. wenn die KI Zusammenhänge lernen will, wäre das die erste Wahl.
Andererseits ist die Leistung der Wärmepumpe von der aktuellen Außentemperatur und nicht der gedämpften abhängig, d.h. wenn es um den tatsächlich erzeugten Wärmebedarf geht, so ist die ungefilterte Temperatur spannend.

[300P]

Ich bleibe vorerst bei der "aktuellen" Aussentemperatur als "Inputgeber".

[klaus.schauer]

Im Consumer Typ "heatpump" ist der Schlüssel swstate nun obligatorisch:
swstate   
Abweichend von anderen Consumern ist die Angabe verpflichtend, auch wenn der default verwendet werden soll. Durch Erstellung eines passenden
userReadings kann gesteuert werden, ob man sowohl Laufzeiten für Heiz- und Kühlbetrieb, Warmwassererzeugung und Heizstabbetrieb zusammenfassen    will, oder ob man ausschließlich die Laufzeiten des Heiz- und Kühlbetriebs als Zeiten für die Heizung separieren möchte.

Das ist eine wichtige Kleinigkeit, weil ich dadurch die On-Minuten für jede einzelne Stunde erfassen und in entsprechenden Semantiken der KI verfügbar machen kann.

Für mich ist noch nicht klar, wie die realen Werte der Energie in den KI-Algorithmus eingehen. Stellt die aktuelle Gesamtleistung die Berechnungsgrundlage dar oder fließen die einzelnen Verbraucher - also nicht nur type=heatpump - mit ihren jeweils aktuell anstehenden Leistungen getrennt ein? Bei getrennter Erfassung könnte die Auswertung von EIN/AUS-Signalen auch anderer großer Verbraucher durch die eindeutige Zuordnung der Verbräuche die Mustererkennung und damit die Treffsicherheit der Prognose für die Wärmepumpe aber auch insgesamt u U. weiter verbessern.

[300P]

Edit :
Text komplett geändert

In  meinem BBQKees EMS-ESP gibt es dazu diverse WP-"Reading" die man dort z.B. per MQTT abrufen kann.

Ich nutze daher dann ein MQTT-Reading "boiler_data_hpcompon" aus der BBQKees-EMS_ESP MQTT-Schnittstelle.
Der Wert wird sich (derzeitig) allein nur vom Kompressorstatus (1 = on / off = off ->>ist leider so  -) bei mir ableiten.
-> Meine Buderus-WP  "WLW186i-7 MB AR" ist dann (derzeitig) genau 1 x consumerxx für SF bzw. das NN-Netz in SF.

Hier noch mein Wärmepumpen "consumer08" als Beispiel:

Code Auswählen Erweitern

SMA_Elgris_EM2
type=heatpump
power=2500
icon=sani_heating_heatpump@orange
pcurr=Bezug_Wirkleistung:W               
etotal=Bezug_Wirkleistung_Zaehler:kWh
noshow=0
switchdev=MQTT_EMSwp                   
swstate=boiler_data_hpcompon:1:off
comforttemp=20



[grappa24]

In meinem BBQKees EMS-ESP gibt es dazu diverse WP-"Reading" die man dort z.B. per MQTT abrufen kann.

Cool, genau das nutze ich auch für meine Bosch/Junkers Gasbrennwert-Heizung bzw. die Integration via MQTT in FHEM

[300P]

Stellt die aktuelle Gesamtleistung die Berechnungsgrundlage dar oder fließen die einzelnen Verbraucher - also nicht nur type=heatpump - mit ihren jeweils aktuell anstehenden Leistungen getrennt ein?

Momentan (m.W.n.) ist der "type=heatpump" eine ConsumerXX-Sonderstellung

[DS_Starter]

Nabend zusammen,

das ist ja eine rege Diskussion ... 

Nun ist es so, dass für die Berechnung der Heizkurve (d.h. Abweichung SOLL zu IST) eben diese Durchschnittstemperatur verwendet wird, für die Wärmeleistung, die die Wärmepumpe gerade liefern kann, ist aber die tatsächliche Außentemperatur relevant.

Was macht für die KI nun Sinn "bekanntzumachen"?

Ihr lasst am Besten nur die gemessene Temperatur mitteilen. Diese Werte werden für jede Stunde in den Rohdaten gespeichert. Daraus werden dann aber 1h / 3h Deltas oder bei Bedarf und Feature-Implementierung rollierende 3h / 6h oder 12h Durchschnitte der KI zur Verfügung gestellt. Das passiert aber alles bei der Semantik/Feature-Implementierung die ich gemeinsam mit euch baue und testen... Schritt für Schritt.

Was ist künftig mit der Kühlung über die Wärmepumpe? Auch die habe ich in einem separaten Gerät abgebildet. Zum Einen, weil die Leistungsaufnahme im Kühlbetrieb höher ist, und zum Anderen um der Prognose die Chance zu geben die Abhängigkeiten richtig zu lernen.
Allerdings - und das ist der große Unterschied zum Heizen - ist der Kühlbetrieb da auch "ein", wenn der Verdichter nicht läuft:
Im Kühlbetrieb wird permanent das Wasser durch die Kühlkreise gepumpt, der Verdichter schaltet zyklisch ein, um es abzukühlen. Ein/Aus über "swstate" zu erkennen, wäre dann eher kontraproduktiv, weil das die Info zum Stromverbrauch ad absurdum führt. Hierfür wäre dann doch die Schwelle des Energiebedarfs sinnvoll, von mir aus auch eine Kombination aus beidem?

Ja, genau eine Kombination. Auch wenn der heatpump-Consumer ein paar Besonderheiten hat, gelten die grundsätzlichen Schlüssel-Möglichkeiten. Also hier speziell der pcurr-Schlüssel, den man mit einem <Schwellenwert> (W) angeben kann, ab dem der Verbraucher als aktiv gewertet wird. Über swstate bekommt das Modul mit dass der Consumer "physisch" on/off ist und über den optionalen Schwellenwert ob er logisch! on/off ist.

Für die WP bedeutet es mit Schwellenwert:

- swstate = on -> Schwellenwert überschritten ? Ja -> WP ist "on" , ? Nein -> WP ist "off"
- swstate = off -> WP ist "off"

Für die KI bitte nicht zwei getrennte Heiz- und Kühl-Consumer anlegen, sondern einfach nur eine WP. In den Lerndatensätzen gibt es dann Verknüpfungen von Temperaturen im Vergleich mit der Komforttemperatur sowie jahrezeitliche Zusammenhänge und mehr.

Für mich ist noch nicht klar, wie die realen Werte der Energie in den KI-Algorithmus eingehen. Stellt die aktuelle Gesamtleistung die Berechnungsgrundlage dar oder fließen die einzelnen Verbraucher - also nicht nur type=heatpump - mit ihren jeweils aktuell anstehenden Leistungen getrennt ein?

Das ist generell ein schwieriges Thema. Grundsätzlich kann man dem neuronalen Netz nur Verknüpfungen/Sematiken bereitstellen, die das Verhandensein eines bestimmten Energieverbrauchs erklären. Das sind zum Beispiel:

- Tageszeiten
- Anwesenheiten
- Batterieladezustände
- Temperaturen
- PV Ertrag
- PV Prognose
- Jahreszeiten
- Feiertage, Arbeitstage, Wochenende
- Vorhandensein von WP, EV
- Sonnenstände
- ....

Aus diesen Dingen implementiere ich noch zusätzliche Signale wie diese:

Code Auswählen Erweitern

# --------------------------------------------------------
# Semantik: Menschlicher Tagesrhythmus (PV-unabhängig)
# --------------------------------------------------------
semantics_human_rhythm => sub {
    my ($f) = @_;
    return [
        # --- MORGEN ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_morning}),             # Aufstehen / Geräte an

        # --- MITTAG ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_noon}),                # Kochen / Haushalt

        # --- ABEND ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_evening}),             # Kochen / Abendaktivität

        # --- SPÄTER ABEND ---
        softplus($f->{delta1_norm_neg} * $f->{hour_class_lateevening}),         # Geräte gehen aus
    ];
},

Das sind keine Berechnungsvorschriften, aber sie sagen beispielsweise es sind gerade Morgenstunden (hour_class_morning) und es gibt ein Ansteigen des stündlichen Energieverbrauchs in den Trainingsdaten (delta1_norm_pos) dann stehen die Bewohner typischerweise auf und machen sich Kaffee und Toastbrot. Das ist nur ein Signal im Normierungsbereich 0...1 oder -1 ... 1 je nach verwendeter Aktivierungsfunktion (mit oder ohne SYMMETRIC).
Ob die KI diesen "Hinweis" von mir Beachtung schenkt und daraus etwas lernt und welche Gewichtung sie dieser Information beimisst kann ich weder beeinflussen noch wissen. Nur durch Einbau, Testtraining und Auswertung der Kennzahlen erkennt man ob die Maschine lernt.

Wie schon mehrfach erwähnt sind Waschmaschine und Trockner echte Störenfriede weil ich einfach kein semantisches Zusatzsignal generieren kann. Es gibt weder Temperatur noch Tages/Jahreszeitabhängigkeiten. Das passiert einfach und die KI kann es nicht vorhersehen. Abhilfe wäre z.B. ein "Füllsensor" der Schmutzwäsche. Ab x% wird der Wama Betrieb wahrscheinlich ....
Aktuell wird duch die Trendfolge-Logik ein Ausgleich geschaffen.

Bei getrennter Erfassung könnte die Auswertung von EIN/AUS-Signalen auch anderer großer Verbraucher durch die eindeutige Zuordnung der Verbräuche die Mustererkennung und damit die Treffsicherheit der Prognose für die Wärmepumpe aber auch insgesamt u U. weiter verbessern.

Absolut. Allerdings bräuchte man dann wieder Zusammenhänge wann diese anderen Großverbraucher üblicherweise in Betrieb gehen, siehe Wama und Trockner.


Genau solche Zusatzinformationen versuche ich jetzt für EV zusammenzustellen und einzubauen um dann daraus Profile wie oben zu sehen zu gestalten. Dazu gehören noch Anwesenheiten, Feiertagskalender und solche Dinge.
Es ist ein sehr weites Feld. Dagegen ist die PV Vorhersage mit KI relativ einfach weil von relativ wenigen Größen der Wetterdienste und Geometrien abhängig.