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

[willybauss]

Ja, wird alles aktualisiert. ...

Ich beginne, zu verstehen. Die ominösen e_Mythz_... Readings sind in der Detailansicht des Statusdisplays, richtig? Dort gibt es bei mir überhaupt keine Readings. Ich wüßte auch nicht, woher die kommen sollen. Hast Du innerhalb der Detailansicht des Statusdisplays auch eine userReadings-Definition? Das würde ich jetzt erwarten.

Ich habe die ganzen userReadings für die Statusanzeige in die userReadings von Mythz dazu gepackt. im Statusdisplay werden sie nur ausgewertet. Ich hoffe, dass das so verständlich beschrieben war.

Der letzte Code-Abschnitt in meiner Erklärung des Statusdisplays ("immi's Code zur Erkennung der aktuellen Lüfterstufe") beinhaltet die Berechnung zur Lüfterstufe (fanstage) incl. des Faktors 3,5 (mehrfach innerhalb des DOIF). Du kannst für Deine Zwecke den Faktor gerne so ändern, wie es für Deine Anlage besser passt.

Davon höre ich zum ersten mal, dass es Ventile mit eingebauter Drossel gibt, aber ich bin ja auch nur Anwender und kein Heizungsbauer. Vor- und Rücklauf kannst Du ja im Zweifelsfall an den Temperaturen unterscheiden. Der Durchfluss ist in beiden Fällen derselbe, macht also sicher keinen Unterschied. Aber wenn im Rücklauf gedrosselt wird, dann stehen die ganzen Heizkreise unter dem Druck, den die HK-Pumpe aufbaut, um die Drosseln zu überwinden. Wenn die Drossel im Vorlauf ist, dann ist dahinter "Freilauf", d.h. es besteht nur noch der normale Überdruck des Heizsystems lt. Manometer.

Wenn Du die Ventile alle ungedrosselt einstellst und nur an der anderen Seite der Leitungen drosselst, dann hast Du auf jeden Fall irgendwelche Irrtümer und versehentlchen "Doppeldrosselungen" ausgeschlossen, die Dir das Verständnis erschweren könnten.

[TheTrumpeter]

Ich beginne, zu verstehen. Die ominösen e_Mythz_... Readings sind in der Detailansicht des Statusdisplays, richtig?

Nein, in der Detailansicht vom "DOIF"Code.

Ich habe die ganzen userReadings für die Statusanzeige in die userReadings von Mythz dazu gepackt. im Statusdisplay werden sie nur ausgewertet. Ich hoffe, dass das so verständlich beschrieben war.

Ja dort habe ich sie auch hingegeben und dort sind sie auch.

Ich habe das Statusdisplay sowie den Code heute Früh kurzerhand wieder rausgelöscht, weil ich plötzlich Probleme mit den Plots hatte. Die gestrigen Plots wurden nicht mehr aktualisiert, nachdem ich diese Teile eingebaut habe und die heutigen Plots wurden auch nicht immer gezeichnet...
Das Problem hat sich durch das Löschen des Codes aber leider nicht beheben lassen. Möglicherweise ist irgendein Problem beim Parsen des Logfiles, weil da Fehlermeldungen aus den Userreadings drin sind? (Habe gestern beim Übertragen der neuen Readings einen Syntax-Fehler eingebaut, den ich erst heute Früh im globalen Logfile entdeckt habe.)

Der letzte Code-Abschnitt in meiner Erklärung des Statusdisplays ("immi's Code zur Erkennung der aktuellen Lüfterstufe") beinhaltet die Berechnung zur Lüfterstufe (fanstage) incl. des Faktors 3,5 (mehrfach innerhalb des DOIF). Du kannst für Deine Zwecke den Faktor gerne so ändern, wie es für Deine Anlage besser passt.

Falls Du daraus eine Anleitung/HowTo machen willst, wäre es gut darauf hinzuweisen. Ich verstehe von den ganzen FHEM-Befehlen leider immer noch sehr wenig und bin auch kein Meister von regulären Ausdrücken, sodass ich es erstmal "dumm" reinkopiert habe. Dann dachte ich das Problem gefunden zu haben, bis Du meintest der Code kann mit den unterschiedlichen Einheiten umgehen. Erst dann habe ich versucht den Code im Detail zu durchdringen und bin über die "3.5" gestolpert, die ich dann kurzerhand auf "4.0" geändert habe.

[willybauss]

Nein, in der Detailansicht vom "DOIF"Code.

Tatsächlich, da habe ich diese komischen "e_Mythz_..." Readings auch. Evtl. kann immi uns erklären, wie das zustande kommt, oder ich schau mir das heute Abend mal an. Mit dem Inhalt des DOIF alleine kann ich es mir auf die Schnelle nicht erklären. Aber ich sehe ähnliches auch in anderen DOIFs, aber nicht in allen.

Ich habe das Statusdisplay sowie den Code heute Früh kurzerhand wieder rausgelöscht, weil ich plötzlich Probleme mit den Plots hatte. Die gestrigen Plots wurden nicht mehr aktualisiert, nachdem ich diese Teile eingebaut habe und die heutigen Plots wurden auch nicht immer gezeichnet...
Das Problem hat sich durch das Löschen des Codes aber leider nicht beheben lassen. Möglicherweise ist irgendein Problem beim Parsen des Logfiles, weil da Fehlermeldungen aus den Userreadings drin sind? (Habe gestern beim Übertragen der neuen Readings einen Syntax-Fehler eingebaut, den ich erst heute Früh im globalen Logfile entdeckt habe.)

Könnte sein, dass dadurch das Mythz Logfile korrupt wurde. Schau es mal mit nem Texteditor an. An der Stelle (Datum/Zeit), wo die Plots aufhören hat sich evtl. eine falsche Zeile eingeschlichen, die Du raus löschen musst. Alle Zeilen müssen sinngemäß identischen Aufbau haben.
- Date/Time Stamp
- Modulname (Mythz)
- Reading
- Value
(Reading/Value wiederholt sich ggf. innerhalb der Zeile bei "Multi-Readings", wie z.B. sGlobal.)

Falls Du daraus eine Anleitung/HowTo machen willst, wäre es gut darauf hinzuweisen. Ich verstehe von den ganzen FHEM-Befehlen leider immer noch sehr wenig und bin auch kein Meister von regulären Ausdrücken, sodass ich es erstmal "dumm" reinkopiert habe. Dann dachte ich das Problem gefunden zu haben, bis Du meintest der Code kann mit den unterschiedlichen Einheiten umgehen. Erst dann habe ich versucht den Code im Detail zu durchdringen und bin über die "3.5" gestolpert, die ich dann kurzerhand auf "4.0" geändert habe.

Diese eigenartigen Regular Expressions in den userReading Definitionen filtern die Werte so, dass nur die Zahlen übrig bleiben. Ich habe davon auch sehr wenig Ahnung und freue mich, wenn's endlich geht. Du siehst das, wenn Du in der Mythz Detailansicht in den Readings nach diesen Werten suchst, z.B. inside_temp steht dort nur als Zahl.

[TheTrumpeter]

Könnte sein, dass dadurch das Mythz Logfile korrupt wurde. Schau es mal mit nem Texteditor an.

Ja daran hat's gelegen. Den Verdacht hatte ich auch schon. Waren nur 2 Einträge, Plots, die in den Zeitraum der Einträge gefallen sind, wurden nicht generiert. Alles was davor endete oder danach begann, hat funktioniert.
Habe noch die gestrigen Dateien aus dem Plot-Cache gelöscht und es ist wieder top :-)

Habe jetzt das Status-Display gleich wieder reingenommen (fhem.cfg war im nano noch offen, ich musste nach Beenden von fhem nur nochmal speichern  ).

