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.
Sorry to resurrect this thread after so long, but I’ve been running into the same issue. Seeing what @scoobydrvr did, I switched the item’s type from Number:Temperature to Number:Dimensionless, and now it works fine.
But I’d like to see how to get it to work properly with it set the “correct” way; as Number:Temperature. But I cannot get it to change (I have the same issue, it immediately switches back to the original value. I’ve tried (using the REST API) sending both e.g. 65 and 65 °F, and they both have the same effect: the actual setting switches back to the original value after sending the command.
Another thing that seems weird to me: if the channel type is Number:Temperature and the item type is Number:Temperature, if I put the item in my sitemap using the Default type, why does this not work? Shouldn’t BasicUI know it needs to send a unit as well? (Though, to be fair, maybe it is sending a unit, but it doesn’t actually work when I send a unit, so…)
Edit: I also saw this post and played around with a few things in BasicUI. I tried setting the label to Heat Setpoint [%.0f %unit%] and Heat Setpoint [%.0f °F], and neither of those work either.
The only way I can get it to work is by setting the item type to Number:Dimensionless, and sending raw values without a unit.
Ok, playing around with it a bit more. This is super weird;, I can somewhat get it to work via BasicUI with Number:Dimensionless, and the sitemap item label ending with [%.0f %unit%]. If I mash on the up or down button in BasicUI quickly, the change to the setpoint sticks. But if I just try to step it slowly one by one, it immediately reverts back to the original value.
@chris any ideas here?
For reference, here’s a z-wave debug log when attempting (and failing) to change the setpoint from BasicUI, with the item type set to Number:Temperature, and the sitemap entry as:
Setpoint item=ThermostatSetpointHeating label="Heat Setpoint [%.0f %unit%]"
The setpoint is already set to 63, and I try (using BasicUI) to step it up to 64.
thermostat-set-setpoint-fail.log (75.3 KB)
Here’s another debug log where it “works”. The setpoint is originally set to 65, and then I mash on the “up” button in BasicUI a few times. I think I get up to 69 or 70 before it settles on 66. So I “successfully” managed to raise the setpoint by 1 degree by rapidly setting it higher 4 or 5 times.
thermostat-set-setpoint-succeed-buttonmash.log (139.3 KB)
(Also I take back what I said about it working when I set the item type to Number:Dimensionless. It only appears to work, because when openHAB gets the state update back from the device, it fails to convert the number with dimensions it gets into the dimensionless value, and leaves it at whatever value I’ve set, even though the thermostat again rejected the setpoint change.)
Edit: I’m also now realizing that I’ve somehow missed @scoobydrvr’s last post where he essentially says everything I just said above. But perhaps with zwave debug logs we can get to the bottom of this…
Edit2: Using the REST API, I’ve found that I can reliably get it to work if I send the command twice in quick succession. Once doesn’t work. I also noticed that setting device parameters (I wanted to set the “swing” to 1F instead of the default of 2F) doesn’t work either; I wonder if setting it twice in quick succession would work, but I don’t think I can do that from the UI.
Edit3: For reference, I’m on openHAB 4.0.4.
I wish you all the luck in the world on solving this but I eventually just threw this thermostat in the bin. In my efforts to get this working I wired it to 24V from the furnace, tried all kinds of fiddling (as documented here), and eventually decided that either the device isn’t conforming to z-wave protocol or it’s too picky to be functional (like it needs exactly “72” and won’t accept “72.00001” or “72 F” or “72°” or similar). Adding to the fact this doesn’t seem to be supported or sold anymore, I just decided to get an Ecobee and move on with my life. Here’s hoping you get it figured out!
Looked this thread over (and your logs over) and am a little bothered that the sensor reports in degrees C. I’m assuming your parameter 1 is degrees F. Anyway my long shot suggestion is to increase the command poll to 5000 milliseconds on the UI page for the device from 1500. Try a one degree change (Like the failed) and wait to see if it holds. Is the device on power or battery?
am a little bothered that the sensor reports in degrees C. I’m assuming your parameter 1 is degrees F.
Yes, that’s right. The on-device unit setting is also set to F, and the device’s own UI does respect that.
I’ve tried sending commands in C (e.g. 20 °C), but that doesn’t work either.
I do have a different zwave thermostat at another property (ADC T-3000) that works correctly, but its sensor also reports in C, so not sure this is actually a problem.
increase the command poll to 5000 milliseconds on the UI page for the device from 1500
No change, unfortunately.
Is the device on power or battery?
Power.
Thanks! I’m probably not going to try too hard with this, and will end up returning it if I can’t get this working in a reasonable amount of time.
Adding to the fact this doesn’t seem to be supported or sold anymore…
Interesting, I just bought a new one on Amazon (US) a couple weeks ago. I wonder if the seller just had an old stock of these, but the manufacturer doesn’t sell them anymore?
Well, a quick googleing shows a few places still sell it, and the mfr has a page for it, but it looks like information that was intended for another product… I do remember contacting their support and, while I got a response, it wasn’t at all helpful. At any rate, best of luck!
Ended up giving up as well, returned the ZTS-500 and got a ADC-T3000, like I’ve used before and know works…