76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Ich würde sagen das die Minuten bei allen 3 Betriebs-Heatpump verzeichnet werden 😔🧐, da das Reading es ja so sagt.

Ich schlage deshalb vor für jede der 3 Heatpump ein eingeschränktes User-Reading zu nutzen.
Z.B.
opmode=heating,off (Heizmodus)
Und zusätzlich dann alle anderen ,,nichterwünschten" als ,,off" in dem Userreading ,,übersetzen".


opmode=hotwater,off (WW-Modus)

Zusatzheizer verstehe ich nicht zu 100 %
Der Verbrauch der in der Wärmepumpe herstellerseits eingebauten E-Heater fällt immer in den entsprechenden Modus zusätzlich an.

Oder ist ein PV-Heater im WW-Speicher gemeint der separat nachtraglich eingebaut wurde ?

[DS_Starter]

st sichergestellt, dass die Laufzeit beim jeweiligen Verbraucher nur dann gezählt wird, wenn dieser Verbraucher tatsächlich eingeschaltet ist (swstate = on) bzw. eine Leistung aufnimmt?

Ja. Technisch wird der Verbrauch der WP aufgezeichnet, wenn swstate "true" ist bzw. wenn das im Consumer Schlüssel etotal angegebene Reading Energiedifferenzen liefert.
Die opmodes dienen zur Aufzeichnung der Anteilsminuten p.h. auf den jeweiligen Modus. Das ist eine Grundlage um weitere Lernmomente zu implementieren. So kann zum Beispiel ein setEvironment "Heißwassertemperatur" erfasst werden. Im Zusammenspiel der aufgezeichneten Temepraturgradienten und dem hotwater-Modus bzw. dessen Energieanteil kann die KI die Energieabhängigkeit von der Wassertemperatur lernen.
D.h. die opmodes zeichnen nur die Minuten auf, die sie innerhalb der Stunde belegen. Die in der Stunde aufgezeichnete Energiemenge wird später anteilig auf die Modes verteilt.
Das ist zugleich auch die Schwäche der Modellierung, denn die Anteile werden nicht linear sein oder wenn die WP nicht aktiv ist, der Modus aber eingeschaltet bleibt (nicht off), zählen die Statusminuten weiter und nehmen sich so einen Anteil der ungerechtfertigt ist.
Aber diese Unzulänglichkeiten muß man wohl akzeptieren es sei denn mir fällt noch etwas besseres ein, was auch umsetzbar ist.

LG,
Heiko

[300P]

Hab mal mit ansatzweise dem Kumpel Internet gesprochen....

Code Auswählen Erweitern

Moderne Wärmepumpen stellen ihren aktuellen Modulationsgrad (0–100 %) oder die Verdichterfrequenz (Hz) als Reading bereit (oft über Modbus, ISG oder eine API).
Statt reiner Minuten zeichnest du einfach Leistungspunkte (Modulations-Minuten) auf.

Logik:
Wenn die WP eine Minute lang auf 40 % Modulation im heating-Modus läuft, bekommt der Modus 0,4 Punkte.
Läuft sie eine Minute auf 90 % im hotwater-Modus, bekommt er 0,9 Punkte.
Falls du dieses Reading hast, löst das dein Modulationsproblem mathematisch sofort auf.

Das würde aber ein weiteres bereitstellen eines Reading aus der (modulierenden) Heatpump bedeuten.
Bei mir kein Problem - Reading ist verfügbar.(Wer eine nicht modulierende WP hat ? ? ? ! ! !)
Aber am Ende sind wir auch nicht genauer, denn modulierend heißt ja rauf runter "wie es grade notwendig ist" und nicht einmal 40 % für die ganze Zeitdauer.

Also ->> Es müsste dann ja jede Minute einmal der Wert  in dem jeweiligen Modus addiert werden der sich aus aktueller Modulation am Minutenende und bei dem jeweiligen aktuellen Modus zum Minutenende ergibt....?

[DS_Starter]

@all,

nun habe ich die BEV-Intergration für das KI-Training implementiert.
Dazu setzt man in aiControl->aiConProfile das Flag "bev". Also zum Beispiel:

  aiConProfile=v1,active,pv,bev

