THZ / LWZ Tecalor Stiebel Eltron Heizung

Begonnen von Heiner, 02 Juni 2013, 11:39:13

Vorheriges Thema - Nächstes Thema

immi

Zitat von: willybauss am 29 Januar 2015, 08:17:26
As far as I know it needs a Stiebel Eltron technician to update the firmware, right?
the problem is where to get the firmwares and a compatibility list

Gassi

Hallo,
Seit ein paar Tagen werden bei mir in den Plots nichts mehr angezeigt. Die Fenster sind da, aber leer (ohne Kennlinien). Ich habe nichts geändert. Der Raspi ist mit der THZ verbunden und die Werte sind bei sGlobal alle da (sichtbar).Nur werden die Plots nicht geschrieben. Softwarestand 0.127
Ich habe auch schon den Raspi neu gestartet.
Es ist jetzt alles ca. 4 Monate am Stück gelaufen.
Hat mir jemand einen Tipp?

immi

Zitat von: Gassi am 29 Januar 2015, 20:01:42
Hallo,
Seit ein paar Tagen werden bei mir in den Plots nichts mehr angezeigt. Die Fenster sind da, aber leer (ohne Kennlinien). Ich habe nichts geändert. Der Raspi ist mit der THZ verbunden und die Werte sind bei sGlobal alle da (sichtbar).Nur werden die Plots nicht geschrieben. Softwarestand 0.127
Ich habe auch schon den Raspi neu gestartet.
Es ist jetzt alles ca. 4 Monate am Stück gelaufen.
Hat mir jemand einen Tipp?
update or force update
thz didn´t change much; but major changes in fhem including plotting have been done in the last days
immi


PhyTHZ

Hello all,

I continued to search for the reason for the numerous NAK/no response messages in my log and looked at the communication between my Zyxel NAS and the THZ403sol v. 4.39 with a "spy" cable. immi was completely right, the communication itself looks fine. If the problem occurs, the sequence is always

02 (THZ_PM)
10 (403sol)
Actual request (THZ_PM)
15 or "no response" (403sol)

Up to now I haven't found any correlation with the 403sol system state or the like.
So unless somebody has a better idea, the only thing I could think of is to implement a loop repeating failed requests.

Regarding the firmware version discussion: I had a look at the PCB and found a label in the center with "F.419" followed by a five digit number on it. Maybe this is a hint, that the PCB left the factory with firmware version 4.19. It is really a pity, that it's not possible to get the service software from Stiebel/Tecalor (or the description of the protocol).

However, despite these issues the monitoring already revealed some interesting things; e.g. my 403sol is affected from the "circulation pump runs always, if solar is active" bug. So either I need a new corrected firmware or control over "freigabe solar" in fhem :-)

Best wishes,

PhyTHZ

andre.k

Hi immi,

the attached patch contains the missing parsing rules for the 2.x commands. I had some problems with the parsing type hex2time.
when ("hex2time") {$value= sprintf(join(':', split("\\.", hex(substr($value, 0,2) . substr($value, 2,2))/100))) ;}

The start/end time in the program registers are represented in hex:0735 -> decimal: 1845 -> time:18:45.
In my case i used the following line.
when ("hex2time") {$value= sprintf("%02u:%02u", hex($value)/100, hex($value)%100) ;}

Could you please check, if this works in all cases. Otherwise we need to use two different versions of hex2time.

Andre

immi

Gassi
look at your logfiles. maybe empty or corrupted?

PhyTHZ
I would suggest that you do not loop in case of a NAK.
I inteprete a NAK as a strange status of your heatpump. If it is really busy, I wouldn´t increase the CPU-load.
I would just drop a reading every now and then.
I am still hoping we can (sooner or later) upgrade our firmware ourself.

immi

immi

Hi Andre
can you explain me the difference?
my $value = "0735";
$value1= sprintf(join(':', split("\\.", hex(substr($value, 0,2) . substr($value, 2,2))/100))) ;
$value2= $value= sprintf("%02u:%02u", hex($value)/100, hex($value)%100) ;
print $value1;
print "\n";
print $value2;

I get the same result 18:45 in MACOS and QNAP.
immi


PhyTHZ

Hi immi,

I agree with you. A loop immediately resending each failed request wouldn't be very clever. However, I want to make sure, that parameters like sElectrDHWDay, sElectrDHWTotal, or the like are read at least once a day. Of course I could just decrease the polling interval, but that wouldn't be very elegant as well.

Best wishes,

PhyTHZ

andre.k

Hi immi,

try another example "0320" and you see the difference.

Andre

immi

Zitat von: PhyTHZ am 29 Januar 2015, 21:20:58
However, I want to make sure, that parameters like sElectrDHWDay, sElectrDHWTotal, or the like are read at least once a day.
Hi PhyTHZ
you are right not elegant: but I would read them 4 times a day and store them on change with a min of one time every 23h.

Zitat von: andre.k am 29 Januar 2015, 21:28:08
try another example "0320" and you see the difference.
Hi Andre,
I see. I use your fix.
immi


immi


andre.k

Zitat von: immi am 29 Januar 2015, 21:50:28
Hi Andre
please test
immi
Hi immi,
it works, verry good.
thank you
Andre




willybauss

Zitat von: immi am 29 Januar 2015, 20:57:26
Gassi
look at your logfiles. maybe empty or corrupted?
@Gassi:
Am besten mal das Logfile umbenennen, so dass fhem es nicht mehr findet. Es sollte dann neu angelegt werden. Dann mal ne Weile laufen lassen und im File mit Texteditor nachschauen, ob wirklich alle paar Minuten die geloggten Daten drin ankommen.

Ich hatte mal versehentlich eine Textzeile eingefügt. Ab diesem Datum/Uhrzeit blieben meine Plots leer. Die Zeile aus dem Log gelöscht und alles war wieder gut.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

belu

Zitat von: toggle am 28 Januar 2015, 19:45:10

Ich habe noch zwei Kleinigkeiten beizutragen:
Das Register 0x0A0176 enthält bei meiner WP (THZ 404 SOL, Ver. 5.39, SW ID 7278) Bits für die Display-Icons.
Ich habe bisher folgende Bits decodiert (Namen wie im Handbuch):
0x0001 - Schaltprogramm
0x0002 - Verdichter
0x0004 - Heizen
0x0010 - Warmwasserbereitung
0x0020 - elektrische Nachheizstufen
0x0100 - Filterwechsel oben und unten
0x0200 - Lüftungsstufe
0x0400 - Heizkreispumpe
0x0800 - Abtauen Verdamper
0x1000 - Filterwechsel oben
0x2000 - Filterwechsel unten

Des Weiteren findet man die Raumtemperatur der Fernbedienung in Bytes 32-33 der Payload der Message 0xF4. Ich glaube es würde in Perl folgendem entsprechen:
[" roomTempRC: ", 68, 4, "hex2int", 10]

@ Toggle, thx

Immi, can u add the lines for the thz 304 404 5.39 in sGlobal?

thx Immi