<channel-group-type id="channelGroupTypeVersion">
<label>Version</label>
<description>Version information of heat pump firmware</description>
<channels>
<!-- at least 1 channel-group with id = version must be included -->
<channel id="version" typeId="version" />
<channel id="dumpResponse" typeId="dumpResponse" />
**<channel id="refreshTime" typeId="refreshDateTime" />**
</channels>
</channel-group-type>
if this channel is not showing after update then this is most probably because the existing thing is based on y version before without that channel. Probably recreating the thing would help
A comparison operator between to identical numerical types does not workâŠâŠwhat am i doing wrong here? (The way over var xyz = abc as DecinalFomat doesnât work either)
Ok i think i found the problem.
I have absolutley no idea why my LVM was only 4 GB big on my openhab rig. Yes it was late as i sat it up but i can not remember setting it to 4GB. The consequence was hat the disk ran full. OH couldnât save any more stuff i guessâŠ. After a reboot all i did in the last 7 days is goneâŠ.
Maybe this was a reason for the incorrect parsing error. It now works with DecimalFormat.
So yeah⊠i have to re-set everythingup from newâŠ.
yes, this is all about reverse engineering a closed source heatpump
This i how it is implemented.
Here you can see how the handcheck should be done to receive data.
if data are received the it will be checked
it looks like the heat pump just send no data.
does it happen all the time or only once.
the request 17 is about the nominal setting and should send data if available.
i will improve the error message so the byte are better readable. sorry
is there a chance that you can activate some logging in the FHEM or add some debug prints in the code to see how the bytes are parsed for you heatpump?
what are the %parsinghash you use in the FHEM?
some how you define which parsingrules should be used
maybe we can try to start from their log messages
Yes, I was hoping that someone who is better at reading FHEMâs Perl code might find the solution easier
I donât get data on any channel group except version, operationCounters and currentValues. As soon as I add another item that is not queried via Request Byte 09 or FD, the heater seems to stop responding or send an empty response?
The error comes with all other values also every time. FD and 09 still work without problems.
I will try to find out more tomorrow. Maybe Iâll have luck and find the error
Good idea.
Tomorrow Iâll add log outputs at all places that might fit and connect the heat pump to the other Raspi again.
I would then contact you again with further information if I donât get it Thanks
SryâŠ.but this perl code is hard to read
I was thinking about setting up a perl env and mocking the module.
So that one can copy the HEX from the oh-log and âpasteâ it into the perl module.
added retry for register data load in case it not working at first try, now have 3 retries. (feedback hogan)
separated schedules for sensor / status and settings
add linked setting load a separated task
measure time for refresh and added to debug log
all settings are loaded at start
refresh of setting is done once per day
refresh of time done once per week
any setting change done with the binding will update the values in OH
refined debug log (feedback Pierre)
available serial ports are now as pick list in thing property
some background.
with 9600 baud the reading of data is not fast, the real data that need continues update are the sensor and status measurements. To keep them fast and simple i decided the have loading of sensor/status and settings separated.
all my setting are loaded ~ 21-25 seconds
sensor / status ~ 10-12 seconds
hope that stabilize the binding a bit and we can focus on getting the other versions in.
The FHEM code is very hard to understand and nearly has no documentation.
Hope that some of you using FHEM in the moment are able to get log messages with the parsing rules applied for data for their version and share them here
btw
does somebody has experience in the habpanel development.
i think it could make sense to have a widget for the heatpump programs , hp1 etc
what do you think?
Hi, Iâm having a LWZ504 7.59. Testing the latest jar at this moment. I was really looking forward to a binding so really happy this exist now! Thanks for all the energy and effort you and others are putting into this.
I noticed some errors:
âOperation counter heating modeâ shows me the value of the DHW
âOperation counter DHW modeâ is actually the value of the booster used for DHW
I was wondering. How can I help? Not a die-hard ITâer but I would be happy to help. Maybe I can try to match some data, position, length ⊠with values I can read from the control screen on my pump? Thatâs how I could see the errors above. Is something like that possible? Other suggestions? Iâm certainly willing to invest the time to improve this binding and helping others with the same pump. I just think I will need some help to start up the proces. Let me know!
Ow, Iâm also wondering if âamount of heatâ and âpower consumptionâ could be read by the binding? Is that something for the future?
this are exactly the things you can do.
in the binding there are xml files per thingtype in which the parsing rules for the data are described.
Yours is here. LWZ_THZ504_7_59.xml
the xml is embedded in the jar and you can replace this easy in the jar and test your own configuration.
when doing that please enable debug in the karaf console.
and then search for groups of bytes to see which data is inside that group and match it? No problem if thatâs the case, but just to be sure because itâs a painstaking proces would hate to find out later if that was not necessary
Question 2: spelling in the binding
I noticed that there are mixes English and German: for example outsideTemperatur <-> condenserTemperature. I think itâs better to do everything in English. Offcourse this will be breaking, so not sure if we want to do this. What do you think?
Question 3: New channel-group types
I think I found a new value, not existing at this moment in the channelgroup-types.xml (Heatpump -> Compressor starts). How do we want to do this? Do I pass this information to you, do I make a pull request on your fork?
1:
the data you see ate the raw byte[] you receive from the heatpump before the parse tries to decode.
i remember that 4 years ago i dumped it to excel and played around to see which data could be in .
what i can offer is to take the current xml, parse it also log the parsed data. would that help?
oh yes i am sure that there are many
if you are familiar with git you could also do a PR on my git repository.
you can also edit the file and send it to my, then i merge the changes.
thanks you
this is no problem.
if the channel groups are different per version we can make a copy of the existing channelgroup type and give it a new meaningful name. you can see similar approach in FHEM.
we can add the channe group type into the existing file of add a new file.
Thanks