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

[TheTrumpeter]

If it works, I will implement your proposal.

Works with both 10°C and 55°C for all 4 parameters.

[immi]

Works with both 10°C and 55°C for all 4 parameters.

committed

[Kiteandy]

Hello,

I have a LWZ303i with Firmware 4.09 installed. Actually I am working for an implementation in Codesys with a WAGO CPU. The heatpump serial connection is connected to an internal RS232 interface of the WAGO CPU. During my work to try to implement the the communication I found your solution with fhem.
So after a few tries the connection is working fine. When I send 0x02 01 00 FC FB 10 03 followed by the acknowledgement comment 0x10 I get an reponse of "actual values" of the heatpump. All the "0xXF" commands are working fine. As far as I know is
- "02" : Starting command
- "01 00": Header for "get" ("01 80" for "send")
- "FC" : Checksum built by Header and command
- "FB" : Command
- "10 03": Footer

Now I am trying to get values like "operating mode". As far as I know the command is "0x0A 01 12".  Accoring to the previous configuration the sendstring must be "0x02 01 00 1E 0A 01 12 10 03". Unfortunately I get no response from the heatpump apart from just 0x10.

Maybe there is something wrong in my sendstring. But I don't know where?!
Please could someone help me to find the answer?

Best Regards
Andreas

[immi]

Hallo andreas
-we are quite off-topic with fhem-
if you want to better understand the protocol, just start fhem with verbose 5

Code Auswählen Erweitern


THZ_Get: Try to get 'pOpMode'
2017.03.20 20:13:02 5: THZ_Get_Comunication: Check if port is open. State = '(opened)'
2017.03.20 20:13:02 5: SW: 02
2017.03.20 20:13:02 5: Mythz start Funktion THZ_ReadAnswer
2017.03.20 20:13:02 5: THZ_ReadAnswer: uc unpack: '10'
2017.03.20 20:13:02 5: SW: 01001E0A01121003
2017.03.20 20:13:02 5: Mythz start Funktion THZ_ReadAnswer
2017.03.20 20:13:02 5: THZ_ReadAnswer: uc unpack: '1002'
2017.03.20 20:13:02 5: SW: 10
2017.03.20 20:13:02 5: Mythz start Funktion THZ_ReadAnswer
2017.03.20 20:13:02 5: THZ_ReadAnswer: uc unpack: '0100290A01120B001003'
2017.03.20 20:13:02 5: SW: 10


send         02             
wait for    10
send         01001E0A01121003
wait for    10
wait for    02
send        10
wait for    0100290A01120B001003
send        10

immi

[Kiteandy]

Hello immi,

thank you very much for your reply.
OK, the procedure was correct. I found a mistake in my checksum routine. Now the reply message is correct from what I get from the heatpump.

Best Regards
Andreas

[TheTrumpeter]

Hello immi,

p49 is limited to 11°C at the lower end in FHEM, but the heatpump allows 10°C.
Could you fix that sometimes you do another change in the module?

[immi]

Hello immi,
p49 is limited to 11°C at the lower end in FHEM, but the heatpump allows 10°C.
Could you fix that sometimes you do another change in the module?

hope I do not forget it.
the next change should be to update the help in command-ref.
it would be great if someone would make a text proposal: both in engl. and german.
im module after line 1884
immi

[TheTrumpeter]

Hello immi,

I have just seen that p75 is restricted to 0-2 in FHEM, but it allows 0-4 in LWZ404SOL.
Can you please change that?
(Maybe togehter with p49 discussed earlier this year?)

[immi]

Hi
Are you using the attribute firmware 5.39?
immi

[TheTrumpeter]

Yes, it's there.

[TheTrumpeter]

One more point as already announced:
Would you mind adding the signals "x40" and "x52" of sHC1 that are currently deactivated in your code at the end of sHC1 per default (or introduce a new attribute for it to activate it)?

I still do not know the content of these signals, but it drives me crazy to always have to modify your code after an update to activate them again 

Same applies to "x84" of sGlobal although you say "do not touch" in your code. I do not want to touch it but just to monitor it...

[immi]

Hi TheTrumpeter
I uploaded your 2 improvements of p75 and p49
thanks for your suggestions.

---

for "x40" and "x52" of sHC1:
In the middle of HC1 noGO. Too many people are relying on the order of HC1.
I could consider adding at the end, if you find an interpretation for "x40" and "x52", and if many users accepts a small increase in their logfiles size.

"x84" of sGlobal:
I remember that I commented it out because some users experienced a crash each time it was read; I didn't check if I was reading outside the register.
Also here I could consider implementing it, if you find an interpretation for x84, and if many users accepts a small increase in their logfiles size.

immi 

[TheTrumpeter]

In the middle of HC1 noGO. Too many people are relying on the order of HC1.
I could consider adding at the end, if you find an interpretation for "x40" and "x52", and if many users accepts a small increase in their logfiles size.

Of course only at the end; that's what I've initially written, maybe it was not clear enough.

"x84" of sGlobal:
I remember that I commented it out because some users experienced a crash each time it was read; I didn't check if I was reading outside the register.

I'm not 100% sure, but I think I've activated it some time ago and did not face any problem with it. I will check the log-files in the evening if it's there.

I do not know how much effort it would be to introduce a new attribute to activate or deactivate the output of "x"-parameters in the readings, but I feel that could be a good solution. It makes it easier for people who are looking for an interpretation of these values and would not bother people who do not want a minimal increase of logfile-size.

As an alternative you could introduce a new reading, "sDebug" (or something like that) which contains all the "x"-readings. But again I have no idea how much effort that would be.

[TheTrumpeter]

I still did not answer the point regarding x84 in older logs... I have it there in a log from January, seems that I activated it only for a very short time. Cannot remember any crash due to that.

[immi]

I still did not answer the point regarding x84 in older logs... I have it there in a log from January, seems that I activated it only for a very short time. Cannot remember any crash due to that.

The crash was coming in the case someone had an older tecalor. Register sGlobal is shorter for older tecalor and perl does not like when you look outside the variable.
immi