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

Begonnen von willybauss, 07 Februar 2015, 11:30:16

Vorheriges Thema - Nächstes Thema

TheTrumpeter

Zitat von: willybauss am 28 Februar 2017, 18:50:36
@Trumpeter:
Hast Du zwei Pumpen für Heizkreis und Warmwasser, oder nur eine für beides zusammen?
Gute Frage...
Finde ich das irgendwie raus ohne die Anlage zu zerlegen?

Bisher bin ich davon ausgegangen, nur 1 Pumpe zu haben, auch wenn in den Readings zwei auftauchen.

EDIT: Müsste nach Schaltplan-Studium eigentlich zu beantworten sein... mal sehen ob ich das noch schnell mache...
EDIT2: Lt. Schaltplan gibt es nur 1 Umwälzpumpe (M2 Motor Umwälzpumpe) sowie 1 Umschaltventil (M3 Motor Umschaltventil (Heizen/WWB)).
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

willybauss

Bei der 303 sind die Pumpen in der Installationsanleitung beschrieben. Dort muss nämlich bei der Inbetriebnahme die Pumpenleistung an den Drehreglern eingestellt werden.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

TheTrumpeter

Da ist auch textuell immer nur von einer Pumpe die Rede... und da auch im Schaltplan nur eine Pumpe eingezeichnet ist, wird es wohl nur eine geben.

Hat sich hier vor längerem nicht auch mal jemand beschwert, dass man die Anlage keinen "automatischen Notfallmodus" hat, in dem Heizung und Warmwasser im Fehlerfall der Wärmepumpe über die Nachbrenner laufen?
Die x04SOL kann das, ist über den Parameter "Notbetrieb Auto" einstellbar. Dort kann man die Funktion abschalten, nur für Warmwasser oder für Warmwasser und Heizen aktivieren.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

