[seaspotter]

UI: openWB/openwb-ui-settings#1030

Sowohl IDM als auch Lambda Wärmepumpen unterstützen kein power_limit, da es dort keine Lastvorgabe gibt. Aber sie unterstützen die Eigenregelung wenn man die Systemwerte wie PV, Hausverbrauch, Netz EVU Punkt etc. übergibt, dass sie in Eigenregelung gehen.

Zusätzlich OVUM Wärmepumpe hinzugefügt, die unterstützt power_limit.

[benderl]

Wäre es bei Lambda nicht sinnvoller, einfach die aktuelle EVU-Leistung zu übergeben, anstatt im Modul einen Überschuss zu berechnen? So läuft es zumindest in dem alten SmartHome seit Jahren zuverlässig.

Das Vorzeichen muss nicht umgedreht werden, da die Lambda beide Optionen bietet. Das wird auch beim Energiemanager eingestellt, wo man die Modbus Slave Funktion aktiviert.

Ein Clamping auf Werte größer "0" ist meines Erachtens auch nicht nötig. Zumindest macht das alte SmartHome dies nicht und es funktioniert.

Übersehe ich hier etwas?

[EDIT]
Ja, habe etwas übersehen. Das war bereits vorher im Modul so umgesetzt. Kannst Du das bei der Gelegenheit bereinigen?

[seaspotter]

Danke @benderl hab aus der Doku nur rausgelesen, dass ein Überschuss erwartet wird, die EVU Leistung hab ich ja dafür schon hergenommen, nur noch limitiert. Sollte so wieder dem entsprechend wie es war, nur das es eben nicht als power_limit ist, weil es keine Leistungsvorgabe für die WP ist.

[benderl]

Die Methoden send_values() übermitteln bei beiden Geräten die EVU-Leistung.
Es würde Sinn machen, im kompletten PR send_values bzw. "sendValues" durch eine etwas aussagekräftigere Bezeichnung zu ersetzen. send_grid_power()/sendGridPower?

[seaspotter]

@benderl ich hatte es erst send_grid_values genannt, allerdings wird nicht nur die evu Power sondern bei IDM auch bat_power, pv_power, bat_soc geschickt. Dann ist das nicht ganz richtig weil nicht nur grid geschickt wird? Aber wenn's ne bessere Benennung gibt, nehm ich die gerne auf.

[benderl]

Stimmt, IDM hatte ich übersehen. Es spricht aber auch nichts dagegen, wenn es bei IDM bei sendValues bleibt und bei Lambda/OVUM sendGridPower heißt. Die Methoden werden nur innerhalb der jeweiligen Methode create_consumer() verwendet, werden nicht vom Core genutzt.

[seaspotter]

Dann spricht aber eher alles dafür es so zu lassen und konsistent über verschiedene Module gleich zu benennen meiner Meinung nach.
Ist ja nicht ausgeschlossen das weitere Module zukünftig dazu kommen die vllt nur den Überschuss oder die PV Leistung gesendet habe wollen.

[benderl]

So unterschiedlich können die Meinungen dazu sein.
Gerade weil es nicht konsistent ist, müssen auch die Bezeichnungen nicht zwingend konsistent sein. Ich erkenne lieber gleich anhand der Bezeichnung, was die Methode macht.

@LKuemmel
Wie stehst Du dazu?

[LKuemmel]

Sollte so wieder dem entsprechend wie es war, nur das es eben nicht als power_limit ist, weil es keine Leistungsvorgabe für die WP ist.

Warum ist das keine Leistungsvorgabe?

Die send_values-Methode übergibt die Leistungen von EVU, WR und Speicher sowie Speicher-SoC an die Wärmepumpe und diese regelt dann nach ihrem Regelalgorithmus. Damit werden sämtliche Einstellungen der Verbraucher-Steuerung überschrieben.

Im idm-Modul ist ein kurzer Kommentar dazu drin, nicht ganz ausformuliert.

    # braucht man Reg 78? der Wärmepumpe kann es doch egal sein, wie viel PV-Leistung vom Dach kommt,

    # vlt soll die anderweitig genutzt werden

