2GIG CT-30 Temp and manual changes at the stat. not updating on Vera

Other Devices & Integrations Climate Control & Temperature Sensors
1

I installed a new 2GIG CT-30 Zwave and linked it to my Vera. Everything seems to work remotely execpt the temp reading updating or manual commands at the stat. updating on Vera2 . I tried playing with the polling times, but that seems not to make any difference. Sometimes it seems to update and other times I can check every hour and no change, yet the local display changed. Any Ideas? Does anyone have this stat. tied to a Vera2 without issues?

2

I just installed the CT30 and I am having the exact same problem… changes on vera are not relected on the LCD and changes through the LCD are not reported to Vera.

have you had any luck fixing this problem?

Thanks,

Eric

3

i have the same problem with the Intermatic in touch CA8900… Help please. i think the system have a bug or something.

4

@periche,

Welcome!

I don’t have this device, but are you operating it on batteries? And if so, have you tested it close to Vera (if possible)?

5

I am still having the porblem. The more I play with it, the more I know there are issues. First, I have batteries installed, but brought 24vac to the stat as they suggest. It seems that you can control the stat through Vera with no problem and it works every time. If I change the temp on Vera through Mios or iVera it reports back the new temp and controls for that temp. That is the same for the fan as well. As for making changes on the stat, they are not reflected in iVera. Neither is the Temp reading as it changes. If I go to the advanced settings and poll the device locally, going right into the Vera throught the local IP address, the temp reading updates to iVera, and will work for a few hours updating. Then it just hangs up on a reading and does not change. I have fooled with the polling times and they seem to have no affect on fixing the poroblem. Please let me know what you have found so far.

Bill

6

Could you post the [tt]Capabilities[/tt] and [tt]Version[/tt] (from the [tt]Settings[/tt] tab) of the thermostat?

7

Hello oTi,

Here are the Capabilities and Version:
Capabilities 82,220,0,4,8,6,R,B,RS,W1,|32,49,64,66,67,68,112,114,128,134,135,136,
Version 3,2,78,7,4

Bill

8

Thanks. Assuming you’re running the t-stat from 24VAC, could you try excluding it and then including it again; then check the [tt]Capabilities[/tt], and see if there is any improvement in the behavior you described?

9

We have just installed 4 CT-30s in a rental property and are noting the same issues on all four thermostats.
Specifically, the ambient temperature between zWave controller and zWave T-Stat (CT30) are not updated realtime.

We are reaching out to Radio Thermostat on this issue, as we are not sure if this is a problem with their zWave device class (radio) or if this is a problem with VERA.

PS: We are running the 3.2 hack on FW 1.1.1362

Any suggestions or pointers would be greatly appreciated.

Thanks
Sean

10

Not sure, but the association command class (133) is not in the list. So it may be that the t-stat is not designed to send instant updates; possibly to minimize communication / battery usage?

11

@smilligan,
The discussions on the HomeSeer board indicate that this is the behavior when you’re running the Z-Wave modules (ie. delayed updates, requiring Poll operations).

They allude to some differences in the behaviors of the units when Pairs “whilst powered” (non-battery, as @oTi@ indicates above) but these behavioral changes appear isolated to whether they’ll act as Relay nodes or not.

There’s a bit of a discussion about burning up batteries while playing with higher Poll frequencies (to try and make it more responsive). Here’s the thread if you’re interested in reading it:
2GIG Z-wave thermostat reliability issues - HomeSeer Message Board

12

To clarify, the posted Capabilities indicate the device is battery-powered. The association command class is not supported, which I think is required to support instant updates. So the device can only be polled when battery-powered.

I read @Flint Hill Force’s post to say that the device is currently AC powered. For that to be properly recognized, you may have to exclude and then include the device again (hence my request to do that). The Capabilities would change. And perhaps the association command class would show up (if the reason to not support it is maximizing battery life), but @guessed’s remark seems to indicate that is not the case.

13

Hello to all that have already responded to my post from 14NOV. (not updating CT30 info/readings realtime to vera)

We are using 12vDC to power the CT30 t-stats.

They were “paired” while powered from 12vDC source connected.

We have not installed batteries in the device; and are using 12vDC to power all 4 T-Stats

I am confused by some of the comments:

  1. Are you suggesting we repair (associate) while on battery power only?
  2. Is this problem ONLY happening when battery powered or externally powered?

Thanks for your support.
Sean

14