So, hier nochmal der funktionierende Code für die myUtils...
Alle Syntaxfehler und sonstige Probleme (z.B. Min-Temperatur 14°C in FHEM statt 10°C lt. Manual) sind nun behoben.
Ausständig ist nur noch der Test, ob die Wartezeiten zwischen den Parameteränderungen zum Beenden und Starten der Warmwasserbereitung ausreichen.
(Wollte ich heute eigentlich machen, aber bis die ganzen anderen Fehler behoben waren, hatte ich schon 50°C  :-[)

##############################################
############## klemmendes Umschaltventil erkennen und reagieren ###############
# liest alle Warmwassertemperaturen aus und versucht durch mehrmaliges Ein- und Ausschalten der Warmwasserbereitung das Umschaltventil wieder gängig zu machen
# benötigt externe Vorlauftemperatursensor
# HINWEIS: beendet bei anhaltender Störung die Warmwasserbereitung vor der erlaubten Max-Zeit p36 (Max. Dauer WW-Erzeug.). Daher kommt es zu keinem Fehlerspeichereintrag!!!

sub Umschaltventil_klemmt
{
my $startdate = localtime;

# sichere aktuelle Parameter
my $p99HC1maxFlowTemp = ReadingsNum("Mythz","p99HC1maxFlowTemp","65");
my $current_p04 = ReadingsNum("Mythz","p04DHWsetDayTemp","45");
my $current_p05 = ReadingsNum("Mythz","p05DHWsetNightTemp","45");
my $current_p06 = ReadingsNum("Mythz","p06DHWsetStandbyTemp","45");
my $current_p11 = ReadingsNum("Mythz","p11DHWsetManualTemp","45");

# betätige 3x das Umschaltventil durch Ein- und Ausschalten der Warmwasserbereitung
for (my $i = 0; $i < 3; $i++)
{
# lese aktuellen Betriebszustand
fhem("get ADC.CH5678 4");
fhem("get Mythz sDHW"); sleep(0.25);
fhem("get Mythz sDisplay"); sleep(0.25);
fhem("get Mythz sGlobal"); sleep(0.25);
fhem("get Mythz sHC1"); sleep(0.25);
fhem("get Mythz sHistory"); sleep(0.25);
fhem("get Mythz sLast10errors"); sleep(0.25);

# setze Warmwassertemperaturen auf Minimum (14°C)
if ($current_p04 > 14) {fhem("set Mythz p04DHWsetDayTemp 14"); sleep(0.25);}
if ($current_p05 > 14) {fhem("set Mythz p05DHWsetNightTemp 14"); sleep(0.25);}
if ($current_p06 > 14) {fhem("set Mythz p06DHWsetStandbyTemp 14"); sleep(0.25);}
if ($current_p11 > 14) {fhem("set Mythz p11DHWsetManualTemp 14"); sleep(0.25);}

# warte bis Warmwasserbereitung aufhört, damit Umschaltventil angesteuert wird
sleep(60);

# lese aktuellen Betriebszustand
fhem("get ADC.CH5678 4");
fhem("get Mythz sDHW"); sleep(0.25);
fhem("get Mythz sDisplay"); sleep(0.25);
fhem("get Mythz sGlobal"); sleep(0.25);
fhem("get Mythz sHC1"); sleep(0.25);
fhem("get Mythz sHistory"); sleep(0.25);
fhem("get Mythz sLast10errors"); sleep(0.25);

# setze Warmwassertemperaturen auf Ausgangswerte zurück
if ($current_p04 > 14) {fhem("set Mythz p04DHWsetDayTemp $current_p04"); sleep(0.25);}
if ($current_p05 > 14) {fhem("set Mythz p05DHWsetNightTemp $current_p05"); sleep(0.25);}
if ($current_p06 > 14) {fhem("set Mythz p06DHWsetStandbyTemp $current_p06"); sleep(0.25);}
if ($current_p11 > 14) {fhem("set Mythz p11DHWsetManualTemp $current_p11"); sleep(0.25);}

# warte bis Warmwasserbereitung startet, damit Umschaltventil angesteuert wird
sleep(60);
}

# lese aktuellen Betriebszustand
fhem("get ADC.CH5678 4");
fhem("get Mythz sDHW"); sleep(0.25);
fhem("get Mythz sDisplay"); sleep(0.25);
fhem("get Mythz sGlobal"); sleep(0.25);
fhem("get Mythz sHC1"); sleep(0.25);
fhem("get Mythz sHistory"); sleep(0.25);
fhem("get Mythz sLast10errors"); sleep(0.25);

# warte 5min vor erneuter Prüfung der Vorlauftemperatur
sleep(300);

# lese aktuellen Betriebszustand
fhem("get ADC.CH5678 4");
fhem("get Mythz sDHW"); sleep(0.25);
fhem("get Mythz sDisplay"); sleep(0.25);
fhem("get Mythz sGlobal"); sleep(0.25);
fhem("get Mythz sHC1"); sleep(0.25);
fhem("get Mythz sHistory"); sleep(0.25);
fhem("get Mythz sLast10errors"); sleep(0.25);

my $endate = localtime;

if (ReadingsNum("Mythz","Vorlauftemperatur_extern","10") < $p99HC1maxFlowTemp)
{
# sende eMail über behobene Störung
DebianMail('dummy@web.de','LWZ404 Mythz Info - Umschaltventil','Klemmendes Umschaltventil erkannt am ' .$startdate .' und behoben am ' . $endate .'!','');

# setze UserReading zurück
fhem("setreading Mythz Umschaltventil_klemmt 0")
}
else
{
# setze alle Warmwassertemperaturen auf Minimum (14°C), damit keine Warmwasserbereitung mehr stattfindet.
if ($current_p04 > 14) {fhem("set Mythz p04DHWsetDayTemp 14"); sleep(0.25);}
if ($current_p05 > 14) {fhem("set Mythz p05DHWsetNightTemp 14"); sleep(0.25);}
if ($current_p06 > 14) {fhem("set Mythz p06DHWsetStandbyTemp 14"); sleep(0.25);}
if ($current_p11 > 14) {fhem("set Mythz p11DHWsetManualTemp 14"); sleep(0.25);}

# sende eMail über anhaltende Störung
DebianMail('dummy@web.de','LWZ404 Mythz Alarm - Umschaltventil','Klemmendes Umschaltventil erkannt am $startdate, KONNTE NICHT BEHOBEN WERDEN, Warmwassertemperaturen auf 14°C gesetzt!!!','');
}

}


Was mich dabei am Meisten stört, ist, dass FHEM während der Zeit der Modulausführung nichts tut, weshalb ich beispielsweise den ADC explizit triggern muss, um die externe Vorlauftemperatur zu erhalten...

Kann man das ändern, indem man beispielsweise explizite "Wartepunkte" o.ä. einbaut?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

maximalz

Kannst du evtl. in deinem Modul programmatisch irgend welche AT Befehle triggern, die dann zu einer bestimmten Zeit (+ x min.) dann wieder eine Funktion aufrufen, damit die Kontrolle zwischendurch wieder an Fhem zurück geht?
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

TheTrumpeter

Du meinst ich soll das Modul in mehrere Teile zerschneiden und die langen "sleep"-Zeiten durch "at"-Befehle ersetzen?
(Also beispielsweise ein Teilmodul endet vor dem ersten "sleep(60)" und definiert als letzten Befehl noch ein "at", das in 60 Sekunden startet & dann das nächste Teilmodul aufruft?)

Daran habe ich auch schon gedacht, verkompliziert den Ablauf aber natürlich deutlich.
Im Normalfall sollte das Modul ja ohnehin nie aufgerufen werden. Wenn doch, läuft es nach aktueller Definition ca. 11min. Dass FHEM in der Zeit "blind" ist, könnte ich verschmerzen, wenn es keine einfache Lösung gibt.
(Im schlimmsten Fall geht mir dadurch das Auslesen der Tages- oder Monatsverbräuche um Mitternacht verloren, viel mehr kann nicht passieren.)

Ich könnte die Wartezeiten zwischen den WW-Parameteränderungen möglicherweise noch verkürzen. Dazu muss ich in den nächsten Tagen mal ausprobieren, wie lange es nach der Parameteränderung wirklich dauert, bis das Umschaltventil angesteuert wird.
Die 5min vor dem erneuten Vorlauftemperaturvergleich möchte ich nicht verkürzen, da mir dazu absolut die Erfahrung fehlt. Keine Ahnung wie lange es dauert, bis die Temperatur wieder sinkt. Wenn das Klemmen des Umschaltventils durch das Modul behoben wurde, steht dann das warme Wasser ja dort in der Leitung. Andererseits, so wie der Trigger (notify) definiert ist, löst er sofort bei der Temperaturüberschreitung aus. Ein Absinken unter die Schwelle sollte dann recht schnell gehen, weil die Temperatur ja nur geringfügig fallen muss.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

maximalz

Naja, ich kenne mich mit FHEM selbst jetzt nicht so aus, aber generell hat man ja bei blockierenden Callbacks, wie Deinem Modul, das Problem, dass der Aufrufer blockert, sofern er den Aufruf nicht in einem neuen Thread oder Prozess absetzt (k.A. ob Perl / FHEM das kann).
Ansonsten eine andere Idee: Bei meiner 403 kann man die "Bestandteile" (Pumpen, Mischer etc.) einzeln über das Bedienteil ansteuern, wenn man einen Code eingibt. Eventuell kann man ja diese Ansteuerung auch über das THZ-Modul machen, ohne dass die Anlage einen Code abfragt. Der steckt vermutlich nur im Display.
Wenn Du dann Dein Ventil direkt steuern könntest, würde das die Zeiten ja erheblich verkürzen.
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

immi

Zitat von: TheTrumpeter am 06 März 2017, 17:24:59
So, hier nochmal der funktionierende Code für die myUtils...
Alle Syntaxfehler und sonstige Probleme (z.B. Min-Temperatur 14°C in FHEM statt 10°C lt. Manual) sind nun behoben.
Ausständig ist nur noch der Test, ob die Wartezeiten zwischen den Parameteränderungen zum Beenden und Starten der Warmwasserbereitung ausreichen.
(Wollte ich heute eigentlich machen, aber bis die ganzen anderen Fehler behoben waren, hatte ich schon 50°C  :-[)
I am not sure if I understood correctly: you want to manually switch off DHW for a short period.
Maybe you can go directly on the hardware: the following registers (in line 288) activate and deactivate the pumps. There must be one also for the  compressor or for other low-level functions.
Use them carefully

my %sets439technician =(
#  "zResetLast10errors"         => {cmd2=>"D1",     argMin =>   "0", argMax =>  "0",   type =>"0clean",  unit =>""},
  "zPumpHC"            => {cmd2=>"0A0052", argMin =>   "0", argMax =>  "1",   type =>"0clean",  unit =>""}, 
  "zPumpDHW"            => {cmd2=>"0A0056", argMin =>   "0", argMax =>  "1",   type =>"0clean",  unit =>""} 
);

maximalz

Yes, this should be the way. But his version of the heatpump does not have two pumps, but one pump and a switching valve, so I would think he has to figure out which register corresponds to this valve he woul like to operate.
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k)

TheTrumpeter

Well, when I temporarily fixed the stuck valve last time, I just operated the valve with the heatpump-display. There is a menu-point for expert that could just operate the valve.
After changing the position several times it was in the correct position for DHW.

Later when the MFG (includes the valve) was replaced by the technican, he told me that newer firmwares have some functionality to minimize the stress of the valve when switching. For example the circuit-pump is switched-off before the valve is operated.

When I just operate it on the display with the corresponding menu-point (or via FHEM with the register yet to be found) this functionality is of course not triggered.
I could also operate the circuitpump then, that's clear, but I do not know whether there is additional functionality or that has other side-effects not yet known.

Therefore it seems the best to me to do it exactly as described in the operating-manual. There it says to switch on and off DHW-mode several times as per change of the parameters for the temperature.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

So, ich habe die Zeiten nun gestoppt...

Nach der Parameteränderung WW-Temperatur wird der Verdichter praktisch sofort abgedreht & auch der Status "WW-Bereitung" wird sofort zurückgenommen.
Allerdings dauert es ca. 30 Sekunden, bis kein Relais-Klackern mehr hörbar ist bzw. sonstige sich ändernde Geräusche aus der LWZ dringen.
Wenn der Parameter WW-Temperatur wieder hochgesetzt wird, ändert das Display auch gleich die Anzeige, aber es dauert erneut ca. 30 Sekunden, bis kein Relais-Klackern mehr hörbar ist bzw. sonstige sich ändernde Geräusche aus der LWZ dringen.
Das war bei jedem Durchlauf der Schleife im Code so, d.h. die Zeiten scheinen recht konstant zu sein.

Damit sind meine 60 Sekunden jedenfalls "auf der sicheren Seite" & ich lasse das für mich auch so. Damit ist mein Code oben soweit fertig, falls es jemand übernehmen will.

Übrigens: Der Verdichter ist die ganze Zeit aus gewesen und erst nach der Sperrzeit (bei mir 20min) ab dem Ausschalten wieder angesprungen. D.h. für den Verdichter bedeutet das Modul keine zusätzliche Belastung.

Nach jedem Ende der WW-Bereitung wird das Heizungswasser auch durch den Heizkreis gepumpt. Man sieht an den Durchflussanzeigern auch, dass der Durchfluss vor dem Schalten des Umschaltventils stark abnimmt, aber nicht auf 0 geht. Dann schaltet das Umschaltventil und erst dann gehen die Anzeiger auf 0. Scheinbar wird also die Heizkreispumpe nicht komplett abgedreht, bevor das Ventil schaltet, sondern nur reduziert.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

Zitat von: immi am 07 März 2017, 13:21:50
I am not sure if I understood correctly: you want to manually switch off DHW for a short period.
One question, immi...

After restart of FHEM all readings of THZ are updated rather slowly. FHEM is working properly during this update, so it's not blocked. The regular readings for other devices are updated also in between although your module is still running.
If I understand your code properly, that's done in module THZ_Refresh_all_gets within one "foreach"-loop.
Why is FHEM not blocked all the time? Could I use the same method for "waiting" in my module???
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

immi

Zitat von: TheTrumpeter am 07 März 2017, 15:18:55
If I understand your code properly, that's done in module THZ_Refresh_all_gets within one "foreach"-loop.
Why is FHEM not blocked all the time?
It is magic :)
THZ_Refresh_all_gets deletes all internal timers and initialises new timer for each recurring reading (line 733).
InternalTimer(gettimeofday() + ($timedelay) , "THZ_GetRefresh", \%par, 0);
The function InternalTimer is very tricky. It sets a timer at which the function THZ_GetRefresh is executed.

