THZ Tecalor (LWZ Stiebel Eltron) module support and code improvement.

Begonnen von immi, 02 Februar 2015, 11:42:16

Vorheriges Thema - Nächstes Thema

toggle

Hallo zusammen,

habt ihr beobachtet, welche WP-Schnittstelle Techniker für Einstellungen benutzen? Ist es die RS232 oder die USB?

Gruß
toggle
THZ404SOL (FW 5.39, SW ID 7278, 14.03.2014)

philipp_b


willybauss

Bei meiner 303 die RS232, aber sicher deshalb, weil USB unzugänglich verbaut ist.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

toggle

Ich habe mir gedacht, man könnte ja die Kommunikation der Installationssoftware belauschen, ohne diese zu besitzen. Eine RS232-Schnittstelle abzuzweigen ist kein so großer Aufwand. Bei der USB-Schnittstelle wird es schon etwas komplizierter. Man muss zwar nicht direkt die USB-Schnittstelle anzapfen - dahinter ist ja ein CP2102 (USB-RS232) verbaut - aber man kommt ohne Löten nicht aus. Und natürlich muss ein Techniker-Besuch anstehen.
THZ404SOL (FW 5.39, SW ID 7278, 14.03.2014)

willybauss

Klingt jetzt aber schon so ein bisschen nach illegaler Kommunikationsüberwachung, auch wenn es kein Telefon ist  ...  :-\
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

immi

maybe Toggle should stick a disclaimer to the heatpump
like in US "Do not put pets in the microwave to dry them"

"warning technician: the customer will look at everything you do to their heatpump; please remember, he owns the heatpump and pays for the manteinance"

sorry: We are drifting off-topic... but I want the copyright for the disclaimer :)

immi

v0.173 uploaded
THZ_RemoveInternalTimer has been removed for Ansgar

--- reminder for me ---
Rudolf improved the RemoveInternalTimer function  in fhem.pl
https://svn.fhem.de/trac/changeset/15667/.
This allows removing all Timers with just the Function.
RemoveInternalTimer(undef, "THZ_GetRefresh") is now equivalent to THZ_RemoveInternalTimer("THZ_GetRefresh") which is now redundant
%intAt  should be avoided
----------



ph0x

Hello immi (and rest)!

First of all, let me express my gratitude for all the work and effort that you put into the development of this fhem module, I really appreciate it a lot!

I would like to suggest a slight code improvement. Somewhere around LOC #1850 you define the value $roomSetTemp in order to create the heat curve diagram on the mythz site.
Since I have a rather old LWZ303i with firmware v2.03 the internal value of sHC1:roomSetTemp is 0. This might be also related to some other settings I have but I wasn't able to figure this out completely.

The fact remains, that when you calculate
my $b = -14 * $p13GradientHC1 / $roomSetTemp;
my fhem crashes because of the division by zero. Unfortunately your check for definition of $roomSetTemp a few lines earlier doesn't help, because $roomSetTemp is defined, but is zero...

As a work around I redefined $roomSetTemp as p01RoomTempDay but I know that this is a bit short sighted and might not be applicable to others. It works for me since I don't have a heating program defined and since there doesn't seem to be a value like p01RoomTempDayHC1SummerMode with my old firmware.

I can't come up with a smart solution to this problem but maybe you can consider another check for $roomSetTemp before performing the actual division.


Fine regards,
Marco

immi

Hi Marco
can you try changing the following (is is 2 lines above)?

