THZ Tecalor (LWZ Stiebel Eltron) Wärmepumpe -Optimierung und Erfahrungsaustausch

[sunrise]

Was passiert eigentlich bei diesem u.a. Codes, wenn die Übertragung (set/get) fehlschlägt? Besteht da nicht die Gefahr, dass etwas falsch gesetzt wird?

Code Auswählen Erweitern

defmod Mythz.preventHCcancelDuringReset at *09:59:25 \


[Eonwe]

Das ist normal, siehe auch:

Alles klar danke.
Mich hat nur irritiert, dass das nicht jeden Tag auftritt. Auch wenn ich den Zeitpunkt für den Rücklauf messtechnisch verpasse, die Änderung im Warmwasser müsste trotzdem sichtbar sein. Und das ist sie nicht.

[sunrise]

Ich krame das nochmal hervor:

So, hier nochmal ein paar Codeschnipsel, nachdem ich ein paar kleinere kosmetische Korrekturen vorgenommen habe...

Verhindern eines Heizzyklus-Abbruch wg. vollem WW-Speicher bzw. Verhindern eines Heizzyklus-Starts wg. leerem WW-Speicher beim täglichen Reset (Temperaturen müsst ihr ggf. anpassen, bei mir funktioniert's so):

Code Auswählen Erweitern

defmod Mythz.preventHCcancelDuringReset at *09:59:25 \
IF (([Mythz:HeatingHC] == 1) && ([Mythz:integral] < ([Mythz:p30integralComponent:d]/4*3)) && ([Mythz:dhw_temp] > 40)) \
( \
 get Mythz p01RoomTempDayHC1,\
 get Mythz p02RoomTempNightHC1,\
 setreading Mythz.preventHCcancelDuringReset p01RoomTempDayHC1 {([Mythz:p01RoomTempDayHC1:d])},\
 setreading Mythz.preventHCcancelDuringReset p02RoomTempNightHC1 {([Mythz:p02RoomTempNightHC1:d])},\
 set Mythz p01RoomTempDayHC1 27,\
 set Mythz p02RoomTempNightHC1 27,\
 sleep 180 quiet,\
 set Mythz p01RoomTempDayHC1 {([Mythz.preventHCcancelDuringReset:p01RoomTempDayHC1:d])},\
 set Mythz p02RoomTempNightHC1 {([Mythz.preventHCcancelDuringReset:p02RoomTempNightHC1:d])} \
) \
ELSE \
( \
 IF (([Mythz:HeatingHC] == 0) && ([Mythz:HeatingDHW] == 0) && ([Mythz:PumpHC] == 1) && ([Mythz:Defrost] == 0) && ([Mythz:dhw_temp] < 38)) \
 ( \
 get Mythz p01RoomTempDayHC1,\
 get Mythz p02RoomTempNightHC1,\
 setreading Mythz.preventHCcancelDuringReset p01RoomTempDayHC1 {([Mythz:p01RoomTempDayHC1:d])},\
 setreading Mythz.preventHCcancelDuringReset p02RoomTempNightHC1 {([Mythz:p02RoomTempNightHC1:d])},\
 set Mythz p01RoomTempDayHC1 15,\
 set Mythz p02RoomTempNightHC1 15,\
 sleep 180 quiet,\
 set Mythz p01RoomTempDayHC1 {([Mythz.preventHCcancelDuringReset:p01RoomTempDayHC1:d])},\
 set Mythz p02RoomTempNightHC1 {([Mythz.preventHCcancelDuringReset:p02RoomTempNightHC1:d])} \
 ) \
)

Was passiert eigentlich bei diesem u.a. Codes, wenn die Übertragung (set/get) fehlschlägt? Besteht da nicht die Gefahr, dass etwas falsch gesetzt wird?


Und hierzu noch eine Frage:

Noch alle meine Userreadings, damit sollte es laufen:

Code Auswählen Erweitern

Zuluft:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[55]*4},\
Abluft:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[53]*4}, \

Gibt's einen speziellen Grund, weshalb Du die mit 4 multiplizierst? Geht's dabei nur um eine bessere Darstellung im Plot? Für letzteres kann man statt der Multiplikationen weitere (beliebig viele) Y-Achsen verwenden (im Plot-Editor sind nur 2 möglich, daher dann per File-Edit) und hat dafür dann immer noch die korrekten Werte in diese Readings. Falls die Multiplikation mit 4 andere Gründe hat, wäre ich interessiert, davon zu erfahren.