Mal eine andere Frage... in der Standard-Konfiguration der Mythz aus dem Wiki wird für das mythz-logfile nur 1 Datei pro Jahr generiert. Kommt FHEM mit der Datei dann noch klar oder wird das langsam?
(Zugegeben, ich habe vorübergehend ein paar Intervalle recht kurz gehabt, aber ich habe jetzt schon 65000 Zeilen von 2017. Wenn ich das hochrechne, kommt da eine gigantische Zahl raus.)

[willybauss]

Bei mir sind es typisch 12 - 15 MB pro Monat. Deshalb habe ich jeden Monat eine neue Datei. Sonst könnten die Zugriffszeiten unangenehm werden. Dafür musst der FileLog_Mythz im Prinzip aussehen wie im Bild (Pfade halt entsprechend anpassen).

-%Y-%m besagt, dass monatlich ein neues File erstellt wird
archivedir ist selbst erklärend
nrarchive: die letzten n alten Files bleiben im log Verzeichnis, alles ältere wird ins Archiv verschoben

Ich will diesen Winter mal versuchen, die Datenmenge zu reduzieren, indem neue Daten nur noch dann gespeichert werden, wenn dich die Werte geändert haben. Das wäre z.B. bei sDisplay sinnvoll.

[willybauss]

... Was mir daran komisch vorkommt, ist, dass die Readings dort so komisch heissen, z.B. "e_Mythz_sGlobal".

Ich hab's jetzt in der CommandRef von DOIF gefunden:

e_<Device>_<Reading>|<Internal>|Events
Bezeichner und Wert der auslösenden Geräte mit Readings, Internals oder Events

[willybauss]

Nach Trumpeters Hinweis auf zu viele Log-Einträge habe ich mal angefangen, die Größe der Logfiles zu beschränken, indem ich nur noch notwendige Daten logge. Z.B. die Werte des Statusdisplays oder tonnenweise FanStageCurrent Einträge sind im Logfile unnötig.

Ich hatte auch versucht, die anderen Daten nur dann loggen, wenn sie sich gegenüber dem vorigen Wert geändert haben. Das kann allerdings dazu führen, dass Daten in den Plots fehlen. Der Spareffekt ist hier gering, da die wirklich großen Brocken (sGlobal ...) sich ja dauernd ändern.

Was habe ich gemacht:
Die Definion des FileLog_Mythz ändert sich in

Code: [Auswählen]

/mntUSB/fhem/log/Mythz-%Y-%m.log Mythz:.*_temp.*|Mythz:Cop.*|Mythz:Rel_humidity|Mythz:sB.*|Mythz:sE.*|Mythz:sG.*|Mythz:sH.*|Mythz:sL.*
Bisher waren alle Mythz-Readings im Log, jetzt wird eingeschränkt auf:

        Mythz:.*_temp.*      Temperaturwerte
        Mythz:Cop.*          Cop-Werte
        Mythz:Rel_humidity   Luftfeuchtigkeit
        Mythz:sB.*           StatusReadings beginnend mit Buchstaben  sB, sE, usw.
        Mythz:sE.*
        Mythz:sG.*
        Mythz:sH.*
        Mythz:sL.*

edit:
Bei mir erscheinen seit ein paar Tagen manche Readings/userReadings doppelt im Log. Die Ursache habe ich noch nicht gefunden => da wird nochmal eine kleine Reduzierung der Datenmenge hinterher kommen.

[willybauss]

Noch was fällt mir grade ein:
Nach einem Hinweis von awex... habe ich vor ein paar Tagen den Parameter P58 (Unterdrückung Temperaturmessung) von 60 auf 120 Sekunden geändert. Seither ist der Plot 2 (Integralwert, HK1-Soll-Ist) viel "glatter" ohne die vielen Zacken, die sich immer beim Einschalten der HK-Pumpe ergeben hatten.