It is much easier for you to use AT with 60s.
immi

TheTrumpeter

Ok thanks.

As I already said I'll keep it as it is now. As the module should never be called, it would never block FHEM.
I had a lot of work getting it to run as the initial version was very buggy regarding the cooperation of Perl and FHEM. Now I stay with "never change a running system"  ;)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

toggle

Hallo zusammen,

mir ist neulich aufgefallen, dass der Verbrauch meiner THZ404SOL zunimmt. Und es hat nicht unbedingt etwas mit dem kalten Januar zu tun. Ich habe mal den gleitenden Jahresverbrauch der letzen 2 Jahre grafisch dargestellt. Der in den ersten paar Monaten abnehmende Verbrauch erscheint mir plausibel (trocknender Neubau). Aber den kontinuierlichen Anstieg etwa seit November letzen Jahres kann ich mir nicht erklären, weil unsere Gewohnheiten sich nicht geändert haben (andere Verbräuche sind mehr oder weniger stabil). Irgendwelche Ideen, woran es liegen könnte oder was man untersuchen könnte?

Hat mal jemand die Abhängigkeit zwischen den Betriebsstunden, dem Verbrauch, der Wärmemenge (externer Wärmemengenzähler) und der Aussentemperatur über einen längeren Zeitraum untersucht? Möglicherweise kann man daran den Verschleiß bzw. die sinkende Effizienz o.ä. erkennen.

Und noch eine Beobachtung - am Ende von manchen Verdichterläufen gibt es einen lauten Knall, als ob irgendwas im Inneren umfallen würde. Es ist OK, dass die Ventile klappern können oder dass irgendwelche Umlenkklappen bewegt werden. Aber sind solche lauten Knallgeräusche normal und, falls ja, womit lassen sie und ihre Unregelmäßigkeit sich erklären?

Gruß
toggle

THZ404SOL (FW 5.39, SW ID 7278, 14.03.2014)