Strange CT101 behavior-did not follow settings


#1

This evening, I had an episode of strange behavior with the CT101 Radio Thermostat. It had been operating correctly since installing in Hubitat and configuring. However, this evening I notied that the house was rather warm. It turns out that somehow, the thermostat got placed in "away mode" settings which meant that instead of 75 degrees changing to 74 degrees at 23:30, it was stuck on 80 degrees. Even after a hub reset it did not correct itself. It was not until I finally hit "Refresh" on the device page that it seemed to finally respond. The thermostat is connected to power so it should not go to sleep. We did have a power outage of several hours duration last week, but after the power was restored it had been operating properly until this evening.

Should I just chalk it up to a temporary glitch? I will be observing it more closely to make sure it is behaving as expected now. Hopefully, this is not something indicating that the thermostat is having problems that will require a replacement.


#2

I had that happen to my Honeywell thermostat only once. I added a separate rule to check it under certain conditions. To my knowledge this "backup" rule has never been triggered. But I sleep better.

John


#3

Hubitat does not control this setting in the driver, my guess here is that it was set via the thermostat itself...


#4

Thermostat Scheduler/Set heating/cooling schedule based on days and times (current period is Wake)/Use setpoints for Away: Set at Heating target for Away: 55; Cooling target for Away: 80.

Mode Manager/Set mode based on presence: Away: All Key Fobs leave; Home: Any Key Fob arrives.

This has worked flawlessly until yesterday evening when it didn't and the house was 80 degrees well after both of us were home. We were getting ready for bed and I noticed that the house was way too warm so I tried to figure out why the Thermostat Scheduler had not set the cooling properly. This morning it did not change to my Awake mode as scheduled. Refreshing seemed to help partially. The heating set point changed, but the cooling set point didn't. I had to change it manually.

This morning also, I decided to try Z-Wave Details/Repair Z-Wave. That process is now done and I will see if that put things back to normal.

Edit: I also used the settings to reboot both my C-4 and C-5 Hubitats to see if that would help. I had done that last night only to find that it did not change the situation. That is why I decided to try the Repair Z-Wave option.


#5

I've wrote this in other places on the forums. I have the CT-100 and the only way I could get it working correctly is to setup a 15 second refresh rule (trigger). I'm assuming it's a firmware issue with the thermostat. If I change the temp or the mode on it, the changes won't reflect back in the device page. And there are occasions when the operatingState doesn't reflect the proper status (e.g. when the heater shuts off). The refresh fixed those things. The only reason I still use it is that I can calibrate it in .5 degree F steps.


#6

The thing is that it was working fine up until yesterday. I think the 2.0.9.133 update is likely the thing that caused the change. As soon as I get a chance, I am going to drop back and see if this is indeed the cause of the anomalous behavior.


#7

