CT100 is slow to respond

ct100

(Sully) #1

I’m trying to do more with my CT100 thermostat, getting it to change setpoints when I’m not at home, that kind of thing. It’s kind of sluggish when changing setpoints, and it seems to miss some commands that are sent. I’m not seeing this from any other device, and range should not be a problem for it (about 15-20 feet away on the opposite side of a wall). Is this normal behavior for this thermostat?

Considering moving on to a WiFi device, but I thought I’d see if there were any tips to get this kind of device to respond better. Device is using a C-Wire. Any thoughts or help would be appreciated.


#2

Not sure of your definition of sluggish, but I have mine set to change the setpoint with Goodbye, I’m Back, Goodnight, and Good Morning routines and it changes within a few (less that 5) seconds, good enough for my purposes. Haven’t noticed it missing any commands. Also am using the C wire. I have had it completely lose communication with the hub and required a reset, but only once in about 4 years.


(Lee Florack) #3

Long answer:
I’m using a CT-100. My experience is that if I only change one setpoint, it’s pretty quick - < 3-5 seconds(?) However, if I’m changing both (my webCoRE piston always changes both setpoints), it takes a while - maybe 25 seconds or so(?).

I never really noticed this - or even looked until one morning, the heat didn’t come on like it’s scheduled to do. I went and checked the thermostat and it was sill at the lower overnight setting. I then spent some time writing a more robust setpoint piston. The new one attempts to change both setpoints as ‘scheduled’ and then checks to ensure the change anticipated was both received and acted on by the CT-100. This cycle is attempted 5 times and if still not successful, it notifies me. While rewriting and experimenting with my piston, I noticed the above timing. As a result or experimenting, I now have a 25 second ‘wait’ with a thermostat ‘refresh’ built into the setpoint attempt cycle. it’s only taken two attempts one time since then. If I had the wait be longer, it might never fail. I’m not sure. In any case, as written, it hasn’t gone past two attempts yet. What I’m unsure of is that if I didn’t have the 25 second delay and the refresh, would the thermostat eventually get there on it’s own? Maybe. I just wanted a predictable, more robust way to ensure success.

Short Answer:
Yes, It can take a while (25 seconds or so) to accurately capture and act upon setpoint changes especially when changing both the heat and cool setpoints at the same time.

If you’re interested in the piston I now use, I can post it.

Lee


(Sully) #4

Yeah, I’m always looking for better ways to code what I’m trying to do. I’m doing a 5 second wait, and that seems to work when I’m changing modes: change the old mode setpoint, wait, change mode, wait, change new mode setpoint

That seems to work every time, but if I try to change the setpoint for a mode other than the one currently set… Timings get weird and even with the 5 second wait, the one command or the other will occasionally get ignored. The 25 second timeframe may explain some of that, but it’s still just odd. I mainly wanted to make sure I didn’t have a defective unit. Misery loves company, I guess. :grin:


(Brian S. Lowrance) #5

Look up my TempThing piston on the webcore forums. It’s working for me with my CT100. It checks the thermostat every 15 min (configurable) and tries to change it again if it’s not in spec. It based inside temp based on a sensor reading outside temp to determine heat/cool mode and associated desired temp