Wenn der Strompreis nachts günstig ist, soll die Wärmepumpe mit höherer Leistung laufen. Übergibt man ihr sämtliche System-Leistungen, sagt die Wärmepumpe, kein Überschuss da, ich laufe so wenig wie nötig. Der Eco-Modus funktioniert nicht. Übergeben wir die gewünschte Leistung als EVU-Überschuss, sollte die Wärmepumpe mit höherer Leistung laufen. So habe ich die Idee von okaegi aus dem alten Smarthome aufgefasst.

[seaspotter]

@LKuemmel das ist die alte Idee, führt aber zu diversen Problemen, weil IDM auch eine komplette eigene Statistik des Verbrauchs und Erzeugung führt und zusätzlich eine eigene dynamische Strompreisregelung hat.
Ich hab selbst eine IDM hier und das Vorgehen aus dem alten Smarthome hat da aben genau diese Probleme. Die IDM will die korrekten Werte habe um ihre eigene Regelung umzusetzen. Schicke ich nachts einen Überschuss der gar keine ist, verfälscht das jegliche Statistiken innerhalb der IDM und ein Register für eine konkrete Leistungsvorgabe gibt es nicht, hat ja btw keine Wärmepumpe außer die OVUM die ich hinzugefügt habe. In meinen Augen ist der einzige sinnvolle Weg bei IDM und auch alle anderen WP die Werte zu übergeben die sie wollen und ohne power_limit zu arbeiten, nur wenn eine externe Leistungsvorgabe wirklich möglich ist, weil power_limit übergibt ja auch nicht den Überschuss sondern nur eine bestimmt verfügbare Leistung wie bei der Batterie.

[LKuemmel]

Ok, ich sehe deinen Punkt.
Das sollte dann besser über den Verwendungstyp abgebildet werden. ZB einen separaten Verwendungstyp für Wärmepumpen. Wir diskutieren das intern. Ich gebe Dir dann nochmal Rückmeldung.

[LKuemmel]

Ich habe noch einen Verwendungstyp "Wärmepumpe in Eigensteuerung" bzw ConsumerUsage.SELF_CONTROLLED hinzugefügthttps: #3775 In den examples und im MQTT-Verbraucher gibt es eine send_values-Methode.
Wenn man möchte, dass die Wärmepumpe durch die openWB gesteuert wird, kann man SUSPENDABLE_TUNABLE auswählen, dann werden die manipulierten Werte geschickt oder man kann es durch die Wärempumpe selbst steuern lassen und muss dann dort weitere Einstellungen zur Regelung vornehmen. So kann man den alten Usage-Case abdecken und zukünftig auch die Steuerung der WP überlassen.

Leider habe ich beim Holen der Änderungen vom Master deinen PR etwas zerschossen. Am besten machst Du ein git reset --hard auf feature_consumer und holst deine Änderungen dann mit git cherry-pick wieder rein.

[seaspotter]

@LKuemmel Danke für den neuen Verwendungstyp, das trifft die Sache genau – hab IDM und Lambda jetzt darauf umgestellt (SELF_CONTROLLED), die eigene Überschussberechnung fällt damit komplett weg, send_values() bekommt die Werte jetzt sauber über CurrentValues.

Eine Frage bleibt aber offen: Sollen IDM und Lambda dann auch SUSPENDABLE_TUNABLE als Option bekommen um da einen manipuliereten Wert vorzugeben wie es im alten Smarthome war? Persönlich find ich es jetzt nicht so toll, aber wenn ihr das so wollt bzw. User so wollen? Oder wollt ihr das nochmal besprechen? Es ist halt keine echte Leistungsvorgabe wie bei OVUM. Ich habs jetzt aktuell mal raus gelassen bei Lambda und IDM.
OVUM hingegen hat sogar mehrere Optionen, vllt kannst du da nochmal auch explizit drüberschauen was das power_limit angeht, ob so ok.

Die Pytest fehler kommen nicht von meinen Änderungen, da musst du vllt auch nochmal schauen.

Danke :)

[LKuemmel]

SUSPENDABLE_TUNABLE soll als Option drin bleiben, damit man es so wie im alten Smarthome nutzen kann und alles über die openWB steuern kann.
Die pytests laufen jetzt alle, da müsstest Du Dir bitte nochmal die Änderungen aus feature_consumer holen.

OVUM schaue ich mir noch an.

[seaspotter]

Sollte jetzt soweit passen denke ich