In dieser Version habe ich nach einigem Nachdenken das von Wolle02 in #6362 bemängelte Verhalten des "Nachziehens" oder anders gesagt der "Selbstheilung" elimeniert. Dies hat nun Vor- und Nachteile.
Nachteil ist, dass es wahrscheinlich höhere Abweichungen und Fehlerraten geben wird bei gleichzeitiger guter/sehr guter Visualisierung, je nachdem wieviel und wie gute Features der KI zur Verfügung stehen.

Dieser Nachteil ist zugleich auch eine Stärke, das Lernen wird "ehrlicher", fehlende Feaures werden deutlicher und Verbesserungen/Einflüsse zusätzlich bereitgestellter Information werden direkt sichtbar. Der Nachzieheffekt ist beseitigt, die in einer Stunde festgestellten Abweichungen werden nicht mehr durch eine "Gegenbewegung" in der nächsten und weiteren Stunden ausgeglichen.

Das sieht zwar am Ende des Tages gut aus, aber wie Wolle02 schon bemerkte, ist dieses Verhalten potenziell problematisch für aufbauende Steuerungen.
Der besser Weg ist semantische Zusammenhänge zu stärken, wie zum Beipiel die im Modul pro Stunde erfassten Consumer -Energieverbräuche der KI ergänzend zum Gesamtenergieverbrauch bereitzustellen.
Und es bietet Raum für weitere Bereitstellungen, wie zum Beispiel Zeitmanagement bezüglich des BEV-Ladens.

Wird die Version ins System geladen, wird ein neues KI-Training notwendig werden. Bei setzen den bev-Flags auf jeden Fall.
Schauen wir mal wie FANN nun damit klar kommt...

LG,
Heiko

[DS_Starter]

@300P,

ja das klingt erstmal verführerisch. Herausforderung wird sein Zeitintegrale je Modus zu bilden. Denn die Lesezyklen im Modul sind nicht gleichmäßig wie wir wissen. Im ersten Meßintervall von 35 Sekunden wurden 35% Modulation zum Meßzeitpunkt registriert, dann nach 75 Sek der nächste Meßpunkt mit Modulation 50% usw.
Der Modulationsgrad bezieht sich sicherlich auf die Nominal-Leistung (power) die angegeben wird.

Wer keine modulierende WP hat, gibt dort einfach eine 100%=fester Wert an. 

Aber ja, das klingt nach einem Plan. Mal schauen.

LG,
Heiko

[300P]

Ja - die Modulation ist ,,grundsätzlich und eigentlich" nur auf die ,,power" des Kompressors bezogen.

Es gibt auch noch die Steuerungs- / Pumpen- und etc. .....verbräuche bei einer Wärmepumpen-Consumer-Verbrauchserfassung. Wir sollten es aber nicht zu komplex werden lassen....😉🥳😇

[DS_Starter]

Make it simple ... sofern man das überhapt noch sagen kann. 
Naja, für heute erstmal Feierabend ... angenehmes Schwitzen 

GN!

[klaus.schauer]

ja das klingt erstmal verführerisch. Herausforderung wird sein Zeitintegrale je Modus zu bilden. Denn die Lesezyklen im Modul sind nicht gleichmäßig wie wir wissen. Im ersten Meßintervall von 35 Sekunden wurden 35% Modulation zum Meßzeitpunkt registriert, dann nach 75 Sek der nächste Meßpunkt mit Modulation 50% usw.
Der Modulationsgrad bezieht sich sicherlich auf die Nominal-Leistung (power) die angegeben wird.

Wer keine modulierende WP hat, gibt dort einfach eine 100%=fester Wert an.

Entscheidend ist die Leistungsaufnahme des Verbrauchers. Die Kenntnis von stark schwankenden Modulationsdaten wird keinen zusätzlichen Lerneffekt haben.

[klaus.schauer]

Zusatzheizer verstehe ich nicht zu 100 %
Der Verbrauch der in der Wärmepumpe herstellerseits eingebauten E-Heater fällt immer in den entsprechenden Modus zusätzlich an.

Oder ist ein PV-Heater im WW-Speicher gemeint der separat nachtraglich eingebaut wurde ?

Die Wärmepumpe ist so ausgelegt, dass der Bivalenzpunkt der Bemessungsaußentempertur entspricht. D. h. die integrierte Zusatzheizung wird im Regelbetrieb nicht benötigt. Die Zusatzheizung schaltet sich nur ein, falls der Betriebsbereich des Kompressors temporär verlassen wird. Z. B. wenn Warmwasser auf 70 °C bei sehr hohen Außentemperaturen aufgeheizt werden muss (Legionellenprogramm).

Zudem kann man bei der Wärmepumpe die variable Leistung der Zusatzheizung getrennt abfragen. Also warum nicht auch auswerten?

[300P]

Ah - okay
Bei mir sind auch 3 x 3 kW herstellerseits installiert.

Am Anfang sind durch Fehleinstellungen 112 kWh verbraucht - inzwischen sind es 126 kWh geworden.

Also weniger als die Tiefkühltruhe 🥶 😇 in 12 Monaten bei uns.

Daher sehe ich das als nicht soooooo verfolgungswürdig an.....
Da müsste eher mein Eletrogrill oder Sauna / Klima / Spülmaschine / E-Herd und Ofen bei mir noch verbrauchsmäßig mit erfasst werden.😉🥳😇

[300P]

Entscheidend ist die Leistungsaufnahme des Verbrauchers. Die Kenntnis von stark schwankenden Modulationsdaten wird keinen zusätzlichen Lerneffekt haben

In dem Modulationswert ist - über den WP-Gesamtverbrauch des ConsumersXX - indirekt auch alles an Leistungsverbrauchern "versteckt" obwohl er "nur" den Kompressorstatus angibt.

Aber wenn genau sein soll/muss, dann ja, ist der Verbrauch der Komponente vom aktuellen Betriebsmodi und alles andere (z.B. Steuerungsverbauch/Pumpenverbrauch etc.) dann als zusätzlicher weiterer separater ConsumerXX-Verbauch maßgebend. (Ist das so genau gewollt?)
Dann ist / wird es kompliziert - dann muss auch bei jedem Modulnutzer auch vom aktuellen Betriebsmodi der separate Verbrauch (aus der Steuerung der WP) greifbar / verfügbar sein.

Bei mir kein Problem - habs verfügbar, aber wenn jemand "nur" per EM den Verbrauch der Gesamtanlage hat und/oder (herstellerabhängig) nicht per EMS/ModBus/APi darauf zurückgreifen kann ? (Solls nicht so selten geben )

[grappa24]

moin,
war jetzt über 2 Wochen weg, bei mir läuft die 2.7.0
BEV ja, WP nein
Was ist denn zu beachten beim Umstieg auf die neueste Contrib-Version?
Grüße, grappa24

[300P]

2.8.0 = BEV = https://forum.fhem.de/index.php?msg=1365549
2.7.0 = WP = https://forum.fhem.de/index.php?msg=1365437
Beides weiter "Datensammlung"

ABER etwas Veränderung bei einigen Parameter - System meldet sich dann......



PS:
Wetter gut im Urlaub ?

[DS_Starter]

Moin,

Entscheidend ist die Leistungsaufnahme des Verbrauchers. Die Kenntnis von stark schwankenden Modulationsdaten wird keinen zusätzlichen Lerneffekt haben.

Absolut. So war es auch nicht zu verstehen.
Die Auswertung des jeweiligen Modulationsgrades und Zuordnung an den aktiven Modus über ein Punktesystem lässt die Aufteilung der verbrauchten Consumerenergie auf die Modi genauer auswerten als stringent linear.

Aber wenn genau sein soll/muss, dann ja, ist der Verbrauch der Komponente vom aktuellen Betriebsmodi und alles andere (z.B. Steuerungsverbauch/Pumpenverbrauch etc.) dann als zusätzlicher weiterer separater ConsumerXX-Verbauch maßgebend. (Ist das so genau gewollt?)
Dann ist / wird es kompliziert - dann muss auch bei jedem Modulnutzer auch vom aktuellen Betriebsmodi der separate Verbrauch (aus der Steuerung der WP) greifbar / verfügbar sein.

Ja und nicht nur das. Sobald eine neue Energiemessungsinstanz eingeführt wird, wären auch alle internen Verwaltungsfunktionen bis hin zur Datenlöschung bei Abschaltung des Consumers zu implementieren. Sonderlocken muß ich bei der Komplexität des Moduls vermeiden. Die separate Energierverwaltung für jeden Modus (6) jeder WP (Gisbert hat 4) separat (ergibt 4 x 6 = 24 neue Energieinstanzen csmex_Modus) ist einfach too much für den Zweck.

 

[DS_Starter]

Hallo zusammen,

