actually the 3.2 version of the binding is still working for me
i am running the OH 3.4
Hi Peter, I have a problem with the version of the stiebel. My LWZ403 has the version 4.39, but this version is not supported in the binding.
I have a problem with updating the values. Only when I create a new item, all other items are updated. Can anyone help me?
Stiebel LWZ403 with 4.39 version, OH 3.3 with Stiebel Binding 3.2
hi ,
i tried to add the 4.39 version to the current built but was not able to verify it on my side due to lack of time.
https://drive.google.com/file/d/1x1nw7zfg5B-mN9cWGIJKQcPndHHwnTNV/view?usp=sharing
Could you give it a try?
/Peter
Hi Peter,
Thank you.
The version works. I no longer get a version error.
Unfortunately, I still have problems with updating the items. Sometimes it does it in the configured time interval, and then it doesn’t do it at all for an hour. Do you have any ideas?
please enable log in the karaf console
ssh -p 8101 openhab@localhost
log:set DEBUG org.openhab.binding.stiebelheatpump
log:tail
then you should get more logs
you can also add a log configuration in /var/lib/openhab/etc/log4j2.xml
adding an appender
<!--stiebel appender -->
<RollingRandomAccessFile fileName="${sys:openhab.logdir}/stiebel.log" filePattern="${sys:openhab.logdir}/stiebel.log.%i" name="STIEBEL>
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>
<Policies>
<OnStartupTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="8 MB"/>
</Policies>
</RollingRandomAccessFile>
and the log configuration
<Logger level="INFO" name="org.openhab.binding.stiebelheatpump">
<AppenderRef ref="STIEBEL"/>
</Logger>
hope this helps to collect mode details
Hi Peter,
I have this error:
2022-09-22 05:23:08.943 [ERROR] [atpump.internal.CommunicationService] - Could not get data from heat pump! java.lang.ArrayIndexOutOfBoundsException: Index 1024 out of bounds for length 1024
2022-09-22 05:23:10.147 [WARN ] [atpump.internal.CommunicationService] - Error reading data for FB ^@^@^@^@: org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpException: heat pump is communicating, but did not receive Escape message in initial handshake! → Retry: 1
Hi Peter
I have a question.
No matter what I set for the parameter (Waiting time between requests), a request is always made after 5 seconds. I thought the parameter controlled the requests. Actal value 60000.
Log:
2022-09-23 13:18:22.786 [DEBUG] [atpump.internal.CommunicationService] - retry request!
2022-09-23 13:18:22.787 [DEBUG] [atpump.internal.CommunicationService] - Sending start communication
2022-09-23 13:18:22.799 [DEBUG] [belheatpump.protocol.SerialConnector] - Send request message : (00)01 00 FC FB (04)10 03
2022-09-23 13:18:27.858 [DEBUG] [atpump.internal.CommunicationService] - retry request!
2022-09-23 13:18:27.859 [DEBUG] [atpump.internal.CommunicationService] - Sending start communication
2022-09-23 13:18:27.873 [DEBUG] [belheatpump.protocol.SerialConnector] - Send request message : (00)01 00 FC FB (04)10 03
2022-09-23 13:18:32.940 [DEBUG] [atpump.internal.CommunicationService] - retry request!
2022-09-23 13:18:32.942 [DEBUG] [atpump.internal.CommunicationService] - Sending start communication
2022-09-23 13:18:32.954 [DEBUG] [belheatpump.protocol.SerialConnector] - Send request message : (00)01 00 FC FB (04)10 03
hi Stephan,
the initial connection request is about to get the version information of the heat pump and derive the channels from the version templates in the thing type definitions.
If this initial communication is not working, following pull request to get monitoring and status information will not start.
In the initialization process is therefore retrying with high rate, every 5 second.
If communication is successfully established the pull rate is defined by the thing refresh configuration parameter (60s).
It seems that we need to solve first why your heat pump is not responding the first request.
You can restart the initialization process be disabling / enabling the thing.
Please verify again if physical connection is properly done.
we need to get the byte that are send back from the heat pump in the initial request.
a successful initial RS232 communication will look like this
18:03:39.161 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'stiebelheatpump:LWZ_THZ303_2_06:cc78eac2' changed from UNINITIALIZED (DISABLED) to INITIALIZING
18:03:39.192 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FD
18:03:39.193 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - set version request : FD
18:03:39.194 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FC
18:03:39.195 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - set time request : FC
18:03:39.196 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FB
18:03:39.196 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 09
18:03:39.197 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 17
18:03:39.198 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 01
18:03:39.199 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 05
18:03:39.200 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 06
18:03:39.201 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 03
18:03:39.201 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 04
18:03:39.202 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0A
18:03:39.203 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0B
18:03:39.204 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0C
18:03:39.205 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0D
18:03:39.205 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0F
18:03:39.206 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 0E
18:03:39.207 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 07
18:03:39.208 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> D1
18:03:39.209 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> EE
18:03:39.209 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request FD added to sensor/status refresh scheduler.
18:03:39.210 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for dumpResponse, please verify thing definition.
18:03:39.211 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for requestBytes, please verify thing definition.
18:03:39.212 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for respondBytes, please verify thing definition.
18:03:39.213 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for setTime, please verify thing definition.
18:03:39.213 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for time#setTime, please verify thing definition.
18:03:39.214 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for refreshTime, please verify thing definition.
18:03:39.215 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request FB added to sensor/status refresh scheduler.
18:03:39.218 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 09 added to sensor/status refresh scheduler.
18:03:39.219 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for heatingBoosterMode, please verify thing definition.
18:03:39.220 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for operationCounters#heatingBoosterMode, please verify thing definition.
18:03:39.221 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for DHWBoosterMode, please verify thing definition.
18:03:39.221 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for operationCounters#DHWBoosterMode, please verify thing definition.
18:03:39.222 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for compressorStarts, please verify thing definition.
18:03:39.223 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for operationCounters#compressorStarts, please verify thing definition.
18:03:39.223 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 17 added to sensor/status refresh scheduler.
18:03:39.224 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 01 added to sensor/status refresh scheduler.
18:03:39.225 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 05 added to sensor/status refresh scheduler.
18:03:39.226 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 06 added to sensor/status refresh scheduler.
18:03:39.227 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 03 added to sensor/status refresh scheduler.
18:03:39.228 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 04 added to sensor/status refresh scheduler.
18:03:39.229 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0A added to sensor/status refresh scheduler.
18:03:39.230 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0B added to sensor/status refresh scheduler.
18:03:39.232 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0C added to sensor/status refresh scheduler.
18:03:39.234 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0D added to sensor/status refresh scheduler.
18:03:39.237 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0F added to sensor/status refresh scheduler.
18:03:39.238 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 0E added to sensor/status refresh scheduler.
18:03:39.240 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request 07 added to sensor/status refresh scheduler.
18:03:39.242 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request D1 added to sensor/status refresh scheduler.
18:03:39.244 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request EE added to sensor/status refresh scheduler.
18:03:40.350 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'stiebelheatpump:LWZ_THZ303_2_06:cc78eac2' changed from INITIALIZING to UNKNOWN (HANDLER_CONFIGURATION_PENDING): Waiting for messages from device
18:03:41.442 [DEBUG] [eatpump.internal.CommunicationService] - Loading version info ...
18:03:41.443 [DEBUG] [eatpump.internal.CommunicationService] - RequestByte -> FD
18:03:41.443 [DEBUG] [eatpump.internal.CommunicationService] - Sending start communication
18:03:41.454 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Send request message : (00)01 00 FE FD (04)10 03
18:03:46.522 [DEBUG] [eatpump.internal.CommunicationService] - retry request!
18:03:46.523 [DEBUG] [eatpump.internal.CommunicationService] - Sending start communication
18:03:46.534 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Send request message : (00)01 00 FE FD (04)10 03
18:03:46.644 [DEBUG] [eatpump.internal.CommunicationService] - reached end of response message.
18:03:46.645 [DEBUG] [g.stiebelheatpump.protocol.DataParser] - Parse bytes: (00)01 00 CC FD (04)00 CE 10 03
18:03:46.645 [DEBUG] [g.stiebelheatpump.protocol.DataParser] - Parsed value version#version -> 2.06 with pos: 4 , len: 2
18:03:46.646 [INFO ] [tpump.internal.StiebelHeatPumpHandler] - Heat pump has version 2.06
the binding file I shared is for RS232 communication only
/Peter
1 Like
Hi Peter,
dann leigt es wohl daran, dass ich über USB an der LWZ angeschlossen bin und nicht über die RS232.
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
- enable debug
- collect log message for all request
- manually collect from the local HMI the data from the heatpump for the values that are not correct
- investigate which bytes in the responds dump math the values
- 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.