Grund:
In Heizpausen kühlt die Rücklauftemperatur in der Anlage schneller aus als in den Heizkreisen. Um eine echte Rücklauftemperatur messen zu können schaltet die Pumpe in den definierten Intervallen (P54, P55) ein, pumpt das Rücklaufwasser aus dem Fußboden zur Anlage zurück und misst dann mit Zeitverzögerung (P58) die "wahre" Fußbodentemperatur. Wenn P58lang genug eingestellt ist, dann vermischt sich das Wasser vor der Messung (unterschiedlich lange Heizkreise, unterschiedlich lange Zuläufe zu den HK-Verteilern) und man erhält die durchschnittliche Rücklauftemperatur des ganzen Hauses.

Mit ist allerdings schleierhaft, weshalb die Pumpe  in den Intervallen immer für 5 Minuten anläuft, wenn man P58 auf maximal 120 Sekunden einstellen kann. Dann würden für den Pumpenlauf ja auch 2 Minuten genügen.

[TheTrumpeter]

Bei mir erscheinen seit ein paar Tagen manche Readings/userReadings doppelt im Log. Die Ursache habe ich noch nicht gefunden => da wird nochmal eine kleine Reduzierung der Datenmenge hinterher kommen.

Nur ein Schuss ins Blaue:
Möglicherweise die, wo eine Deiner RegEx mehrfach zuschlägt? Z.B. Readings, wo 2 Temperaturen enthalten sind und daher "Mythz:.*_temp.*" zweimal passt?

Was anderes: Warum berücksichtigst Du bei der COP-Berechnung eigentlich die Wärmerückgewinnung der Lüftung (negativ) mit? Das ist doch völlig irrelevant, oder? Die WP zieht x Strom und gibt y Wärme ab.

Nach einem Hinweis von awex... habe ich vor ein paar Tagen den Parameter P58 (Unterdrückung Temperaturmessung) von 60 auf 120 Sekunden geändert. Seither ist der Plot 2 (Integralwert, HK1-Soll-Ist) viel "glatter" ohne die vielen Zacken, die sich immer beim Einschalten der HK-Pumpe ergeben hatten.

Habe ich auch vor ca. 2 Wochen umgestellt, als ich den Parameter entdeckt habe. Die Zacken sind aber trotzdem da und ca. 1°K gross. Geändert hat sich nach meinem Gefühl aber der Einschaltzeitpunkt des Verdichters. In den Plots sieht es so aus als ob jetzt die Zacken komplett um Hysterese1 unter Raum-Soll sein müssen, bevor die Heizung anläuft. Davor musste die Linie nur mal kurz drunter sein.
Könnte daher sein, dass sich Deine und meine Anlage bzgl. P58 anders verhält: Bei Deiner Anlage wird die Temperatur für diese Zeit eingefroren, die Kurve scheint daher "geglättet". Bei meiner Anlage wird die Temperatur zwar berechnet, aber der Wert erst nach P58 zur Berechnung der Ist-Temperatur herangezogen. Ergebnis ist das gleiche, nur der Weg dorthin anders.

[willybauss]

Nur ein Schuss ins Blaue:
Möglicherweise die, wo eine Deiner RegEx mehrfach zuschlägt? Z.B. Readings, wo 2 Temperaturen enthalten sind und daher "Mythz:.*_temp.*" zweimal passt?

Was anderes: Warum berücksichtigst Du bei der COP-Berechnung eigentlich die Wärmerückgewinnung der Lüftung (negativ) mit? Das ist doch völlig irrelevant, oder? Die WP zieht x Strom und gibt y Wärme ab.

Woran siehst Du das?

Code: [Auswählen]

CopHC:sHeatRecoveredDay.* {sprintf("%.2f", ReadingsNum("Mythz","sHeatHCDay",1) / ReadingsNum("Mythz","sElectrHCDay",1))},
CopDHW:sHeatRecoveredDay.* {sprintf("%.2f", ReadingsNum("Mythz","sHeatDHWDay",1) / ReadingsNum("Mythz","sElectrDHWDay",1))},


