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

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

Vorheriges Thema - Nächstes Thema

ioT4db

hi,

so siehts bei mir aus:

2015.09.30 23:32:29 5: Cmd: >get Mythz sLast10errors<
2015.09.30 23:32:29 5: THZ_Get: Try to get 'sLast10errors'
2015.09.30 23:32:29 5: THZ_Get_Comunication: Check if port is open. State = '(opened)'
2015.09.30 23:32:29 5: Mythz sending 02
2015.09.30 23:32:29 5: SW: 02
2015.09.30 23:32:29 5: Mythz start Funktion THZ_ReadAnswer
2015.09.30 23:32:29 5: THZ_ReadAnswer: uc unpack: '10'
2015.09.30 23:32:29 5: Mythz sending 0100D2D11003
2015.09.30 23:32:29 5: SW: 0100D2D11003
2015.09.30 23:32:29 5: Mythz start Funktion THZ_ReadAnswer
2015.09.30 23:32:29 5: THZ_ReadAnswer: uc unpack: '10'
2015.09.30 23:32:29 5: Mythz start Funktion THZ_ReadAnswer
2015.09.30 23:32:29 5: THZ_ReadAnswer: uc unpack: '02'
2015.09.30 23:32:29 5: Mythz sending 10
2015.09.30 23:32:29 5: SW: 10
2015.09.30 23:32:29 5: Mythz start Funktion THZ_ReadAnswer
2015.09.30 23:32:29 5: double read 1 activated 0100D7D1010122001302C10B00
2015.09.30 23:32:29 5: double read 1 result with buf1  0100D7D1010122001302C10B00000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 2 activated 0100D7D1010122001302C10B00000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 2 result with buf1  0100D7D1010122001302C10B00000000000000000000000000000000000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 3 activated 0100D7D1010122001302C10B00000000000000000000000000000000000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 3 result with buf1  0100D7D1010122001302C10B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 4 activated 0100D7D1010122001302C10B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2015.09.30 23:32:29 5: double read 4 result with buf1  0100D7D1010122001302C10B0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001003
2015.09.30 23:32:29 5: THZ_ReadAnswer: uc unpack: '0100D7D1010122001302C10B0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001003'
2015.09.30 23:32:29 5: Mythz sending 10
2015.09.30 23:32:29 5: SW: 10
2015.09.30 23:32:29 5: Parse message: D7D1010122001302C10B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2015.09.30 23:32:29 5: Message length: 128
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

immi

passt
Parse message: D7D1010122001302C10B00
so wird decodiert
D7D1  checksum+registername
0101--> 1 failure    
2200--> fault0CODE 34   
1302--> fault0TIME   0213 ->5:31
C10B--> date 0BC1 --> 30.09   

if you look here http://www.tecalor.de/dam/jcr:41d93500-ae8f-4fea-a7c4-dd057c679095/DM0000022464-jei_BI_THZ%20304-404%20SOL%20Installation.pdf
failurecode  34
Volumenstromsensor
Drücken Sie die Reset-Taste der Elektronik. Tritt der Fehler wiederholt auf, benachrichtigen Sie den Kundendienst.

willybauss

lt. dem Installationsmanual, das immi verlinkt hat (dessen mehrfache Lektüre ist IMMER eine gute Idee, um die Anlage besser zu verstehen), ist es ein Fehler des Volumenstromsensors. Damit ist vermutlich der Volumenstrom des HEizungs-Vorlaufs gemeint. Wenn es eine neue Anlage ist solltest Du darauf achten, dass das innerhalb der Garantiezeit "irgendwie" behoben wird.


Ach ja: herzlich willkommen - hier werden Sie geholfen  :)
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ioT4db

Moin und Danke nochmal fürs geholfen werden ;)

Ich trenn die 2 Probleme mal:
1) Anlage meldet Fehler > ich hab ein Problem > ich lass das reparieren (Anlage wurde 03/2014 in Betrieb genommen > Garantie)

2) mein eigentlicher Antrieb das zu posten > der Eintrag in der myTHZ-Logdatei gibt eben nicht das wieder was im Display steht und das wollt ich in Diskussion bringen, warum das so sein könnte bzw. wie man das beheben kann. In der Mail wird ja so kein Fehlercode mitgeliefert, da der Log-Eintrag diesen nicht enthält.

