OpenHab 2 and Stiebel Eltron

Hi Peter,
dann leigt es wohl daran, dass ich über USB an der LWZ angeschlossen bin und nicht über die RS232.

please have a look here.
binding description
there you will find the RS232 interface links

Hi Stephan,
is there any information around on what protocol is available on the USB interface?
Do you have an link to other automation system that integrated the USB interface, e.g. FHEM?

BR
Peter

Hi Peter,
I read this article and assumed that it does not matter whether it is a usb or serial interface (RS232).
https://wiki.fhem.de/wiki/Tecalor_THZ_Wärmepumpe

The waiting time between request is in ms and is not the refresh rate in s. Se above readme in the github link
I do hase1200ms for that set forwaiting between request.

Hi Peter,

I tried the build you provided on the LWZ 303 SOL with firmware 4.39. I found that the baud rate for this firmware is 115200, which seems to be new (so far I’ve only seen people mention 9600 and 57600).

It seems to work fine in general, I get a lot of readings like temperatures and pump statuses that look correct. These values are updated regularly, like every 60 seconds (actually a bit longer but I think that’s because it waits 60 seconds after having read all values).

However, there are also a few errors in the logs.

When activating the thing, I get these messages:

Could not find valid request definition for dumpResponse,  please verify thing definition.
Could not find valid request definition for requestBytes,  please verify thing definition.
Could not find valid request definition for respondBytes,  please verify thing definition.
Could not find valid request definition for setTime,  please verify thing definition.
Could not find valid request definition for refreshTime,  please verify thing definition.
Could not find valid request definition for heatingBoosterMode,  please verify thing definition.
Could not find valid request definition for DHWBoosterMode,  please verify thing definition.
Could not find valid request definition for compressorStarts,  please verify thing definition.
Heat pump has version 4.39

When I add all channels (also the advanced ones) as items, I get these messages:

Could not find valid request definition for version#respondBytes,  please verify thing definition.
Could not find valid request definition for time#setTime,  please verify thing definition.
Could not find valid request definition for version#requestBytes,  please verify thing definition.
Could not find valid request definition for version#dumpResponse,  please verify thing definition.
Could not find valid request definition for currentValues#refreshTime,  please verify thing definition.
Could not find valid request definition for operationCounters#heatingBoosterMode,  please verify thing definition.
Could not find valid request definition for operationCounters#DHWBoosterMode,  please verify thing definition.
Could not find valid request definition for operationCounters#compressorStarts,  please verify thing definition.

Every minute, these logs are printed:

response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p40FanStageExtractAir1 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p41FanStageExtractAir2 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p42FanStageExtractAir3 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p43VentilationTimeUnscheduledStage3 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p44VentilationTimeUnscheduledStage2 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p45VentilationTimeUnscheduledStage1 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p46VentilationTimeUnscheduledStage0 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#p75OperatingModePassiveCooling 
response (00)01 00 EB 01 (04)2A AD 00 00 (08)12 10 03  could not be parsed for record definition ventilation#stoveFireplaceOperation 

Not all the channels have valid data, some are NULL:

  • All P-parameters except P37, P38, P39
  • Electrical heating stage 1 (not sure what this even is)
  • Maybe more, or maybe NULL is correct as they’ve not been set

Some channels seem to have wrong data

  • Fan speeds show as negative percent, e.g. -18% for “Extract fan speed”
  • Filtered outside temperature shows 1177.6 °C
  • Unconnected temperatures “Inside temperature” and “Flow temperature HC2” show as -60 °C (maybe that’s correct and simply what it reads, not sure)

If you don’t have time to look into these issues I’d be happy to help out. Could you push the changes you made for the build above to your Github account?
And by the way, is there a reason why you didn’t publish the binding for OH3? It looks like quite a few people are using it!

I also had the error that Stephan mentioned in the logs, three times in ca. 12 hours where it was polling every 60 seconds:

Could not get data from heat pump! java.lang.ArrayIndexOutOfBoundsException: Index 1024 out of bounds for length 1024

And quite frequently these (with retry = 1, i.e. I think the second attempt is usually successful):