[TheTrumpeter]

Mich hat nur irritiert, dass das nicht jeden Tag auftritt. Auch wenn ich den Zeitpunkt für den Rücklauf messtechnisch verpasse, die Änderung im Warmwasser müsste trotzdem sichtbar sein. Und das ist sie nicht.

Ich denke, dass die Voraussetzungen jeden Tag etwas unterschiedlich sind, sodass sich der Reset nicht immer ,,sichtbar" auf die Temperatur beim Speicherfühler auswirkt.
Letztendlich findet durch den kurzen Pumpenzyklus ein Wärmeaustausch des Wassers im Speicher mit dem Wasserkreislauf in der LWZ statt.

Was passiert eigentlich bei diesem u.a. Codes, wenn die Übertragung (set/get) fehlschlägt? Besteht da nicht die Gefahr, dass etwas falsch gesetzt wird?

Genau.

Gibt's einen speziellen Grund, weshalb Du die mit 4 multiplizierst? Geht's dabei nur um eine bessere Darstellung im Plot? Für letzteres kann man statt der Multiplikationen weitere (beliebig viele) Y-Achsen verwenden (im Plot-Editor sind nur 2 möglich, daher dann per File-Edit) und hat dafür dann immer noch die korrekten Werte in diese Readings. Falls die Multiplikation mit 4 andere Gründe hat, wäre ich interessiert, davon zu erfahren.

SE hat entschieden, den Sollwert anstatt in m3/h in ,,sGlobal" in Prozent anzugeben, wobei sie bei der 40x 400 m3/h als 100% definiert haben. Damit ich mit m3/h rechnen kann, konvertiere ich die Darstellung.

[bvlgari_do]

Problem 1: Für mich sieht es zunächst nach einem kaputten Umschaltventil  Weil, wenn ich die Werte richtig interpretiere, steigt während einer WW-Aufbereitung auch die Vorlauftemperatur und zwar außerhalb des Wertes den ich per MAX. VORLAUFTEMP 40°C gesetzt habe. Dazu spricht auch der sehr hohe (über 30l/min) Volumenstrom zur Zeit der WW-Aufbereitung.

Die Vorlauftemperatur MUSS steigen bei WW. Die Wärme wird dann halt per Umschaltventil ins Warmwasser umgeleitet, statt in die FBH. der höhere Volumenstrom bei WW ist normal, damit das WW schnell geht.

Ich glaube, es wird doch was mit Umschaltventil sein. Weil, es geht nicht nur um eine zu hohe T für VL, sondern auch HK1_IST und RL-T sind sehr hoch, fast 60°C Aber wieso fällt die HK1-IST dann wieder so schnell ab wenn es am Umschaltventil liegen soll?

Kurz vor der WW_Aufbereitung:
11:43
WW IST = 25,2°C
HK1 IST = 21,4°C
VL IST = 26,8°C

WW_Beginn:
11:48
WW IST = 25,4°C
HK1 IST = 25,9°C
VL IST = 28,0°C

Kurz vor Ende WW-Auafbereitung:
13:33
WW IST = 59,6°C
HK1 IST = 62,8°C
VL IST = 62,3°C

Kurz nach Ende WW-Aufbereitung:
13:38
WW IST = 59,9°C
HK1 IST = 31,7°C
VL IST = 30,2°C

[Eonwe]

HK1_ist berechnet sich nach deiner Vorgabe (Prozent Vorlauf) aus Vorlauf und Rücklauftemperatur.
Was passiert denn genau bei der Warmwasserbereitung? Das Umschaltventil schaltet von Heizung auf WW-Speicher. HK1 soll jetzt den Speicher erwärmen. Dabei fließt das Wasser von HK1 durch einen Wärmetauscher und erhitzt so das Wasser im Speicher.
Die Messwerte beziehen sich immer noch auf HK1, der ist aber momentan umgeleitet auf den WW-Speicher. Um das Wasser im Speicher zu erwärmen, muss aber der Vorlauf wärmer sein als der Speicher. Gleichzeitig kann der Rücklauf nie kälter sein als der Speicher. Das erklärt die (vermeintlich zu) hohen Temperaturen.
Am Ende der Warmwasserbereitung schaltet das Ventil wieder auf Heizung um und die Heizkreispumpe läuft noch etwas nach, um die Restwärme aus HK1 in den Fußboden zu befördern. Daher der schnelle Abfall.
Schau dir mal den Plot im Anhang an, da sind auch 2 Warmwasserzyklen drauf, die genauso aussehen wie bei dir. Bei mir sind Rücklauf und HC1_ist identisch, weil meine Anlage 100% rücklaufgesteuert arbeitet.

