Sorry, but I’m not on TRM3 yet, so I have no experience.
My TRM2fx also has a decimal point issue.
The 2fx display shows Measured temperature with the two decimal values .0 and .5 only (?), while it shows Setpoint temperature with all ten decimals (?)
I can live with that for now, since I’m not using Sitemap for control. I’m more on “The house takes care of Itself” path without the Internet.
So far it works very well for all my 39 nodes.
Take care and enjoy your OH development.
Hi again,
I have read this post again and is still confused. Sorry if I’m a bit slow.
Can anyone please tell me/us what the status is right now for TRM3 with openHAB?
Is it working perfectly well or are there still issues?
If working, what is the Firmware version that works?
Thanks.
While OpenHAB is not using OpenZWave I am posting this as it might help another developer; I made a pull request for OZW which fixes the Z-TRM3 issue without the need for changing firmware: https://github.com/OpenZWave/open-zwave/pull/2458
Perhaps this can be inspiration for a fix in OpenHAB as well? (assuming its still is broken as this thread seems to indicate).
I recently started to use OpenHab, and have installed three of the z-trm3.
However, I’m not sure that my item configuration is optimal. Could you please share how you have defined the z-trm3 in the item file?
And where do you get the temperature graphs from?
Same problem her e I have 12x Heatit Z-TRM3, not able to change the temp from OH
I
I’ve looked into this over the last days. My understanding is that OH doesn’t necessarily adhere to the standards, as indicated from @chris .
The current OH procedure truncates temperatures below 25,5 Celsius to 1 byte values when sending them to the thermostat. Whereas the standard specified by Z wave indicates that the setpoint values should be send as per the capability report of 2 bytes. i.e. the values shouldn’t be truncated.
Previous products appear to have accepted the 1 byte values, however the standard as per the compatibility report is to send 2 byte values. Consequently OH should send 2 byte values and not 1 byte values. This causes issues with the Z-Trm3, and will likely contribute to errors in future heating products as well. As the compliance to Z-wave standards among producers increases to ensure compatibility across platforms this might become an issue.
However, this is my interpretation. Please correct me if I’m wrong.
Please also see the change request here for OpenZwave, https://github.com/OpenZWave/open-zwave/pull/2458
If you believe this to be a bug open an issue on GitHub.
Chris has access to the official specifications.
HeatIt/Thermo-Floor has made an official statement in a Norwegian home automation forum, where they claim that this is not a bug in the thermostat but in the controller. Translated, this is their claim:
This is an error that arises in some Z-Wave systems, and we see that these are often based on Open Z-Wave. The new Z-Wave standard requires that the device (the thermostat) tells the controller how to report the set point. This is not implemented in Open Z-Wave.
They go on to talk about a test report showing that the size used by the controller to set the set point does not match the one provided by the termostat with the “Thermostat Setpoint Capabilities Get Command.”
This is all based on Open Z-Wave based controllers, which OpenHAB is not, but since the problem is identical, it doesn’t seem too far fetched to suspect that it’s the same problem.
There is a pull request to Open Z-Wave containing a fix, which may be clarifying: Use interviewed setpoint byte size and precision in setpoint command by Cyberwizzard · Pull Request #2458 · OpenZWave/open-zwave · GitHub
Could this be what we are experiencing in OpenHAB as well, and if so, how soon can we expect a fix?
2 Likes
Possibly, but I know this binding is only one of many tasks Chris is working on. Time to fix would depend on the criticality for the majority of users, the complexity of the change, and his time availability.
Hi!
The last post is already one year old - do you guys already have a solution?
I had to change to TRM3, as the old one was broken…
Regards,
Herbert
No solution that I could find.
Have to set it to x.y degrees, where y != 0
I had to upgrade my trm3 with experimental FW from heatit, via OTA (zwave me)
Send an email to heatit and ask for the files, I ufortunatly do not have them anymore
To switch to the firmware with the workaround, I’d have to borrow equipment, while paying a deposit for it, and send it back by mail afterwards. Since this very much seems to be a bug/missing feature in the binding, I’m not overly stoked on that alternative. At least not yet. 
@chris have you been able to take a look at this, by any chance? If you need a refresher, take a look at my post above for why this seems like a binding issue, and not a device issue.
I couldn’t find this as a github issue, so I created one: Use thermostat setpoint byte size and precision from capabilities report · Issue #1708 · openhab/org.openhab.binding.zwave · GitHub
No - I’ve not had the chance and have no way to test this. I agree that this is a binding issue in that this was a feature added relatively recently in the specification so the binding hasn’t had this feature added.
I also struggle with this.
Exchanged a ‘dumb’ thermostat with a HeatIt Z-TRM3 and am not able to control my bath room floor in a house I have 140km away.
I thought I could fool it by setting a setpoint with a decimal point, and that value sticks, but not taken into account by the thermostat. Applies to both channel and param9.
When I set 23.0 C it is clearly some float rounding issue at play:
I think I will just swap it for a Zigbee Thermostat. Easiest solution
Also, I think the Switch channel is missing. On my Z-TRM2 (discontinued) I see this:
Hi all TRM3 users and Happy New Year,
My first TRM3 is still parked on my book shelf waiting for a working solution confirmation.
My plan was (and still is ?) to have 6 TRM3 installed to lower night temp and energy usage.
In Chris’ last entry above he confirms an OH Binding issue - with no fix in sight.
So, has the community given up on this (soon to be 2 years old) topic?
What is the best alternative to TRM3?
@chris, would it help if you had a TRM3 device available? There might be chance that some one here has one to spare for a couple of weeks if that could result in a fix
(mine are currently all in use)
I only have the previous model, but understand that you can OTA update the TRM3 to work with the old-style setpoint. This archive is what I found on a Scandinavian forum that includes the firmware and instructions:
https://drive.google.com/file/d/12c0SjjWI9fUbuif8D3CPyc40C48x77gU/view?usp=sharing
1 Like
I added the following workaround.
- created an proxy item which can be used in sitemaps …
- created a rule which adds “.1” (i use only integer values for the setpoint) to the value of the proxy item (as string, as I use jithon for my rules)
→ sendCommand to the real setpoint item with the modified value (which the is set to, e.g. 19.1 instead 19)
This way, the update of the setpoint channel is working.
1 Like
This is still a problem with the new Z-TRM6.