org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpException: heat pump communication could not be established !no data available! -> Retry: 1

I’ll keep an eye on them, but they don’t seem to be a big problem for now. They might be caused by my setup (Pi0W RX/TX => Max232 level shifter => heat pump):

  • The Raspberry Pi Zero W that I’m using is not exactly fast, so maybe it’s too busy with other things when this happens
  • The native Java serial port implementation crashes on this architecture, so I’m using org.connectorio.addons.io.transport.serial.purejavacomm-3.0.0-20210705.jar which might be too slow
    I’ll leave it at that until we sorted out all other errors and warnings.

Hi Robert,

thanks for testing the LWZ303 SOL 4.39
please follow the instruction here , this should give more details.

Concerning the message:
the first messages

Could not find valid request definition

This should not be an issue. You can ignore them for the moment.

The rest of the message is related to the fact that i do not have such type of heat pump and cannot verify.
The principle is to now verify the individual data under debug log (see above link).
All work is done based on reverse engineering. You may fine the configuration also in the FHEM implementation. There is maybe a user that has done the decoding for the version you have.

Then we need to investigate for each value that is not properly decoded the actual value at the heat pump during read process. By that we can search for such byte value in the debug stream and adjust the channel definition.
This is basically not a complex thing to do.
I actually implemented the dumpResponse to get all values from all request.

Please follow these steps

  1. enable debug
  2. collect log message for all request
  3. manually collect from the local HMI the data from the heatpump for the values that are not correct
  4. investigate which bytes in the responds dump math the values
  5. adjust the channel definition for these data

So no problem we can get this done

Thanks Peter. I checked what they have in FHEM and it looks like there are quite a few changes that we could incorporate in your binding - they have 4.39 and 5.39 specific definitions, as well as some earlier firmware versions. I’m actually thinking about writing a small script that takes the channel definitions from fhem-mirror/00_THZ.pm at master · mhop/fhem-mirror · GitHub and converts them into your XML format.

the FHEM seems to have good support for the different versions of the heat pumps from Stiebel.
A automated conversion would be great to have.

thanks you

Hi Peter, I worked on the conversion script over the past two weeks and have some very promising results. I’m now logging all the status channels they have in FHEM for a few days without issues and I have configuration files for the other firmware versions, as well. In total that is: 2.06, 2.14, 2.14j, 4.39, 4.39technician and 5.39.

Along the way, I found the issue that caused the ArrayIndexOutOfBoundsException and fixed a bug in setting the time. Further, I needed to make some adjustments to actually make it compile. I’ve open PRs on your Github repository for these changes.

I have also added support for units so that each channel is publishing the value including its unit, and openHAB can show it and convert it to the user’s preferred format as needed.

I still have to tidy it up a little and fix a smaller issue for firmware version 2.06 and would open another PR then. We’ll have to discuss some details, in particular we might want to rethink how the channels are organized into the channel groups. Also, unfortunately, the names of all channels will be different, because I’m using the names from the FHEM definitions (e.g. “sGlobal_condenserTemp”).

Many thanks and well done.
I will have a look into it and will merge your improvemnt.

And here are all the other changes: Commits · rhuitl/openhab-addons · GitHub. It includes the conversion script. A JAR file to try it out is here: https://drive.google.com/file/d/1UNSdXRU89mE8QG1Dl002MYV1EscWaS0G/view?usp=sharing

This includes support for these firmware versions: 2.06, 2.14, 2.36, 4.19, 4.39, 5.09, 5.39, 7.39, 7.59, 7.62 - but, of course, with the caveat that I can not test any but 4.39 and some are just copies of others.

is this binding supporting THZ504 w sw 12.1.2?

No it doesn’t. It might be easy enough to add. The main reason it doesn’t work is that the binding verifies the firmware version, so it will fail at that early stage even if the configuration could work. If you have openHAB and the binding up and running, you should be able to see log output related to the firmware version. Maybe you have to enable debug logs as explained earlier in this thread to see it, not sure. If we have the debug output we can copy the 5.39 definitions and see if they work.