Für mich sieht dein Plot absolut in Ordnung aus.

[sunrise]

@TheTrumpeter
Da könnte es Sinn machen, nach dem Set mit einem Get zu prüfen, ob der Wert korrekt gesetzt wurde und falls nicht, es nochmal zu versuchen.

[TheTrumpeter]

@TheTrumpeter
Da könnte es Sinn machen, nach dem Set mit einem Get zu prüfen, ob der Wert korrekt gesetzt wurde und falls nicht, es nochmal zu versuchen.

Klar, kannst Du gerne so erweitern.
Für mich reicht es, weil ich 1. nie Übertragungsfehler beobachte und 2. falsche Parameter recht schnell erkennen würde. 3. initialisiere ich beim FHEM-Start alle Parameter mit den "richtigen" Werten, damit ein FHEM-Absturz während des "sleep" auch ausgebügelt würde.

[bvlgari_do]

HK1_ist berechnet sich nach deiner Vorgabe (Prozent Vorlauf) aus Vorlauf und Rücklauftemperatur.
Was passiert denn genau bei der Warmwasserbereitung? Das Umschaltventil schaltet von Heizung auf WW-Speicher. HK1 soll jetzt den Speicher erwärmen. Dabei fließt das Wasser von HK1 durch einen Wärmetauscher und erhitzt so das Wasser im Speicher.
Die Messwerte beziehen sich immer noch auf HK1, der ist aber momentan umgeleitet auf den WW-Speicher. Um das Wasser im Speicher zu erwärmen, muss aber der Vorlauf wärmer sein als der Speicher. Gleichzeitig kann der Rücklauf nie kälter sein als der Speicher. Das erklärt die (vermeintlich zu) hohen Temperaturen.
Am Ende der Warmwasserbereitung schaltet das Ventil wieder auf Heizung um und die Heizkreispumpe läuft noch etwas nach, um die Restwärme aus HK1 in den Fußboden zu befördern. Daher der schnelle Abfall.
Schau dir mal den Plot im Anhang an, da sind auch 2 Warmwasserzyklen drauf, die genauso aussehen wie bei dir. Bei mir sind Rücklauf und HC1_ist identisch, weil meine Anlage 100% rücklaufgesteuert arbeitet.

Für mich sieht dein Plot absolut in Ordnung aus.

Vielen Dank für deine Antwort. Das beruhigt Bei mir war der Gedanke, HK1 ist was exklusives fürs Heizen. WW-Aufbereitung hat eigene "Wege" dachte ich. Aber dass der HK nur umgeleitet wird, war mir nicht klar, aber freut mich zu hören.

Habe keinen Bock auf einen kaputten Umschaltventil. Vor 3 Monaten habe ich die beiden Lüfter getauscht - 750€ 

[willybauss]

HK1_ist berechnet sich nach deiner Vorgabe (Prozent Vorlauf) aus Vorlauf und Rücklauftemperatur....

So hätte ich es jetzt auch vermutet, obwohl ich keine Anlage mit Umschaltventil besitze. Wenn Du's genau wissen willst, miss einfach mal während der WW-Bereitung oberhalb der Anlage am Ausgang für die FBH nach, welche Temperatur das Rohr da hat.

RL-T zitierst Du zwar im Text als sehr hoch, im Bild ist davon aber nichts zu sehen. Wenn das Wasser wirklich mit 60°C aus der FBH käme, dann würde Deine Bude vor Wärme explodieren.

[sunrise]

