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

[willybauss]

Hi Willy
I see 3 cases for you: 0101, 0102 or no answer:
... maybe your should shield your serial data line, make it shorter or change the USB-Serial_Controller

OK. Sounds like a project for next winter or bad weather period. Currently I have different projects in garden etc.
Thanks for the hints.

[immi]

sets:
0B0287 is "Kühlbetrieb HK1", it's only one bit. If it's 1, then cooling is enabled, 0 is disabled.
0B0582 is "HK Temp. kühlen", it's in °C, divide the raw value by 10, then you get the physical value, ex. 0x00AF is 175d which is 17,5°C.
0B0583 is "Hyst. Vorlauftemp kühlen", it's in K, divide the raw value by 10, then you get the physical value.
0B0584 is "HK1 Raumtemperatur Hysterese",  it's in K, divide the raw value by 10, then you get the physical value.
gets:
0B0264 is the "dewpoint of HC1", it's in °C, divide the raw value by 10, then you get the physical value

Hi TheTrumpeter
I tested on my tecalor

Code Auswählen Erweitern


0A0648, 0A0649, 0B0264 --> UNKNOWN REQUEST
0B0287-950B02870000
0B0582-650B058200D2
0B0583-A30B0583000F
0B0584-A40B0584000F

it does not make lots of sense on my tecalor which has no cooling.
Nevertheless, I can add them to the list of 5.39 specialities.
Please make a proposal like you did for 

Code Auswählen Erweitern

"sCoolHCTotal"   => {cmd2=>"0A0648", cmd3=>"0A0649",     type =>"1clean", unit =>" kWh"},
immi

[TheTrumpeter]

Please make a proposal

0B0287 : p99CoolingHC1Switch, "on" sets it 0x0001 and "off" sets 0x0000
0B0582 : p99CoolingHC1SetTemp
0B0583 : p99CoolingHC1HystersisFlowTemp
0B0584 : p99CoolingHC1HystersisRoomTemp
0B0264 : sDewPointHC1

Thanks for your support in continuously improving the module.

PS: I feel the same parameters for HC2 are right after 0B0584, but as I have no HC2 I did not elaborate it.

[immi]

I committed v0.161
-speed up of initialization: your fhem start time will decrease of 5 seconds (depending on your hardware and config)
-added all new registers discovered by  TheTrumpeter (availabe only as 5.39 specialitiy)

Hi TheTrumpeter
please check the implementation, especially the range in which the register can be changed.

PS: I feel the same parameters for HC2 are right after 0B0584, but as I have no HC2 I did not elaborate it.

normally HC2 registers are in 0C0xxx

p.s. A short description of what the register does can be also helpfull for other 5.39 users

[TheTrumpeter]

Hi TheTrumpeter
please check the implementation, especially the range in which the register can be changed.

p99HC1CoolingSetTemp is possible from 10-30°C, you've limited it to 15-27°C. That's not a big issue as I do not feel anybody would use values outside the range allowed by you.
p99HC1CoolingHysteresisFlowTemp lower limit is 0.5K, not 0K. Upper limit is fine with 5K
p99HC1CoolingHysteresisRoomTemp lower limit is 0.5K, not 0K. Upper limit is only 3K, not 5K

p.s. A short description of what the register does can be also helpfull for other 5.39 users

p99CoolingHC1Switch: enables or disables whether cooling-mode is permitted for HC1 or not.
p99CoolingHC1SetTemp: set temp for cooling-mode of HC1. When HC1-temp exceeds SetTemp+HysteresisFlowTemp, compressor will start. When HC1-temp drops below SetTemp-HysteresisFlowTemp, compressor will stop. Lower end shall be reached before FlowTemp drops below dewpoint+offset (default 2K, could be changed by StiebelEltron with service-laptop). Otherwise compressor will be switched-off and restarted just after p47.
p99CoolingHC1HystersisFlowTemp: see above
p99CoolingHC1HystersisRoomTemp: cooling-mode will be released when room-temp is above SetTemp+Hysteresis and will be stopped when room-temp is below SetTemp-Hysteresis (see manual)
sDewPointHC1: calculated DewPoint based on temperature and relative humidity at display.

[TheTrumpeter]

please check the implementation

One point I do not understand...
I modified the 00_THZ-module before the update to introduce the reading sDewPointHC1. I also added the attribute interval_sDewPointHC1.
Then the reading got stored into Mythz.log.

As you did not introduce the attribute for continuously update, I did it with a notify:

Code Auswählen Erweitern

defmod Mythz.GetDewPoint notify Mythz:sGlobal:.* get Mythz sDewPointHC1

The reading got updated whenever sGlobal got updated, but it was never stored into Mythz.log.
Mythz.log is defined as

defmod FileLog_Mythz FileLog ./log/Mythz-%Y-%m.log Mythz

I do not know the reason for that.
For example I get the readings for energy-consuption with an "at". These values are stored properly.

Any idea about that?

[immi]

The reading got updated whenever sGlobal got updated, but it was never stored into Mythz.log.

As far as I remember notify does not trigger logs ("at" generates logs). Maybe they added a special attribute in the meanwhile for notify
Not sure.  look in the forum under "notify"

[TheTrumpeter]

As far as I remember notify does not trigger logs ("at" generates logs). Maybe they added a special attribute in the meanwhile for notify
Not sure. 

I already had a look into command-ref and could not find any hint regarding that.

Thanks anyway, I'll try the forum.

[willybauss]

Code Auswählen Erweitern

defmod Mythz.GetDewPoint notify Mythz:sGlobal:.* get Mythz

Is it a typo ordentlich did your really use defmod instand of define?

[TheTrumpeter]

Is it a typo ordentlich did your really use defmod instand of define?

I used "define" when defining it. Later I used "raw definition" to copy the definition into this forum.
I reads out the values properly whenever sGlobal is updated, but it's not stored into file-log.

[andre.k]

Do not trust 13:16:21 and 13:16:25. I do not think that your tecalor needed 4 seconds to answer.
It is important to find a threshold to differentiate between no answer and slow answer.

Hi immi,
I'm pretty sure my THZ sometimes takes more than 5 seconds for an answer. (I've traced the serial communication in the ser2net server)
Even when I've increased the time in my reading loop to 10 seconds I got timeouts. This is definitly too long, in production I would not go over 500ms. To solve the timeout problem I see some options:
A) just ignore the timeouts
B) a modification in THZ_Get_Communication to restart the communication (step0: resend STX). I'm already testing.
C) reschedule the THZ_GetRefresh for the timed out Get

What do you think?

[immi]

Hi immi,
I'm pretty sure my THZ sometimes takes more than 5 seconds for an answer. (I've traced the serial communication in the ser2net server) Even when I've increased the time in my reading loop to 10 seconds I got timeouts.

10 seconds to reply, your heatbunp is very busy

This is definitly too long, in production I would not go over 500ms.

completely agree

To solve the timeout problem I see some options:
A) just ignore the timeouts
B) a modification in THZ_Get_Communication to restart the communication (step0: resend STX). I'm already testing.
C) reschedule the THZ_GetRefresh for the timed out Get

A and C are easy.
B would be more elegant;

In both A and B, how can we tell the heatpump that we want to stop the comunication (with ETX or EOT, see ascii table)?

[TheTrumpeter]

2 more paramters:

0A05B3: called "EINFRIERSCHUTZ NE" in German manual, divide raw-value by 10 to get °C. Allowed range: 10-30°C, suggested name "p99defrostfreezeprotectionbooster"
0A05B4: called "ABTAUABBR." in German manual, divide raw-value by 10 to get °C. Allowed range: 0-20°C, suggested name "p99defrostcancellation"

[andre.k]

In both A and B, how can we tell the heatpump that we want to stop the comunication (with ETX or EOT, see ascii table)?

Thats a good question. I have no idea how we can stop a current communication, but we can start a new communication. We can send STX (02) and if the headpump is not yet ready it will send a NAK (15). Then wait and send 02 again until 10 is received.

Code Auswählen Erweitern

sub THZ_Get_Comunication($$) {
  my ($hash, $cmdHex) = @_;
  my ($err, $msg) =("", " ");
  Log3 $hash->{NAME}, 5, "THZ_Get_Comunication: Check if port is open. State = '($hash->{STATE})'";
  if (!(($hash->{STATE}) eq "opened"))  { return("closed connection", "");}
 
  #slow down for old firmwares
  select(undef, undef, undef, 0.25) if (AttrVal($hash->{NAME}, "firmware" , "4.39")  =~ /^2/ );
  select(undef, undef, undef, 0.001);

  my $cnt = 1;
  my $cntmax = 5;
  my $success = 0;

  do {{
THZ_Write($hash,  "02"); # step0 --> STX start of text
($err, $msg) = THZ_ReadAnswer($hash); # read 10
if ($msg ne "10") {
if (!defined($err)) { # no timeout
if ($msg eq "15") { # received NAK?
select(undef, undef, undef, 0.5);
$err = "NAK";
} else {
$err = "UNKNOWN";
}
}
Log3 $hash, 5,  "THZ_Get_Com: step0 ($cnt) ($msg):".$err;
next;
}
Log3 $hash, 5,  "THZ_Get_Com: step0 ($cnt) ($msg)";
THZ_Write($hash,  $cmdHex); # step1 --> send request
($err, $msg) = THZ_ReadAnswer($hash); # read 10
if ($msg ne "10") {
if (!defined($err)) { # no timeout
if ($msg eq "15") { # received NAK?
select(undef, undef, undef, 0.5);
$err = "NAK";
} else {
$err = "UNKNOWN";
}
}
Log3 $hash, 5,  "THZ_Get_Com: step1 ($cnt) ($msg):".$err;
next;
}
($err, $msg) = THZ_ReadAnswer($hash); # read 02
$success = 1 if ($msg eq "02");
Log3 $hash, 5,  "THZ_Get_Com: step1 ($cnt) ($msg):".$err;
  }}
  until ($success or ($cnt ++ == $cntmax)); # step1 <-- STX start of text
 
  if ((defined($err)))  {
return("THZ_Get_Com: error step1 $err", $msg);
  }

  THZ_Write($hash,  "10");     # step2 --> DLE data link escape  // ack datatranfer
  ($err, $msg) = THZ_ReadAnswer($hash); # receive data from heatpump
  THZ_Write($hash,  "10");  # --> DLE
 
  if ((defined($err)))  {
    return("THZ_Get_Com: error step2 $err", $msg);
  }
  else  {
    return(THZ_decode($msg)); #clean up and remove footer and header
  }
}


[immi]

Thats a good question. I have no idea how we can stop a current communication, but we can start a new communication. We can send STX (02) and if the headpump is not yet ready it will send a NAK (15). Then wait and send 02 again until 10 is received.

I cannot test it because i do not have the problem.
Nevertheless I expect that
1) the heatpump is not multitasking
2) if the heatpump is so busy, that it answers after 2 seconds, sending a second STX  after 0.5 seconds makes only think worse.

can you test your proposed code sending a ETX or EOT after 0.5 seconds?