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.