-
Made 2 Pull Requests (1 “fix” for a wrong label, 1 fix for the LWZ 504 thing)
-
I’m searching for Amount of Heat (HTG, DHW, Recovered via Ventilation) and Power Consumption (HTG, DHW). I can not find the values if I enable the “Dump heat pump response”. I suspect that not everything is dumped and that it is coded which requestbytes are requested? Can we add more? Don’t know if it’s overkill to dump each and everyone?
-
In the LWZ 504 thing, we do requests to requestByte “17” to get the “Settings nominal values”. They all don’t work (the response of 17 is only 5 bytes), so I guess for the 504, that information is stored somewhere else. Probably linked to what I said here above.
Same for me.looks like something is wrong.should be string type.
In general i see that paperui has some issues, e.g some temperatures are from same type but presented differently.
Will investigate further
I am not an expert on the heatpump. I know that some version do have 2nd heat circuit. Have investigated in the fhem code and could find tthe byte to send?
Here is the list of byte is verify in the dump. If you find new we can add it there.
Thanks for th PR , will merge it
i fixed the version string issue. find version 10
change log:
- fixed version string presentation
- merge fixes from Dries
Concerning the bytes for the debug responds.
This is what is in the FHEM
my @numbers=(‘01’, ‘09’, ‘16’, ‘D1’, ‘D2’, ‘E8’, ‘E9’, ‘F2’, ‘F3’, ‘F4’, ‘F5’, ‘F6’, ‘F8’, ‘FB’, ‘FC’, ‘FD’, ‘FE’, ‘FF’);
here what is in our list
public static final byte[] DEBUGBYTES = { (byte) 0x01, (byte) 0x03, (byte) 0x04, (byte) 0x05, (byte) 0x06,
(byte) 0x07, (byte) 0x09, (byte) 0x10, (byte) 0x16, (byte) 0x17, (byte) 0xD1, (byte) 0xD2, (byte) 0xE8,
(byte) 0xE9, (byte) 0xEE, (byte) 0xF2, (byte) 0xF3, (byte) 0xF4, (byte) 0xF5, (byte) 0xF6, (byte) 0xFB,
(byte) 0xFC, (byte) 0xFD, (byte) 0xFE, (byte) 0x0A, (byte) 0x0B, (byte) 0x0C, (byte) 0x0D, (byte) 0x0E,
(byte) 0x0F };
feel free to propose new bytes to add.
Had a first look into the log from pierre
Basically the binding should work, but we may need to adjust the binding to send different request messages. It looks like it is not a single byte to be send,instead a byte array.
Also itlooks like individual value can be read.
Is there chance that you can add some debug messages in perl to show the decoded value and the parameter of the parsing in the log?
Hi Dries,
with some values (operation counters) for our heat pump the designations are not correct with me yet. Can you confirm this?
operationCounters#coolingMode = German: Elektr. NE Heizen (I think “heatingBoosterMode”)
operationCounters#heatingMode = German: Verdichter WW (“DHWMode”)
operationCounters#compressorA = German: Verdichter Heizen (“heatingMode”)
operationCounters#DHWMod and operationCounters#DHWBoosterMode return the same value for me.Corresponds in both cases to “Elektr. NE WW” (DHWBoosterMode)
operationCounters#heatingBoosterMode returns 0 hours for me. But this is not true and probably corresponds more to the coolingMode.
@ kreutpet: I’ll expand the log this evening and get back to you.
Here the extended log and my modified THZ file. The new entries are marked with (OH)
I hope it helps 
26.05.2020_fhem-2020-05.log (442.4 KB)
26.05.2020_Mythz-2020.log (15.3 KB)
26.05.2020_00_THZ.txt (140.7 KB)
super :-), well done, with this info it will be more easy
i will investigate how to adapt the code to also work with byte array as request .
As my heat pump is only working with single byte as request we need most probably some iteration to get this done.
i guess none of you have experience with the eclipse IDE , do you?
Unfortunately not really.
I get to compiled your code and start a debug process. That’s all I have done with Eclipse.
Normally I work with Visual Studio and C#
well that could be enough for trouble shouting and solve simple things
i do have 
the main problem is that im quite short on time atm.
Hi @kreutzer_peter, @Zony
Yes, there were certainly some designations not correct within the operation counters. I tried to fix them. Can we first be sure you are on the last test jar? (I failed to restart my binding in the beginning, thinking I had the new version but was still seeing the old thinks) And be sure you have a LWZ 504 too?
A few days ago I certainly fixed DHWBoosterMode and DHWMode, the numbers I see now in PaperUI, are exactly the same as on my Stiebel control screen.
You are right that heating mode is incorrect, don’t know how I missed that
Cooling mode is more difficult for me as my cooling has never worked for the past year I live in my new house, so those numbers are still zero. Hard to make a distinction than
I’m not a developer but I have some IT skills enough to save me now. I succeeded in building the jar myself yesterday, was thinking about expanding the debug responds and try to match more and more data via Openhab logs. Your log files will help!
Hi Dries,
I use the version 2.5.4.202005250811 (from 25.08.2020). The date corresponds to version 10 of kreutzer_peter
I also had to create my items new because the names have changed So I assume that your adjustments are included.
Yes I also have a LWZ 504 with firmware 7.59
I rebooted the whole system (Raspberry) again last night.Because of this the value for “Verdichter WW” (DHWMode) has changed again and is now correct.
Now the following values are still wrong:
compressorA = heatingMode
heatingMode = coolingMode
coolingMode = heatingBoosterMode
Here is a screenshot of the values (are slightly different from yesterday evening)
CoolingMode is also still on 0 for me. I have not used it yet. But the only value that is set to 0 is relatively easy to assign
here a new version which is enabled to define requests with multiple bytes.
version11
could you try to define a data request for you heatpump version that is based on multiple bytes request.
e.g. programHC1_Tu_0 with “0B1420” ?
for those like to debug you can use my branch on github
I tried v11 of the binding but it seems that i have problems getting values from my pump.
The values for outside temp and P07 (e.g.) are NaN in PaperUI and in VSCodes they are NULL.
Here is the log.txt (17.5 KB)
I deactivated and activated the thing a few times.
hi hogan,
as mentioned my former post , with the pull request from Dries some channels have updated names.
you need to remove the thing and create it new as the channels in the already instantiated thing do not match. see here post 15
e.g.:
2020-05-30 17:34:31.356 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Data outsideTemperature has value 15.7
2020-05-30 17:34:31.357 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - For channelid outsideTemperature no configuration found. Review channel definitions.
hope that helps resolving
I tried to make some changes locally in the 504 definition and build the jar myself. I succeeded but if I’m testing at this moment, I get several errors. I thought I messed something up, but even without my changes, I’m stil getting errors.
I’m building based on your branch, merged with the latest changes from the 2.5.x branch from the official fork, and on the 2.5.6 release. Do you think that’s something you can try too?
2020-05-31 16:52:04.037 [hingStatusInfoChangedEvent] - 'stiebelheatpump:LWZ_THZ504_7_59:123eea99' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2020-05-31 16:52:05.210 [hingStatusInfoChangedEvent] - 'stiebelheatpump:LWZ_THZ504_7_59:123eea99' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2020-05-31 16:52:05.252 [DEBUG] [iebelheatpump.internal.ConfigLocator] - Parsing heat pump configuration file LWZ_THZ504_7_59.xml.
2020-05-31 16:52:05.342 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FD
2020-05-31 16:52:05.345 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - set version request : FD
2020-05-31 16:52:05.349 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FC
2020-05-31 16:52:05.352 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - set time request : FC
2020-05-31 16:52:05.364 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> FB
2020-05-31 16:52:05.369 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 09
2020-05-31 16:52:05.372 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Request : RequestByte -> 17
2020-05-31 16:52:05.377 [INFO ] [pump.internal.StiebelHeatPumpHandler] - Request FD added to sensor/status refresh scheduler.
2020-05-31 16:52:05.381 [WARN ] [ng.stiebelheatpump.protocol.Requests] - Could not find valid request definition for dumpResponse, please verify thing definition.
2020-05-31 16:52:05.385 [WARN ] [ng.stiebelheatpump.protocol.Requests] - Could not find valid request definition for setTime, please verify thing definition.
2020-05-31 16:52:05.388 [INFO ] [pump.internal.StiebelHeatPumpHandler] - Request FC added to setting refresh scheduler.
2020-05-31 16:52:05.392 [WARN ] [ng.stiebelheatpump.protocol.Requests] - Could not find valid request definition for refreshTime, please verify thing definition.
2020-05-31 16:52:05.398 [INFO ] [pump.internal.StiebelHeatPumpHandler] - Request FB added to sensor/status refresh scheduler.
2020-05-31 16:52:05.405 [INFO ] [pump.internal.StiebelHeatPumpHandler] - Request 09 added to sensor/status refresh scheduler.
2020-05-31 16:52:05.409 [WARN ] [ng.stiebelheatpump.protocol.Requests] - Could not find valid request definition for compressorB, please verify thing definition.
2020-05-31 16:52:05.412 [INFO ] [pump.internal.StiebelHeatPumpHandler] - Request 17 added to setting refresh scheduler.
2020-05-31 16:52:05.431 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Initializing stiebel heat pump handler 'stiebelheatpump:LWZ_THZ504_7_59:123eea99' with configuration: port '/dev/ttyUSB1', baudRate 115200, refresh 60. Available ports are : /dev/ttyUSB1, /dev/ttyACM0, /dev/ttyAMA0
2020-05-31 16:52:05.451 [WARN ] [ng.stiebelheatpump.protocol.Requests] - Could not find valid request definition for version#dumpResponse, please verify thing definition.
2020-05-31 16:52:05.456 [DEBUG] [atpump.internal.CommunicationService] - Loading version info ...
2020-05-31 16:52:05.456 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Found valid record definition in request (00)09 with ChannelID:operationCounters#heatingMode
2020-05-31 16:52:05.458 [DEBUG] [atpump.internal.CommunicationService] - RequestByte -> FD
==> /var/log/openhab2/events.log <==
2020-05-31 16:52:05.458 [hingStatusInfoChangedEvent] - 'stiebelheatpump:LWZ_THZ504_7_59:123eea99' changed from INITIALIZING to UNKNOWN (HANDLER_CONFIGURATION_PENDING): Waiting for messages from device
==> /var/log/openhab2/openhab.log <==
2020-05-31 16:52:05.455 [DEBUG] [pump.internal.StiebelHeatPumpHandler] - Could not find valid record definitionrequest in channel for: version#dumpResponse
2020-05-31 16:52:05.461 [DEBUG] [belheatpump.protocol.SerialConnector] - Interrupt serial connection
2020-05-31 16:52:05.465 [DEBUG] [belheatpump.protocol.SerialConnector] - Close serial stream
==> /var/log/openhab2/openhab.log <==
2020-05-31 16:52:06.548 [DEBUG] [belheatpump.protocol.SerialConnector] - Disconnected
2020-05-31 16:52:06.550 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
at org.openhab.binding.stiebelheatpump.protocol.DataParser.addDuplicatedBytes(DataParser.java:455) ~[?:?]
at org.openhab.binding.stiebelheatpump.internal.CommunicationService.createRequestMessage(CommunicationService.java:514) ~[?:?]
at org.openhab.binding.stiebelheatpump.internal.CommunicationService.readData(CommunicationService.java:202) ~[?:?]
at org.openhab.binding.stiebelheatpump.internal.CommunicationService.getVersion(CommunicationService.java:81) ~[?:?]
at org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpHandler.getInitialHeatPumpSettings(StiebelHeatPumpHandler.java:496) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
hi dries,
actually i am not sure what can be the issue.
on my productive environment i am running 2.5.3.
i have manually installed and would need to update here first.
also i am not sure what is the version i do have on the development environment.
I would actually prefer to start here and merge the updates from official master to my branch
i know that i create my branch from the 2.5.x , so i guess doing that would bring me in my development environment to the level of 2.5.6
As i am not a software engineer and not use git on daily base i need to first have a look how to get this done
is this a rebase i need to do on my branch?
Found this java9 .
It is related to moving from java8 to 9
Let me try to find a solution today
I am using this version in productive and development (java8)
java -version
openjdk version “1.8.0_242”
OpenJDK Runtime Environment (Zulu 8.44.0.11-CA-linux64) (build 1.8.0_242-b20)
OpenJDK 64-Bit Server VM (Zulu 8.44.0.11-CA-linux64) (build 25.242-b20, mixed mode)
i understood that OH2 is still recommending java8 and is preparing to java11 , which will become LTS
So i use the latest snapshot of oh (2.5.6).
I removed the items, the thing, deleted the json channellinks, deleted the binding and did a reboot of the whole system. After that i placed the binding back in and configured it.
I still hae the problem, that the nominal Values are not available.
Here is the log.txt (20.5 KB)