@immi: mit "passt", meinst Du ja dass Die Daten von der THZ richtig empfangen werden > also muß irgendwas im THZ-Modul das nicht richtig umzusetzen. was meinst Du? könnte es an meiner neueren Firmware liegen?

PS: werd heut Abend mal die "Fehlermeldungen.txt" erweitern und posten...

VG
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

willybauss

zu Punkt 2:
immi hat heute Nacht im Thread zur Codeentwicklung einen Bugfix veröffentlicht. Ich vermute, dass er Dein Problem lösen soll. Du kannst ja mal im Lauf des Tages ein "update 00_THZ" (hoffentlich stimmt die Syntax so) machen. Dumm nur, dass Du erst sehen wirst, ob der Bugfix Dir hilft, wenn der Fehler wieder auftritt.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

@friesenjung:
Noch was: bei der Vorgängeranlage 303 ist bei ähnlichen Problemen meist die Verstopfung eines Siebs die Ursache. Die Ursache der Verstopfung wiederum ist i.d.R. Kalk im Heizungswasser. Dieser Kalk führt langfristig zu weiteren Problemen, vor allem defekte Rückschlagklappen. Es wäre gut, mal den Kalkgehalt des Heizungswassers zu bestimmen. Messstäbchen gibts für wenig Geld im Aquarienzubehör. Stiebel-Eltron/Tecalor macht sehr scharfe Vorschriften für die Wasserhärte; je nach Anlage und Auflage des Installationsmanuals geht das runter bis zu 1°dH. Wenn das die Ursache des Problems ist, wird der Hersteller evtl. die Garantie ablehnen. Dann musst Du den Installateur zur Verantwortung ziehen, und vor allem die Anlage spülen und neu befüllen lassen.

Das HaustechnikDialog-Forum ist voll mit Berichten über dieses Problem, speziell bei den LWZ/THZ Anlagen.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ioT4db

grad mal ein update gemacht und jetzt werden die Readings richtig angezeigt! > Sehr geil, wie schnell das immi gefixt hat! Merci...

jetzt sieht das das Reading so aus:
number_of_faults: 1 fault0CODE: F34_FlowSensor fault0TIME: 05:31 fault0DATE: 30.09 fault1CODE: n.a. fault1TIME: 00:00 fault1DATE: 0 fault2CODE: n.a. fault2TIME: 00:00 fault2DATE: 0 fault3CODE: n.a. fault3TIME: 00:00 fault3DATE: 0

passt :)

@willybaus: Danke für die Hinweise. Werd das mal angehen!
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

micomat

Zitat von: micomat am 30 September 2015, 11:04:08
Two notifys to start and stop fans depending on Betriebsart Winter/Summer
define notifyWintermode notify Mythz:Betriebsart {if ((ReadingsVal("Mythz","Betriebsart",0) eq "winter") && (ReadingsVal("Mythz","Zuluftventilator",0) > 0)) {fhem "set Mythz p07FanStageDay 0;; set Mythz p08FanStageNight 0"}}
define notifySummermode notify Mythz:Betriebsart {if ((ReadingsVal("Mythz","Betriebsart",0) eq "summer") && (ReadingsVal("Mythz","Zuluftventilator",0) == 0)) {fhem "set Mythz p07FanStageDay 1;; set Mythz p08FanStageNight 1"}}


okay, the notify was not firing the summer mode today... seems to need some more attention to check...
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

ioT4db

Nabend!

nochmal zu den Fehlermeldungen im Zusammenhang mit der eMail, die gesendet wird...

Ich hab mit dem Kundendienst telefoniert und die sagten mir ich soll den Fehlerspeicher mal löschen und schauen, ob der Fehler wieder auftritt (bei gleichem Fehlercode wird nämlich der erste Eintrag NICHT überschrieben oder gar eine 2. Fehlermeldungszeile gefüllt!!!). Gesagt, getan.