Nope; if it was paired while externally powered, then it should have correctly been registered as a non-battery powered device and thus participate in routing. If you don’t mind, could you post the [tt]Capabilities[/tt] line?

2) Is this problem ONLY happening when battery powered or externally powered?
I'm getting the impression the device just doesn't support sending real-time status updates, regardless of how it is powered.
15

oTi@:

All 4 of the CT30s were paired while on external power yet show up with Battery ICON… Hmmm… We may drop and repair later.

Of the four:
#1 had no capabilities
#2 had 210,156,0,4,8,6,L,R,B,RS,|32,49,64,66,67,68,112,114,128,129,134,135,136,
#3 had 210,156,0,4,8,6,L,R,B,RS,|32,49,64,66,67,68,112,114,128,129,134,135,136,
#4 had 210,156,0,4,8,6,L,R,B,RS,|32,49,64,66,67,68,112,114,128,129,134,135,136,

Thanks
Sean

16

Thanks for posting the capabilities. Yep, they are properly recognized as devices that do not sleep. But no association command class; so no instant reports, I think. Polling only.

17

Oti@,

Thanks for the update on the capabilities.

  1. If they show up as “devices that do not sleep” why do we get a battery icon? (Be advised that the CT30 does have battery option)
  2. I had read somewhere that the CT30s had issues with polling as well. What has been your experience as you have helped people trying to support these? Are these thermostats that VERA considers as “supported”? Also, I see that VERA does support/sell a thermostat that uses a similar uSnap zWave module, so i am assuming that VERA should be able to support these CT30s from RadioThermostat.

Thanks again for your support.

Kind Regards
Sean

18

I’d guess that depends on the logic in Vera and what the device sends as capabilities. One option could be that Vera puts a battery icon there if the device says it has a battery / supports battery level reporting etc.; possibly driven by command class 128, which, per the posted capabilities, is reported when battery-powered, as well as when externally powered. And presumably you can have a battery in there as backup?

2) I had read somewhere that the CT30s had issues with polling as well.
Interesting. Do you currently experience polling issues, while on external power? When battery powered, my guess is this device relies on beaming (to save power), so you could have polling issues if the t-stat was out of direct radio range and no beaming-capable device in between.
Are these thermostats that VERA considers as "supported"?
My impression is that MCV attempts to support as much gear as possible, so my guess would be yes, but someone at MCV would have to speak to that.
19

Theoretically Vera supports all the Z-Wave certified devices. Practically it depends a lot on how a manufacturer implements certain Z-Wave command classes, or if they implement all the required command classes.

20

oTi@/mcvflorin:

My question “Does VERA support the CT30” was mean to say:

Does anyone have reason to believe the RadioThermostat did not implement “real zwave” thermostat class? To put this question into perspective: RadioThermostat labels the CT30 w/ uSnap zWave module as a 'zWave" device. But we all know that the accreditation does not necessarily mean adherence to the standard. So, has anyone at MCV found certain messages to/from the CT30 that would imply the CT30 is not truly zWave compatible. (For example, the Trane EMS behaves flawlessly with all zWave controllers including VERA. The intermatic CA8900 is 90% as reliable as trane… But the behaviour of CT30 has proven to be unpredictable and sporadic. Does anyone have any specific message logs that show the CT30s deviate from the zWave class standard?

oTi@ : I think i understand your comment that if the device has battery capability and external power capability, it will still show the battery icon even though it has on-power capabilities. Thanks for this headsup. The question is that even if on-power will the CT30 stay awake all the time, and will it repeat?

As for polling issues; It is too early to say we have polling issues. All i can say is that we are experiencing similar problems to those detailed by Bill (Flint Air Force) posted on COT19 in this thread. We can send commands from VERA to CT30 realtime without issue. But asynchronous (unsolicited/non-polled) events that occur AT the thermostat directly can take hours to show up in VERA. This is especially true of ambient temperature readings.

I guess i am spoiled by the performance of the TRANE EMS…

So i am sure the next question is “Well, then why are you using CT30 instead of Trane”
And the reason is because the CT30 is more versatile . It has dry contacts or 24vAC capability on “Y” thereby making it a great thermostat for controlling “mini splits” that accept dry contact to “call for cool”. Also, the CT30 can be used with 24vAC, 24vDC or Battery. Making it a “one thermostat” fits all of our hotel applications. Yes, we could use relays with TRANE but this drives up the integration and support costs.

Any comments are greatly appreciated.

Regards
Sean