Ist es eigentlich möglich, einer THZ 403 SOL aus 2008 mit Firmware 2.16 seitens SE eine Firmware 4.39 oder neuer spendieren zu lassen? Wäre dafür auch ein neues Board nötig? Hat jemand von Euch schon einmal ein THZ/LWZ Fimware-Update bekommen?

[sunrise]

3. initialisiere ich beim FHEM-Start alle Parameter mit den "richtigen" Werten, damit ein FHEM-Absturz während des "sleep" auch ausgebügelt würde.

Wie machst Du das? Via 99_myUtils.pm? Hast Du evtl. einen Code-Schnipsel dafür?


Falls übrigens jemand Daten zwischen FHEM und Home Assistant (HA) austauschen möchte, geht das via Notify, aber auch via MQTT_GENERIC_BRIDGE. Entsprechend habe ich mir UserReadings angelegt - ganz schlicht, z.B.:

Code Auswählen Erweitern

attr Mythz userReadings \
outsideTemp:sGlobal.* {((split ' ',ReadingsVal("Mythz","sGlobal",0))[1])}, \
flowTemp:sGlobal.* {((split ' ',ReadingsVal("Mythz","sGlobal",0))[3])}, \
returnTemp:sGlobal.* {((split ' ',ReadingsVal("Mythz","sGlobal",0))[5])}, \
...
Auf HA-Seite benötige ich passend zum o.g Bsp. nur das in der configuration.yaml:

Code Auswählen Erweitern

mqtt:
  sensor:
    - name: Mythz_outsideTemp
      state_topic: "fhem/Mythz/outsideTemp"     
    - name: Mythz_flowTemp
      state_topic: "fhem/Mythz/flowTemp"
    - name: Mythz_returnTemp
      state_topic: "fhem/Mythz/returnTemp"

Das Ergebnis (Android HA App) sieht dann so aus:

Du darfst diesen Dateianhang nicht ansehen.

(https://forum.fhem.de/index.php?msg=1295901)

[TheTrumpeter]

3. initialisiere ich beim FHEM-Start alle Parameter mit den "richtigen" Werten, damit ein FHEM-Absturz während des "sleep" auch ausgebügelt würde.

Wie machst Du das? Via 99_myUtils.pm? Hast Du evtl. einen Code-Schnipsel dafür?

Da ist es gut beschrieben: https://www.computerhilfen.de/info/fhem-aktion-beim-systemstart-ausfuehren.html
Was Du da dann rein packst obliegt Deiner Phantasie...

[TheTrumpeter]

HK1_ist berechnet sich nach deiner Vorgabe (Prozent Vorlauf) aus Vorlauf und Rücklauftemperatur....

So hätte ich es jetzt auch vermutet, obwohl ich keine Anlage mit Umschaltventil besitze. Wenn Du's genau wissen willst, miss einfach mal während der WW-Bereitung oberhalb der Anlage am Ausgang für die FBH nach, welche Temperatur das Rohr da hat.

Genau so ist es, siehe Plot anbei. Die Magenta-Punkte sind vom externen Temperaturfühler am Vorlauf außerhalb der LWZ.

[bvlgari_do]

So, Raspberry habe ich bekommen. Jetzt warte ich nur noch auf einen Serial-Stecker um endlich mal auch FHEM installieren/konfigurieren zu können.

Währenddessen läuft mein JAVA-ISG-Parser fleißig weiter  und ich hätte aktuell noch folgende Frage. Ich verstehe nicht, wie kann die Heizung unter gleichen Bedingungen (ähnliche Aussentemperatur) und gleichen Einstellungen der THZ so unterschiedlich Verbräuche am Heizstrom haben. Klar, es liegt am Ende an der VL-Temperatur, aber wieso ist die unter fast gleichen Bedingungen so unterschiedlich (hoch/niedrig)? Wieso steigt die am Donnerstag um 00:22 von 25°C auf über 30°C und bleibt dann durchgehend auf diesem Level?

Man sieht auf den Bildern, am Dienstag wurde in der Zeit gar nicht geheizt, am Donnerstag durchgehend ab 00:22.

Betrachten wir nur den Zeitraum von 00:00 - 06:00. Da hatte ich am Dienstag nur 2,4kWh, am Donnerstag in der gleichen Zeit fast 12kWh.

Und das habe ich oft, ist keine Ausnahme.