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.
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:
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
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:
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.
Don’t really know what “this” means in this context. Probably should open a new thread.
On quick review, the device (Z-TRM3) uses a V3 version report of the Thermostat_Setpoint CC, but the binding only supports V1 & V2. I do not see that changing in the near future. However, by Silabs specifications the device should be backward compatible with V1 and V2, so I’m guessing the HEATIT firmware update mentioned above fixes that. Also I couldn’t see (on my quick look) how adding a decimal works, but hey, don’t argue with success .
Anyway, assuming the first post is correct in that parameter 9 works (parameter 22 in the case of the Z-TRM6), another workaround is to create an endpoint (i.e. channel) for that parameter in the Configuration CC in the ZW device DB. You would have to deal with a Number item 10x larger and not a Number:Temperature, but it should work.
As an alternative to waiting, if anyone wants to test using the parameter (9 or 22) as a channel for an item to set the heating setpoint (ECO could be added later), I marked up a couple of XMLs with that functionality that can be added to your ZWave jar.
Z-TRM3 ztrm3_0_0.xml (20.0 KB)
Z-TRM-6 trm6_0_0.xml (28.3 KB)
The procedure is here. The files are located in /OH-INF/thing/thermofloor/
Hi guys. I have some openHAB 4.0.2 with the Z-Wave binding and an Aeotec Z-Stick 5 USB on a Raspberry PI 4 with 4GB RAM, which works fine with all the devices… except several Z-TRM3.
I am not sure here if the issue should have been solved in openHAB 4.0.2 or not.
I noticed som decimal story, but I am not able to see this anywhere.
Hi,
In my world the decimal story goes like this:
TRM3 setpoint values must be decimal and the decimal value must range from 1-9 NOT 0. Nor can it be 00 (integer).
So, your Setpoint value should read 24.1.
Yes strange, but works for me.
Bjorn
Thank you, @satman, for sharing the hint to add decimal digits higher than 1. That works in that way, that openhab now sets the new value for the setpoint (and not jumps back, like it does when sending without that addition) …
… but my problem is, that my thermostat (Z-TRM6) does not receive the new value or at least does not switch to the new value.
Did you also notice such a behaviour and have a further hint for me to get this working?
I remember that TRM3 Setpoint Items were defined default as Number:temperature, which I understood to be a character string. I therefore defined my Setpoint Items as Number only.
Clarification: TRM3 Setpoints accept all decimal values x.1 to x.9 but not x.0. My experience.
From the Debug everything looks good and timely. There is a “SET” and a subsequent “GET” (actually 2) that confirms the SET.Is this a new device that has never worked or one that worked before and stopped? Is the MODE on HEAT? Have you checked all the parameters to make sure the setpoint is looking at the right temperature sensor (floor or internal) and any offsets, etc.?
.
Thanks a lot HaKuna. 