I’m having trouble getting my CT100 thermostat to report any value changes other than battery level to openHAB. I’m pretty sure I had it working at one point, but I mucked up my Ubuntu installation and started over from scratch. Since then I’ve seen it report the fan state and operating state exactly once.
I have tried excluding/readding the thermostat, a fresh OH setup, even resetting my z-stick g5. My only remaining thought is to try excluding, removing the batteries (currently running on C-wire + batteries), then including again. Surely even on battery power though it would report changes?
I have the controller set up as an association, and manual setpoint changes are reflected in OH. Temp, humidity, op state, and fan state changes are never reported though.
I’m at my wits end here and would welcome any ideas. I already scrapped the CT30 I just purchased because it was clear that it wasn’t going to work acceptably.
Still not sure what’s going on here. I ended up resetting the Z-stick, resetting the thermostat, completely powering off the thermostat, then adding it back on a fresh OH install. Still not operating correctly. I will occasionally get an update from the thermostat, but it is inconsistent and certainly not timely. I have seen both Operating State, and Fan State update. Sometimes both, sometimes one or the other. Never remotely close to the time that the actual state changes.
From this screenshot, it looks to me like the commands are being processed nearly 10 minutes after they are actually happening.
Here’s a zwave log for a period of several cooling cycles and a couple setpoint changes. If someone could take a look at it and see if they can make anything of it, I would appreciate it. I see some obvious changes shown, but can’t seem to find any consistency.
Th e CT100 is a little finicky. I am still not convinced I have everything working as it should be, but the manufacturer has not been helpful with getting any additional information to make it better either.
That being said, I do have it working good enough for me. Here are some thoughts:
Yes, if it is powered from the C wire, by all means reset it and include it again to get the updates more often. This also makes it a z-wave repeater for other devices, and the radio in this thing is one of the best of any z-wave device I own. I have two of these thermostats, and they are connected to just about every other node in my network. Also, if you do use battery, allow it about 12 hours to settle down and function better.
To get information from the device more often, you need to set up polling. I have polling set up on mine to get data every 60 seconds, and this seems to work pretty well.
Your logfile snippet shows that you are sending a setpoint and it is being updated right away. The later entries don’t seem to make much sense unless something else was continuing to send 74.
My understanding is that the thermostat should be sending updates to the controller when values change without the need for the controller to poll the device. Indeed this is the case because, as I said, I see the operating state and fan state update occasionally, and I have no polling set up.
The problem is that the updates are seemingly random. They do not happen with ever state change (not even close actually) and the changes are reflected several minutes after they happen.
Is it possible that there are range or signal issues even if the node never gets marked as dead?
I’m fairly certain that it was operating as expected when I first set it up, including temperature updates. Given that I have been unable to get it to since, however, I’m begging to wonder if I’m crazy.
If this is the case, and I would hope so given it supports association groups, make sure you have the controller in the association groups to make sure anything the thermostat sends has the controller as a destination. Even with this set though, I did not get consistent updates without polling, and never have. I had to set up the refresh in the 1.x binding as well.
That is disappointing. If I knew it was going to require polling, I would have just went with a wifi 'stat and avoided a layer of complexity and point of failure. With the way mine is sending occasional, and often incorrect status updates, I imagine that even with manual polling I would end up with inconsistent states at least part of the time.
I do have the controller set as an association, so manual setpoint changes are reflected in OH fine. It’s interesting that the CT30 has some configuration parameters available, including the temperature reporting threshold. Unfortunately, I could not even get setpoint changes from OH to work with the CT30. It would receive the command, process it, then immediately revert the setpoint back to what it was.
@xsnrg, do you have CT100 or CT100 Plus? I just recently installed 21 CT100s and it looks like they do not support association groups, only the CT100 Plus.
This was quite some time ago, and I did not see it, apologies. I have, as far as I know, just the CT100s. How do you tell? Perhaps this is why I needed polling.
Don’t remember when they started working, but they have been working for a good while now. I am no longer pooling and the stats update openHAB when state changes.
Ironically, my ct100s stopped working. They just did not report anything in at all. I pulled the latest snapshot and one came back, but isn’t updating very often, and the other one I had to delete and re-add. It is now back, but reports everything in C instead of F even though I have tried changing it to F in both PaperUI and Habmin. They are both C-ware hot devices.
