OH3 Remotec ZTS-500 Cooling Setpoint

I’ve had a Remotec ZTS-500 z-wave thermostat for a few years now. I used it successfully on a now-deleted installation of OH2 as well as Home Assistant. I decided to go back to OH to give version 3 a try and have run into an issue with setting the cooling (and presumably the heating) setpoint, both in the app and in rules. When a new value is commanded, the number is updated and then immediately returned back to the previous value. Log entries follow.

2021-08-12 20:26:06.666 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_Setpointcooling' received command 74

2021-08-12 20:26:06.671 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Setpointcooling' predicted to become 74

2021-08-12 20:26:06.681 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 73 °F to 74 °F

2021-08-12 20:26:08.104 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 74 °F to 73 °F

In the app, I can see the set value toggling rapidly from the new value back to the old and, if I persist enough, it might evenually accept the value (or it might not). My knee jerk reaction was that this is an artifact of converting from F to C for the sake of the thermostat and that the value in C was being rounded one way or the other when converted back to F resulting in a net change of 0 degrees, from the viewpoint of the thermostat.
I’ve also found an old thread where others were complaining of the same issue in OH2 when working with degrees F and it makes me wonder if I just need to set up a rule to convert from F to C before sending the command to the thermostat. Does anyone have any suggestions?

You appear to be sending your command with no units at all. I don’t know what the binding will do with that, perhaps nothing.
The state change you see looks like the work of autoupdate, internal to openHAB. Followed later by a superceding update from the device.

Thanks for the suggestion. It was late when I posted this last night and I forgot to mention that certain values do actually work. If I’m in the app and hammer the up or down button fast enough, it will eventually set to a value, just maybe not one one I was hoping for.

Since I’m using the web UI primarily for creating my sitemap (still haven’t figured out the fancy new OH3 UI) how can I change things to include the unit like you suggest?

There was a bug in the BasicUI setpoint element, and if I recall it behaved as you described. However, it was resolved in 3.0.2. What version are you running?

The simple way to test is to create a switch element on your sitemap with defined values, and then see if you can change between them. I did that while waiting on the bug fix.

And of course you’ll need to edit your own rules to control what they send.

1 Like

Current version is 3.1.0

What you’re proposing is to have a switch that, when, for the sake of conversation, is turned on, sends a command of 74 to the thermostat; and when turned off sends a command of 72, for example?

Yes, if you just want to test it, but don’t forget that switches can have mappings:

Switch item=Thermostat_Setpoint mappings=["71"="71","72"="72","73"="73","74"="74"]

I used something like this until the setpoint bug was fixed. But if you’re on 3.1, it shouldn’t be an issue.

I still think you want to be sending 74°F

Would I be sending the literal characters of seven, four, degree, and “F” or should I apply some of the transforms OH uses? This is just something that I’m aware of but have never really mastered…

I think I’m currently doing something like this in a set of rules I wrote to make things act like a programmable thermostat - setting the value at a certain time of day. I’ll give rossko57’s suggestion a try and see what comes out of it.

I added the degree symbol and a “F” to the rule setting the temp to 80 for an away state. This is what the log captured, first without the extra characters then with them.

2021-08-17 20:40:59.108 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_Setpointcooling' received command 80

2021-08-17 20:40:59.110 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Setpointcooling' predicted to become 80

2021-08-17 20:40:59.119 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 74 °F to 80 °F

2021-08-17 20:41:00.601 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 80 °F to 74 °F

2021-08-17 20:41:32.447 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_Setpointcooling' received command 80 °F

2021-08-17 20:41:32.449 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Setpointcooling' predicted to become 80 °F

2021-08-17 20:41:32.457 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 74 °F to 80 °F

2021-08-17 20:41:33.904 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 80 °F to 74 °F

So, a quick follow up, I connected the C wire to the furnace to get the thermostat off battery power. Unfortunately, this hasn’t changed the behavior - if I spam the up or down button of the setpoint, it will eventually take one of the higher or lower values I’m attempting to assign but with no real control. If I get the number from, say 74, up to 80 quickly enough before the value resets by the device, it will “take” one of the numbers along the way i.e.: 78.
I have rules set up to attempt to set the temperature throughout the day but none of them seem to work with a single assignment. I’m tempted to loop the rule 8 or 10 times as a work around but I hate how hacky that feels. Does anyone have any other ideas?

It’s been a few months and I’m trying to return to this problem again after losing my entire Openhab setup. I’m now running version 3.2.0. I’ve tried the suggestion @rpwong suggested above of using a switch with mappings but the behavior still persists - selecting a new value results in the following log entries:

2022-03-20 14:03:14.118 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_Setpointheating' received command 69

2022-03-20 14:03:14.129 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Setpointheating' predicted to become 69

2022-03-20 14:03:14.142 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointheating' changed from 68 °F to 69 °F

2022-03-20 14:03:14.356 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointheating' changed from 69 °F to 68 °F

I’ve tried changing the units of the thermostat to Celsius, just on a wild hare, but the same behavior is exhibited.
I’d really like to get this issue sorted out, as that was the point of getting this silly thing in the first place, but I’m starting to think maybe an Ecobee or something is the better way to go.

Is this only occurring with a sitemap? Or does it also happen with rules and MainUI?

I would also suggest setting the zwave binding to Debug, do one of the one degree changes that doesn’t stick, then switch the binding back to Info. Run the debug log through the viewer and see if there are any interesting messages as to why.

Bob

but

You’re still sending non-Quantity commands (no units) to a Quantity type Item. It i never going to work properly like that. Fix that first, see what is left after that.

Maybe the root of your problem is that you should not be using a Quantity type Item. Or perhaps you should, but have instead used an ordinary Number type.
Check the zwave Thing channel type, use a matching Item type.

Are you using an old Thing brought forward from OH2? Where channel types have changed over time, you might need to delete the old Thing and allow it to rediscover with new channels.

This was it! The Item type was “Number:Temperature”; changing it to “Number:Dimensionless” fixed the issue and the values weren’t punted back from the device. I never would have thought to try that; thank you so much for the suggestion!

That’s not right either. That is still a Quantity, a measure with units. It is to represent a proportion, like a percentage when it has units %. Or a ratio, like 5-to-1, where it gets no visible units. It’s likely to give you odd problems with charting and so on.

If your channel is of number type, use a Number type Item.

Well, I’m really not sure what to make of this… The channel states it is a Number:Temperature type. When I changed the type of the linked item to number the previous bad behavior returned; everything works as it should with Number:Dimensionless.

Have you tried using the Number:Temperature type Item, as the binding author expected?

Yes, that’s how it is set by default and is where the odd behavior is seen. As a follow-up: with the item type of Number I realized that, while the thermostat wasn’t immediately bouncing back the issued commands like it was with Number:Temperature it wasn’t actually updating the values on the device. I could set the cooling setpoint to 71 and it would read 73 on the thermostat. The only way I’ve found to make the values “stick” is to use Number:Temperature and spam the commands until the thermostat agrees to it.