da im contrib aktuell die V 2.8.0 liegt, fasse ich alle wichtigen Änderungen seit der letzten offiziellen V 2.6.11 zusammen.
Es ist bereits viel zusammengekommen. Deswegen wird es ein bedeutendes Minor-Release:

- der von WDS gemeldete Boot-Fehler ist behoben (#6291)

- die Ausgaben bzw. Exporte der pvHistory können gefiltert werden

- Die Verbrauchsprognose FANN ist um weitere synthetische Features erweitert (bisher in sandbox zum Test enthalten)

- Codeverbesserungen in der Trainingslogik (Snap-Guard und Retrainidicator)

- Weiterentwickllung und Korrekturen im FANN Hinweissystem ("Berater" für die FANN-Einstellungen)

- das Reading Tomorrow_ConsumptionForecast ist entfernt (Tomorrow_CONforecast anstatt verwenden)

- Wichtig: Umstellung aiControl->aiConProfile auf Flags. Bei einer Neudefinition braucht man nur noch die Eigenschaften des
  Haushalts mit einfachen Flags wie pv,heatpump anzugeben. Das richtige Profil wird intern synthetisiert.
  Ihr braucht aber nichts anzupassen, die bisherigen Profile behalten ihre Gültigkeit bis zu einer Neueingabe.
 
- attr ConsumerX: Beim Ändern eines Consumers wird der Fingerprint identitätsbestimmender Schlüssel (type, switchdev, opmode)
  geprüft und ggf. das vorherige Löschen des Consumers und neu Anlegen requestet, z.B.:
 
  "Das Ändern des Geräts oder eines der identitätsbestimmenden Schlüssel (type, switchdev, opmode) eines bestehenden Verbrauchers
  ist nicht zulässig. Dies würde stillschweigend historische Daten (pvHistory) und bereits für 'consumer03' aufgezeichnete
  KI-Trainingsdaten beschädigen, da diese Daten nur anhand der Verbrauchernummer und nicht anhand der Geräteidentität indiziert sind.

  Bitte zunächst das Attribut 'consumer03' löschen (dadurch wird dessen Verlauf sicher entfernt) und erneut mit dem neuen Gerät bzw.
  den neuen Schlüsseln definieren. Die Verbrauchernummer kann unmittelbar danach wiederverwendet werden."
 
 
- in pvHistory und aiRawData werden nun die kumulativen Run-Minuten der Wärmepumpen-Modi
  getrennt nach Modus -> csmXX_(off|heating|defrost|hotwater|cooling|pool|poolheating)_minutes registriert und gespeichert.
  Dazu gibt es einen neuen Schlüssel aiControl->opmode für Consumer "heatpump"
  Hinweis: ähnlich wie bei BEV ist das nur erstmal eine Datensammlung. Effektiver Einbau in das KI-Training erfolgt später
          wenn wir bereits Daten gesammelt haben
         
- es können nun mehrere Consumer vom Typ "heatpump" erstellt werden

- die BEV-Integration für das KI-Training implementiert. Dazu setzt man in aiControl->aiConProfile das Flag "bev". Also zum Beispiel:

       aiConProfile=v1,active,pv,bev

- das von Wolle02 in #6362 bemängelte Verhalten des "Nachziehens" oder anders gesagt der "Selbstheilung" ist eleminiert.
  Dies hat nun Vor- und Nachteile. Nachteil ist, dass es wahrscheinlich höhere Abweichungen und Fehlerraten geben wird bei gleichzeitiger
  guter/sehr guter Visualisierung, je nachdem wieviel und wie gute Features der KI zur Verfügung stehen.
  Dieser Nachteil ist zugleich auch eine Stärke, das Lernen wird "ehrlicher", fehlende Feaures werden deutlicher und Verbesserungen/Einflüsse
  zusätzlich bereitgestellter Information werden direkt sichtbar.
  Der Nachzieheffekt ist beseitigt, die in einer Stunde festgestellten Abweichungen werden nicht mehr durch eine "Gegenbewegung" in der
  nächsten und weiteren Stunden ausgeglichen.



Durch ergänzende Features in der KI Verbrauchsprognose gibt es bei dieser Version Strukturänderungen.
Aus diesem Grund wird in den meisten Fällen ein Retraining erforderlich sein, bei Setzen des Flags "bev" auf jeden Fall.

LG,
Heiko