Where and how did you setup the refresh rule? Might every 15 seconds be a bit taxing to Hubitat (coming from ST, I'm always worried about how busy something is... dang it)?


#8

Please expand on how you made this rule. I think I am going to have to do this since I am still experiencing this anomalous behavior. I'm about to remove the thermostat from Hubitat and re-add it after a reset to see if that will put things back to right. It may be that the power outage somehow got the thermostat's radio thinking it had to go into hibernation to preserve battery. Normally, it is powered, but when the power went out, it was running on battery for several hours.

If my theory is right, removing, resetting, and re-pairing it to Hubitat will get it working right again.


#9

@mike.maxwell I did remove the thermostat and re-paired it last night. This morning, things appear to be back to working normally. I deleted the info entries and only listed the debug and error entries below:

I did turn on debug logging. I am seeing these in my log:
dev:7692019-05-12 08:51:45.384 errorgroovy.lang.MissingMethodException: No signature of method: rtcCT101.pollDevice() is applicable for argument types: () values: [] Possible solutions: collect() (pollDevice)

dev:7692019-05-12 08:25:49.906 debugcmd:SensorMultilevelReport(precision:1, scale:1, sensorType:1, sensorValue:[2, 238], size:2, scaledSensorValue:75.0), desc:zw device: 06, command: 3105, payload: 01 2A 02 EE , isMulticast: false

dev:7692019-05-12 07:56:41.977 debugcmd:ThermostatSetpointReport(setpointType:2, precision:0, scale:1, size:1, value:[75], scaledValue:75), desc:zw device: 06, command: 4303, payload: 02 09 4B , isMulticast: false

dev:7692019-05-12 07:56:41.966 debugcmd:ThermostatSetpointReport(setpointType:1, precision:0, scale:1, size:1, value:[68], scaledValue:68), desc:zw device: 06, command: 4303, payload: 01 09 44 , isMulticast: false

dev:7692019-05-12 07:30:01.530 debugcmd:ThermostatSetpointReport(setpointType:1, precision:0, scale:1, size:1, value:[68], scaledValue:68), desc:zw device: 06, command: 4303, payload: 01 09 44 , isMulticast: false

dev:7692019-05-12 05:51:45.132 errorgroovy.lang.MissingMethodException: No signature of method: rtcCT101.pollDevice() is applicable for argument types: () values: [] Possible solutions: collect() (pollDevice)

When I paired it, it detected as "Generic Z-Wave Thermostat" which I changed to "Radio Thermostat CT101" for the Type in Device Settings. Do these entries mean anything? Should I change back to the "Generic Z-Wave Thermostat" type?


#10

Ignoring the error for the moment, does it work correctly using the ct101 driver?


#11

Greetings. My apologies for the delay. Here is the rule and the driver page:


Could you let me know what your firmware level is?


#12

Right at the moment, I would have to say no. It was working until recently. I just had the opportunity to test the Thermostat Scheduler's "Use setpoint for away" function. The heat set point changed properly at 09:35 after we left and the mode was changed to Away by the Mode Manager (key fobs had departed, but the cooling setpoint remained at the "Wake" setting (currently 75) instead of changing to the "Away" 80 temperature. I looked in the logs and the cooling set point changed from 75 to 80 at 13:19, nearly 4 hours after the mode changed to Away.

When we returned home, I see in the logs that the heat set point changed back to 68 when we arrived about 14:29. The cooling set point did not change. I manually changed it to 75 at 14:42 so the house would not continue to warm.

The strange thing is that these things worked until recently. When I changed it to the Generic Z-Wave Thermostat, I also was getting this anomalous behavior. It seemed to start with the most recent hub updates.

As for the firmware version, how would I find that?

|Create Time|2019-05-11 22:04:29 EDT|
|Last Update Time|2019-05-11 23:02:01 EDT|
|Last Activity At|2019-05-12 08:25:49 EDT|
|Data|* deviceType: 25857

Also, the dashboard operating state (heat, cool, idle) used to accurately reflect the state of the thermostat. Now, it is not in sync with the thermostat. The unit is idle, but the dashboard tile reflects that it is cooling. If I go to the device page and refresh it, that will update the status, but it is not doing so like it used to without manual intervention.

If there is any other information I can provide, please let me know. I'm open to suggestions for getting this working again. I thought removing the thermostat, factory resetting it, and re-pairing it might work, but it did not help the situation.


#13

When we debug issues, we really need to separate the apps from the drivers.
The first, and always first thing one needs to do is verify of the driver device functions first.
Do device physical events correctly update driver states?
Do driver commands correctly update the device?, and does the device then correctly report these states back to the driver?
All of these tests can be done via the device details page.
Once we have verified the driver device combination is working correctly, then we can look at apps.

Trying to do end to end app device debugging without even knowing if the device is working correctly first generally is not a fruitful endivour..


#14

Okay. I have removed the Mode Manager integration into the Thermostat Scheduler.

I would be happy to perform tests if you list the procedures I should follow. I will also disable the Thermostat Scheduler to do so.

Edit: I removed the Thermostat Scheduler app. On the device page, I changed the cooling set point from 75 degrees to 74 degrees. The AC started running but the ThermostatOperatingState did not change from idle to cooling until I selected Refresh. When the AC stopped running, the ThermostatOperatingState remained on cooling and did not change to idle until I again selected Refresh. These operations used to occur before the 2.0.9.128 I think, but definitely before the 133 update. I will do the testing you specify and report back as soon as I can.


#15

You didn't need to remove the apps, but ok.
This is simple stuff really.
When you hit heat in the driver, does the thermostat go to heat mode?, and does the driver reflect this change?, when you change the heating setpoint, same thing...
Then do the same from the thermostat, do these changes reflect in the driver state?
If you have ac, do these settings work as above?
Can you turn the fan on and off...
In other words does the thermostat control from Hubitat work properly.
If it does, then the problems you're having are with the automations, if not then the issues are with the driver device combination...
The point is you can't create a sucessfull automation unless you're sure that the device works correctly first.


#16

Test 1: Set Thermostat Mode in driver:
Select heat--thermostatMode changed to heat. Checked thermostat screen. It also changed to heat.
Select cool--thermostatMode did not change to cool. Checked thermostat screen. It changed to cool.
Select auto--thermostatMode changed to auto. Checked thermostat screen. It showed true auto.

From thermostat:
Changed mode to heat--thermostatMode changed to heat.
Changed mode to cool--thermostatMode changed to cool
Changed mode to auto--thermostatMode changed to auto

Fan on and auto from driver - operates as expected and updates thermostatMode on page
Fan on and auto from thermostat - operates and updates thermostatMode on device page

The one operation that is failing is related to the air conditioning (cooling) side of the device driver.

With the mode manager, I noticed that the heat settings changed appropriately. It was the cool settings that were not working.

With the Thermostat Scheduler, the heat settings again appeared to behave as expected, but the cool settings were not changing as specified. The Away settings were also following the pattern of the heat setting changing, but the cool settins were not changing or were changing delayed or at inappropriate times.

Since the thermostat appears to be functioning properly, the most likely cause lies in the device driver. What changed there that could have caused a regression?

p.s. Correction to my previous comment: I think the 129 version was the last that worked correctly. The 132 and 133 updates are where this behavior started. Is there a way to download an older Hubitat version if it is not available in the Update Tool?


#17

There were no changes to this driver in any of the patch releases.

I'm confused on the cooling mode changes, from the driver page you were able to command the stat to cool, and it obliged, but you say the driver didn't update its state to cooling, and yet when you physically set the stat to cool, this updated in the driver. This tells me the driver worked, but in one case the driver didn't receive an update from the thermostat, the reason for this is unknown, but it isnt the driver, otherwise the driver would not have been able to capture the cooling mode response from the device when you activated it physically.

I'm not seeing the results of any setpoint change tests.


#18

Set point changes from the device settings page seem to be working. Set point changes done at the thermostat were not reflected in the coolingSetpoint of the device settings.
Edit: I'm not sure I did that correctly though. I used the up and down arrows on the thermostat to make the changes, I did not go in to the menu and change anything there.

Edit: I re-did the thermostat setpoint and the change on the thermostat is not reflected in the thermostatSetpoint on the device settings page.


#19

This is the opposite of what happened with cooling mode. You can change the cooling set point from the driver and the device and driver update, but now cooling set point changes made at the thermostat do not update the driver?

Which set point, there are two, heating and cooling...

This isn't a driver issue, it appears that zwave frames aren't making it back to the hub.


#20

The heatingSetpoint does not appear to be having any problems. The situation is with the coolingSetpoint. I just changed it again at the thermostat from 75 to 73 on the thermostat and even after refreshing, it isn't showing as a change in the coolingSetpoint.

Edit: It is like the cooling side of the system isn't communicating back to the Hubitat although the heating side does appear to be doing so.