In der nachfolgenden Nacht kam der Fehler tatsächlich erneut und das Reading passt jetzt ja auch  :D, nur diesmal hat FHEM keine Mail verschickt (hab auch im Log geschaut > nix). Jemand eine Idee? Wird das in der Notify-Logik vlt. nicht abgefangen, wenn man den Fehlerspeicher löscht? Hab versucht die die Notifys zu prüfen, hab aber nichts finden können - bin da aber noch nicht ganz soweit das alles zu blicken :(

VG...

PS1: im Anhang noch die vervollständigte Tecalor-Fehlermeldungen.txt

PS2: was mir grad noch aufgefallen ist, ist dass der Eintrag im sGlobal bei "lowPressureSensor" der Wert 1 steht (also: lowPressureSensor: 1) ISt das bei Euch auch so???
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

micomat

so that did the trick:

    define notifyWintermode notify Mythz:Betriebsart[b].*[/b] {if ((ReadingsVal("Mythz","Betriebsart",0) eq "winter") && (ReadingsVal("Mythz","Zuluftventilator",0) > 0)) {fhem "set Mythz p07FanStageDay 0;; set Mythz p08FanStageNight 0"}}
    define notifySummermode notify Mythz:Betriebsart[b].*[/b] {if ((ReadingsVal("Mythz","Betriebsart",0) eq "summer") && (ReadingsVal("Mythz","Zuluftventilator",0) == 0)) {fhem "set Mythz p07FanStageDay 1;; set Mythz p08FanStageNight 1"}}

Now all my codes are working like a charm :)
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

immi

Hi Markus
happy you made it alone.
Now as master of the Wiki, when you have time, it would be great if you document your findings :)
Please put it in a separate chapter; something like "advanced" or "only for FHEM experts".... or "goind the last mile"...
People new to fhem have enought truobble, without it.
People used to fhem should be encoraged to keep on playing
immi

micomat

Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

vscot

@friesenjung
Prüfe mal deinen Volumenstrom, v.a. während der Warmwasserbereitung. Sollte bei 60% Pumpenleistung in etwa bei 22l/min liegen. Wenn das hinhaut, dann ist der Sensor in Ordnung. Würde dann vermuten, dass keine Stellventile offen waren? Ist eine Überströmmöglichkeit gegeben? Wenn der Volumenstrom länger <5l/min ist, dann kommt Fehler 36.

willybauss

Zitat von: friesenjung am 02 Oktober 2015, 21:26:30
... nur diesmal hat FHEM keine Mail verschickt (hab auch im Log geschaut > nix). Jemand eine Idee?
Ich habe mir mal den Code für den Emailversand angesehen. Da hatte ich etwas geschlampt:

Mythz { if (((split ' ',ReadingsVal("Mythz","sLast10errors",0))[1]) > ReadingsVal("Mythz","number_of_faults_old",0)) { DebianMail('WilfriedBauer-Stgt@t-online.de','Tecalor Mythz Alarm - ERROR','Fehlermeldung: '. $EVENT,'/mnt/fhem/Tecalor-Fehlermeldungen.txt'); fhem("setreading Mythz number_of_faults_old ". ((split ' ',ReadingsVal("Mythz","sLast10errors",0))[1])); } }
Die Entscheidung für den Emailversand erfolgt , wenn die Anzahl der Fehlermeldungen ansteigt. Nachdem eine Email verschickt wurde, wird die Dummy-Variable " number_of_faults_old" hochgezählt, sonst würdest Du alle 5 Minuten eine weitere Email bekommen. Nach dem zurücksetzen des Fehlerspeichers steht die Variable aber immernoch auf 1. Du kannst sie mit setvalue ... auf 0 zurücksetzen.

Ich (oder gerne auch Du, wenn Du mal tiefer drin bist) sollte mal den Code erweitern, damit bei Anzahl Fehler = 0 die Dummyvariable automatisch zurückgesetzt wird.

PS:
Dasselbe Problem besteht dann wohl auch beim Emailversand für zu hohe bzw. zu niedrige Raumtemperatur.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

Zitat von: vscot am 03 Oktober 2015, 20:17:38
@friesenjung
Prüfe mal deinen Volumenstrom, v.a. während der Warmwasserbereitung. Sollte bei 60% Pumpenleistung in etwa bei 22l/min liegen. Wenn das hinhaut, dann ist der Sensor in Ordnung. Würde dann vermuten, dass keine Stellventile offen waren? Ist eine Überströmmöglichkeit gegeben? Wenn der Volumenstrom länger <5l/min ist, dann kommt Fehler 36.
Prinzipiell alles richtig. Aber wenn das die Ursache ist, ist es ein Fehler der Installation. Dafür sollte der Handwerker gerade stehen.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS