Autor Thema: THZ Tecalor (LWZ Stiebel Eltron) module support and code improvement.  (Gelesen 36804 mal)

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
If it works, I will implement your proposal.
Works with both 10°C and 55°C for all 4 parameters.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 788
Works with both 10°C and 55°C for all 4 parameters.
committed

Offline Kiteandy

  • Newbie
  • Beiträge: 2
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

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 788
Hallo andreas
-we are quite off-topic with fhem-
if you want to better understand the protocol, just start fhem with verbose 5
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
« Letzte Änderung: 20 März 2017, 20:27:10 von immi »

Offline Kiteandy

  • Newbie
  • Beiträge: 2
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

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
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?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 788
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

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
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?)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 788
Hi
Are you using the attribute firmware 5.39?
immi

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
Yes, it's there.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
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...
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 788
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 

Offline TheTrumpeter

  • Full Member
  • ***
  • Beiträge: 150
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.
« Letzte Änderung: 19 Mai 2017, 09:39:31 von TheTrumpeter »
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight

 

decade-submarginal