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?