userReadings
... Jede Definition hat folgendes Format:
<reading>[:<trigger>] [<modifier>] { <perl code> }

CopHC:sHeatRecoveredDay ist lediglich der Trigger. Den habe ich gewählt, weil er auch zu Zeiten, wo nicht geheizt wird, zur Verfügung steht. Berechnet wird aus sHeatDHWDay/sElectrDHWDay

Aus demselben Grund glaube ich auch nicht an den Schuss ins blaue. Getriggert werden die userReadings immer auf das "Multi-Reading", in dem der zu extrahierende Einzelwert enthalten ist. Das Multi-Reading selbst wird ja nur einmal erzeugt. Nur die daraus abgeleiteten userReadings kommen mehrfach-

[TheTrumpeter]

Aus demselben Grund glaube ich auch nicht an den Schuss ins blaue. Getriggert werden die userReadings immer auf das "Multi-Reading", in dem der zu extrahierende Einzelwert enthalten ist. Das Multi-Reading selbst wird ja nur einmal erzeugt. Nur die daraus abgeleiteten userReadings kommen mehrfach-

Ok, ich muss wohl noch mehr in die CommandRef schauen, bevor ich ins Blaue schiesse...

[The Spirit]

Gibt es eigentlich eine Übersicht über alle Parameter und Werte in deutsch?  Bin mir immer mal wieder unsicher bei den Parametern was die deutsche Übersetzung ist.
Danke

[willybauss]

Gibt es eigentlich eine Übersicht über alle Parameter und Werte in deutsch?  Bin mir immer mal wieder unsicher bei den Parametern was die deutsche Übersetzung ist.
Danke

Die Anlagenparameter findest Du natürlich in der Installationsanleitung Deiner Anlage unter den auch hier verwendeten Nummern (Pxx). Der Rest ... keine Ahnung. Wenn Du was spezielles brauchst frag einfach. Manches weiß ich, den Rest weiß immi.

[awex102]

Passt der zeitliche Zusammenhang? Bei mir kann ich keinen erkennen. Ich habe diese Meldungen nicht.

Guten Morgen,

ja, irgendwie schon, grade eben nochmal genau geschaut:

2017.01.21 09:12:09 1: /dev/ttyUSB1 disconnected, waiting to reappear (THZ403)
2017.01.21 09:12:10 3: Setting THZ403 serial parameters to 115200,8,N,1
2017.01.21 09:12:10 1: /dev/ttyUSB1 reappeared (THZ403)

Ab 2017-01-21 09:10:38 refresh aller Werte.

Pumpe läuft ab 08:53 durch.

Also kein Zusammenhang im Minutenbreich, aber irgendwie schon, denn die verlorene Verbindung taucht immer dann auf, wenn die Pumpe anfängt zu laufen. Sieht eher so aus, dass die Anlage out of sync kommt und dadurch auch die Verbindung verloren geht.

Ob das eher an der USB Verbindung liegt, vielleicht sollte ich auf den externen Anschluss wechseln ?

[awex102]

- 10 Grad heute.

Hier die Logs von heute Nacht zum Thema: Selbes Spiel: Pumpe geht an und Integralwert schießt in den Keller, Heizphase beginnt zu früh. Das wird auf dauer doch recht teuer, zumindest sieht es so aus.

Verbindungsverlust:

2017.01.22 06:08:32 1: /dev/ttyUSB1 disconnected, waiting to reappear (THZ403)
2017.01.22 06:08:33 1: /dev/ttyUSB1 reappeared (THZ403)

2017.01.22 06:22:01 1: /dev/ttyUSB1 disconnected, waiting to reappear (THZ403)
2017.01.22 06:22:01 1: /dev/ttyUSB1 reappeared (THZ403)