if (!defined($roomSetTemp)) {

with
if (!$roomSetTemp) {


if it works, I will update the code... it should cover both undef and 0 at the same time
immi

andre.k

Hi Marco,

what value have you set for "firmware" in the attribute section 2.06 or 2.14? The diffenence between these versions in terms of sHC1 is  the position of the value roomSetTemp in the Register. If you set to the wrong version this could be the reason why roomSetTemp=0.

Andre


ph0x

immi: it works, although now I'm of course presented with the DEMO: no data graph...

Andre: I set it to 2.06. Do you think, 2.14 would work better?

EDIT:
I just tried setting the firmware version to 2.14 and did not encounter any difficulties so far. Nice!
Unfortunately there are now several additional readings that do not apply to my machine, but who cares...

andre.k

Yes, 2.14 is closer to your 2.03 than 2.06. The version 2.14 is the first version for THZ 303 SOL and has a similar release date like your 2.03.
I found the following information in the Tecalor "Ersatzteilkatalog"
THZ 303 INTEGRAL
2.03 (2002/01-2004/04)
2.05 (2004/04-2006/11)
2.06 (2006/12-2008/08)
THZ 303 SOL
2.14 (2002/10-2004/08)
2.15 (2004/09-2006/08)
2.16 (2006/09-2008/08)


immi

added [" Service: ", 10, 1, "bit2", 1] from  toggle
v 0.175 uploaded


andre.k

Ich habe mal etwas intensiver an zwei Registern geforscht, eins liefert diverse Statuswerte, die zum Teil auch schon in sGlobal enthalten sind das andere liefert Werte aus der Lüftungssteuerung. Ich weiss nicht inwiefern die Register auch in den neueren Anlagen bzw. Firmware<>2.14 vorhanden sind. Vieleicht könnte das mal jemand testen. Die zugehörigen Get-Kommandos sind wie folgt definiert:
  "sControl"  => {cmd2=>"F2", type =>"F2ctrl", unit =>""},
  "sFan"  => {cmd2=>"E8", type =>"E8fan", unit =>""},


Die Definitionen für das Parsing sehen dann so aus:
"E8fan" => [["statusAFC: ", 4, 4, "hex", 1], # 0=init air flow calibration (16:00) 4=normal fan operation
[" supplyFanSpeedCAL: ", 8, 4, "hex", 60], # calibration speed
[" exhaustFanSpeedCAL: ", 12, 4, "hex", 60],
[" supplyFanAirflowCAL: ", 16, 4, "hex", 100], # calibration air flow volume
[" exhaustFanAirflowCAL: ", 20, 4, "hex", 100],
[" supplyFanSpeed: ", 24, 4, "hex", 1], # actual fan speed in 1/s
[" exhaustFanSpeed: ", 28, 4, "hex", 1],
[" supplyFanAirflowSet: ", 32, 4, "hex", 1],         # actual air flow volume setting in m3/h
[" exhaustFanAirflowSet: ", 36, 4, "hex", 1],
[" supplyFanSpeedTarget: ", 40, 4, "hex", 1], # target fan speed in %
[" exhaustFanSpeedTarget: ", 44, 4, "hex", 1],
[" supplyFanSpeed0: ", 48, 4, "hex", 10],
[" exhaustFanSpeed0: ", 52, 4, "hex", 10],
[" supplyFanSpeed200: ", 56, 4, "hex", 10],
[" exhaustFanSpeed200: ", 60, 4, "hex", 10],
[" airflowTolerance: ", 64, 2, "hex", 1],
[" airflowCalibrationInterval: ", 66, 2, "hex", 1],         # calibration interval
[" timeToCalibration: ", 68, 2, "hex", 1] # days to next calibration
],


"F2ctrl"  => [["heatRequest: ", 4, 2, "hex", 1],         # 0=DHW 2=heat 5=off 6=defrostEva
[" heatRequest2: ", 6, 2, "hex", 1],         # same as heatRequest
[" hcStage: ", 8, 2, "hex", 1],  # 0=off 1=solar 2=heatPump 3=boost1 4=boost2 5=boost3
[" dhwStage: ", 10, 2, "hex", 1], # 0=off, 1=solar, 2=heatPump 3=boostMax
[" heatStageControlModul: ", 12, 2, "hex", 1], # either hcStage or dhwStage depending from heatRequest
[" compBlockTime: ", 14, 4, "hex2int", 1],         # remaining compressor block time
[" pasteurisationMode: ", 18, 2, "hex", 1], # 0=off 1=on
[" defrostEvaporator: ", 20, 2, "raw", 1],         # 10=off 30=defrostEva
[" boosterStage2: ", 22, 1, "bit3", 1], # booster 2
[" solarPump: ", 22, 1, "bit2", 1], # solar pump
[" boosterStage1: ", 22, 1, "bit1", 1], # booster 1
[" compressor: ", 22, 1, "bit0", 1], # compressor
[" heatPipeValve: ", 23, 1, "bit3", 1], # heat pipe valve
[" diverterValve: ", 23, 1, "bit2", 1], # diverter valve
[" dhwPump: ", 23, 1, "bit1", 1], # dhw pump
[" heatingCircuitPump: ", 23, 1, "bit0", 1], # hc pump
[" mixerOpen: ", 25, 1, "bit1", 1], # mixer open
[" mixerClosed: ", 25, 1, "bit0", 1], # mixer closed
[" sensorBits1: ", 26, 2, "raw", 1], # sensor condenser temperature ??
[" sensorBits2: ", 28, 2, "raw", 1], # sensor low pressure ??
[" boostBlockTimeAfterPumpStart: ", 30, 4, "hex2int", 1], # after each  pump start (dhw or heat circuit)
[" boostBlockTimeAfterHD: ", 34, 4, "hex2int", 1] # ??
],


Es ist, wie gesagt, einiges redundant, da die Werte bereits in anderen Registern enthalten. Mir ist auch nicht bei allen Werten die Bedeutung klar. Der eine oder andere Wert ist sicher hilfreich, z.B.
heatRequest - zeigt an wofür gerade Wärme angefordert wurde, also ob die Anlage im Heiz- oder Warmwassermodus ist.
supplyFanAirFlowSet und exhaustFanAirFlowSet enthalten den aktuellen Volumenstrom der Lüftung entsprechend der gerade laufenden Lüfterstufe. Dabei werden die in p37 bis p42 eingestellten Werten geliefert, so dass man daraus allgemeingültig die aktuelle Lüfterstufe ermitteln kann. Zum Beispiel mit einem UserReading
FanStage:sFan.* {if (ReadingsVal("myWP","supplyFanAirflowSet",0) eq ReadingsVal("myWP","p37Fanstage1AirflowInlet",0)) {return 1}\
elsif (ReadingsVal("myWP","supplyFanAirflowSet",0) eq ReadingsVal("myWP","p38Fanstage2AirflowInlet",0)) {return 2}\
elsif (ReadingsVal("myWP","supplyFanAirflowSet",0) eq ReadingsVal("myWP","p39Fanstage3AirflowInlet",0)) {return 3} else {return 0}


willybauss

Ich fürchte, ich komme da grade nicht dazu. Aus irgendeinem Grund hat meine THZ in 2017 ca. 15% mehr Strom verbraucht als 2016. Dem muss ich erst auf den Grund gehen.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS