Radio Thermostat (2GIG) CT100 Plus Thermostat

Forum rules

Questions about hardware that can be controlled by Indigo (but not through the interfaces and plugins listed). If Indigo doesn't support some bit of hardware you're interested in, and you don't find a 3rd Party Plugin for it, add it to this forum. Be sure to include links to as much information as you can find about it.

Note: adding it here does not mean we're going to add it - in fact it's possible one of our 3rd party developers may decide to write a plugin for it. We add hardware/features based on a lot of different factors beyond just having a request for it.

Posted on
Sat Jun 02, 2018 6:29 pm
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Radio Thermostat (2GIG) CT100 Plus Thermostat

I just got around to installing a "CT100 Plus" model thermostat I bought a few months ago.

This model was attractive to me because it reports humidity, supports Z-wave Plus, has all the usual bells and whistles for thermostats these days with multilevel heat and cool support. It was described as being a new and updated model from a company whose older models seemed to be widely used and supported in the home automation community generally (including CT100). Also it was inexpensive.

I have this device installed and connected. It reports temperature, humidity, battery level and allows control of mode and set points as I would expect. Basically, seems to work well (haven't done any extensive testing yet - I will report back again once I do).

Indigo creates two separate devices for this Z-wave device. One is type "Thermostat - General Thermostat (v2)" and behaves as I would expect - like a thermostat.

The second device is type "Multilevel Sensor - General Thermostat (v2)". It is reporting a temperature that is different from what the thermostat is reporting. Correction - I just sent it an update request, and now it seems to be showing the exact same temp as the thermostat device is reporting. I don't really understand what this device is useful for. Can anyone fill me in?

In the "Edit Device Settings..." dialog, it says Indigo does not currently have a device definition for this model. Use the button above to submit a report to us describing how well it works. ". So I am submitting this report.

As of now, the only thing I would like to see in terms of better Indigo support would be ability to configure the Z-wave configurable parameters (temp reporting threshold, humidity reporting threshold, thermostat swing temp, thermostat diff temp) - these seem to be documented here: https://products.z-wavealliance.org/pro ... 98/configs.

Here's the description:
Z-Wave Indigo Device "L1RAD Thermostat" Z-Wave Properties:
Indigo Z-Wave Version: 2.0.111
Node ID: 34
Model: General Thermostat (v2)
Model ID: 64020100
Manufacturer: 2GIG Technologies
Manufacturer ID: 0098
Protocol Version: 4.24
Application Version: 10.07
Model Definition Version: 0
Library Type: 3
Class Name: General Thermostat (v2)
Class Hierarchy: 04 : 08 : 06
Command Class Base: 40
Command Versions: 80v1 81v1 42v1 43v1 44v1 85v1 86v1 87v1 40v1 8Ev1 59v1 5Av1 5Dv1 5Ev1 45v1 60v4 20v1 70v1 31v5 72v1 73v1 7Av1
Encryption Status: Not Supported
Multi-Endpoint Types: 1:(08 : 06), 2:(21 : 00)
Multi-Endpoint Classes: 1:[5E 5D 81 87 59 31 7A 40 42 44 45 43 70 80 85], 2:[31 85 59 5E]
Multi-Instance Counts: - none -
Features: routing, battery, beaming, frequentWaking
Neighbors: 25, 27
Associations: 1:[1]
Config Values: - none -

Posted on
Sun Jun 03, 2018 11:40 am
jay (support) offline
Site Admin
User avatar
Posts: 15289
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

And you submitted the device information via that button? Just wanted to confirm.

FYI, until there's a custom definition, you can set arbitrary config settings yourself using the Interfaces->Z-Wave->Modify Configuration Parameter... menu item.

Do you know if that model supports a remote temp sensor? That might be what the second endpoint refers to. Not sure why else they'd be using a second endpoint just to report temperature.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Sun Jun 03, 2018 11:51 am
matt (support) offline
Site Admin
User avatar
Posts: 19047
Joined: Jan 27, 2003
Location: Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

In the next release of Indigo we'll have your model version set to use Indigo's CT100 device definition. That will get rid of the extra unneeded device, but we don't currently have any model specific configuration UI for the CT100. So you'll still need to use the Modify Configuration Parameter...

Image

Posted on
Mon Jun 04, 2018 2:23 pm
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

Followup:

First, I had not completed the submit process for the device, since I wasn't connected directly to my server at the time. I have now done so. Thanks for reminding me.

Nothing in the docs makes any reference to it supporting an external sensor. However, it does seem to have built in support for both temperature and humidity.

Everything I've seen so far makes it look like this is working well in Indigo. I did the extra work of pulling a replacement wire to the location so I could take advantage of having full-time 24v power, so this device now becomes an always-on z-wave repeater node in my network. That is useful for me because up to now, my z-wave network has been populated mainly with non-repeating battery-powered devices (locks, sensors).

Device can also work on batteries if you don't have a COM wire for it to use.

Posted on
Wed Jun 06, 2018 10:20 am
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

I've uncovered what is (maybe) a non-trivial problem with how this device works in Indigo vis a vis its status as "powered" vs. "battery".

This is capable of running in two distinct states w.r.t. whether it is running on pure battery power vs. connected to power via your HVAC system. The device selects one of these two "modes" to operate in based on whether it detects that it is connected to power at the time it is included with your Z-Wave controller. It reports its status as a read-only Z-Wave parameter (parameter 4, 1 byte; value 0x1 -> "powered by C-wire", value 0x2 -> "battery").

I originally did some steps out of order and had my device included as a battery device (I had left the master power switch turned OFF on my boiler). I then fixed the power problem, excluded, re-included and could then verify that the device was self-reporting as being in powered mode. So I was feeling good at that point.

Side note #1: When the device is operating in its powered mode, it still has an internal power supply (4xAA batteries). This is used to maintain the state (including clock, I'm guessing) in the event of a power outage, according to its docs. I mention this just to point out that even in powered mode, it could still be useful to have this device be able to report its battery state, even though it does not behave as a typical battery-powered Z-wave device. If push comes to shove and it turns out not to be possible to report battery state when the device is in "powered" mode, then I could live with that.

Side note #2: I happened to notice during setup that the internal clock (time of day and day of week) on the thermostat was set accurately and automatically by Indigo during the inclusion process - that's cool - nice work! (an all too rare instance of "smartness" in smarthome technology).

So my current state is the thermostat is connected. The device thinks it is in powered mode, however I see some signs that Indigo thinks it is a battery device. For example, when I go to "Interfaces>Z-Wave>Optimize Z-Wave Network... the pull-down menu of devices is partitioned into two groups and my thermostat appears on the battery-powered group.

I'm still trying to master the process of Z-wave network optimization. For example, I'm trying to see if I can use Z-Wave Node Matrix plugin to get a picture of what's on my network, but from what I can tell right now, my thermostat doesn't seem to be getting used as a neighbor node for my other devices (like door locks, etc.) That may be because of the way the signal propagation happens to work in my house. I'm open to the possibility that everything is fine, but right now my thermostat's role in my network looks more like one of my battery-powered doorknobs or multi-sensors and less like a powered device. Also, the Node Matrix plugin displays the device as a battery powered device.

Am I misinterpreting things? or is Indigo treating my powered device as a battery device and thereby hampering some of its potential functionality?

Posted on
Wed Jun 06, 2018 10:41 am
jay (support) offline
Site Admin
User avatar
Posts: 15289
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

dduff617 wrote:
Am I misinterpreting things? or is Indigo treating my powered device as a battery device and thereby hampering some of its potential functionality?


It's likely reporting battery levels to Indigo, which Indigo assumes means that it's a battery-powered device (that's a guess). However, that doesn't effect how Indigo treats the device in normal operation. The Z-Wave protocol does the routing - Indigo has no direct impact on how messages get delivered other than to request that devices rediscover their neighbors thereby rebuilding the routes on those devices.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Thu Jun 07, 2018 5:44 am
DaveL17 offline
User avatar
Posts: 4763
Joined: Aug 20, 2013
Location: Chicago, IL, USA

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

dduff617 wrote:
For example, I'm trying to see if I can use Z-Wave Node Matrix plugin to get a picture of what's on my network, but from what I can tell right now, my thermostat doesn't seem to be getting used as a neighbor node for my other devices (like door locks, etc.)

You can double-check this by exploring the configuration of the device directly. Run the following in an Indigo scripting window:
Code: Select all
dev = indigo.devices[DEV_ID_HERE]
indigo.server.log(u"{0}".format(dev))

In the log output, look for the property called zwNodeNeighborsStr (or alternatively zwNodeNeighbors). This should list the neighbors known to your thermostat. This list should agree with what's plotted in the ZwaveNodeMatrix plugin.

Code: Select all
zwNodeNeighborsStr : 2, 3, 4, 5, 7, 8, 10, 12, 13, 15, 16, 20, 21, 22, 27, 28, 29, 39, 42 (string)

I came here to drink milk and kick ass....and I've just finished my milk.

[My Plugins] - [My Forums]

Posted on
Sun Jul 08, 2018 1:26 am
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

Yet another update on my experience with CT100 Plus... (nitty-gritty setup details probably only of interest to those who own one.)

Recap: I had (incorrectly) originally done the z-wave include of my device when it was powered by batteries. Then (I thought) that I had fixed this, by excluding it and re-including it after it was externally powered. I had reason to believe that this was successful because when I read z-wave parameter 4 from the device, it reported 0x1 which means "powered by C-Wire" where previously it returned 0x0 "powered by batteries". A strange thing I noticed and reported above was that Indigo still seemed to treat the device as a battery-powered device. For example, when I selected Interfaces>Z-Wave>Optimize Z-Wave Network..., the menu of devices was partitioned into "Battery Powered" and "Continuously Powered" devices and my unit was in the former list. I chalked this up to a minor cosmetic issue caused by the fact that the unit did have batteries and was reporting a battery level even though it was getting power from the boiler. I was a bit puzzled at the fact that none of my other devices seemed to want to use it for routing.

I purchased a second CT100 Plus unit and got around to installing it today. Install went smoothly. This time, I noticed that the new device (exactly same model and firmware as the first), once setup, appeared in Indigo to be a normal powered z-wave device. So I went back and did an exclude of the old device, then reset it, and re-included it. It now also shows up as a normal powered device. So it appears that there might be something sticky within the device itself (not just in data saved in Indigo during the inclusion process) that locks the device into battery-powered mode at startup.

I'm now happy (happier), as among my reasons for going with Z-Wave thermostats was to use them as powered repeaters on multiple levels of my house to "anchor" my z-wave network so it could more reliably talk to the rest of my z-wave devices, which are mainly battery-powered sensors and locks. This seems to be working properly now with both my units. The CT100 plus is a Z-Wave Plus device and supports routing and beaming.

Posted on
Sat Nov 24, 2018 10:36 am
hchain offline
Posts: 9
Joined: Nov 16, 2012

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

I am not sure where to ask my question, so I am inserting it here:
Does anyone has the URL scheme for the iOS Radio Thermostat app?

Thanks,

Posted on
Sat Jan 19, 2019 3:04 pm
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

Here's a followup with a long-term experience report with this thermostat.

Good stuff:
  • Generally works well. Reliable communication and generally well-behaved. I don't see any crazy temperatures or set points or anything, which is more than I can say for past Insteon thermostats including the one this unit replaced.
  • Works on line power or batteries (I have only tested on line power). Acts as a Z-wave repeater when powered.
  • Inexpensive (<$100 when you can find it).
  • Has pretty good flexibility for heating system types (supports 1 or 2-stage heat and 1 or 2-stage cool, heat pump "emergency" heat, etc.).
  • It is a Z-wave Plus device - seems to have a fairly modern Z-wave chipset and worked smoothly for me with network inclusion.
  • Seems fully supported in Indigo. There are about a dozen "minor" tuning params, for which you have to use Interfaces>Z-Wave>Modify Configuration Parameter... to set, but that is fine. Indigo reports battery level. Indigo even sets the clock on the device for you when you first set up the device - cool.
  • Let's you make some useful tweaks such as minimum difference temp (between heat and cool set points when in "auto" mode), "swing" temp, etc.
  • Generally, I'd say it seems to have small refinements reflective of a 2nd or 3rd gen product. Company says this is a followup to the popular CT50, CT100 and CT101 models.
  • Backlit display, touch-screen LCD interface.

Some bad stuff -- mostly minor:
  • The touch-screen UI you see when you're standing at the device is not intuitive to me--I almost never use it, but still...
  • Humidity sensing seems responsive and accurate generally, but mine seemingly has a response "floor" of 20% - that is, reported value = min(actual_humidity, 20.0).
  • Terminal strip on the back of the device is a bit non-standard and makes mounting awkward compared to other thermostats I've used - instead of wires entering through a hole in the center of the back, they enter at the top.
  • Not widely available for purchase for some reason. I bought the first one on Amazon for about $60; second one from a home-automation supply place for about $80; now you really have to hunt to find them.

I'm not completely clear on one facet of setup in Indigo, where I am given a choice to "enable polling" or not and to set a polling interval. The device seems to support associations, so I presume Indigo gets notified any time the device state (whether sensor output or device settings) changes changes, right? Any difference between polling "off" and polling "on" (checked) but with frequency set to "only when activity detected"?

Posted on
Sat Jan 19, 2019 4:40 pm
matt (support) offline
Site Admin
User avatar
Posts: 19047
Joined: Jan 27, 2003
Location: Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

Most thermostats are good about sending out all status change information automatically, so polling turned totally OFF should be fine. The "only when activity detected" will send status request messages when Indigo thinks a module might have had a state change. This is mainly useful for dimmers that don't broadcast out a brightness level but will send out a message telling Indigo some type of activity occurred (so Indigo can follow-up and try to get the details).

Image

Posted on
Sun Jan 20, 2019 10:49 am
jay (support) offline
Site Admin
User avatar
Posts: 15289
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

matt (support) wrote:
This is mainly useful for dimmers that don't broadcast out a brightness level but will send out a message telling Indigo some type of activity occurred (so Indigo can follow-up and try to get the details).


This was some vendors (JASCO/GE, Leviton, Evolve/Linear) way around a Lutron patent on broadcasting out state changes. I believe that Lutron is probably no longer defending that patent (or perhaps they lost in court) given that ALL modern smart home devices do it now.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Jan 22, 2019 3:26 pm
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

A few days ago, I changed settings on my CT100-plus thermostats, turning off "enable polling of this device". What I observed in the few days since that change is that Indigo would some but not all of the state transitions of the state heatIsOn.

In the attached graph, you can see two changes late on 1/18. First, you can see that I lowered the set point one degree (not really relevant to this discussion). Also, you can see that the data in the bottom of the bottom chart ("Heat is On") is very consistent with the temperature data for a while. That is, when the HeatIsOn is true, the reported temperature rises, then HeatIsOn becomes false shortly thereafter (as you would expect). This consistency holds up util late 1/18 when I made the change in setting to turn off "enable polling". After that, it appears that many of the state transitions of the HeatIsOn state seem to be missed.

So this was not expected and seems to suggest that for whatever reason, running with "enable polling of this device" checked seems like the better option for me. (thanks, grafana).
Attachments
L0 HVAC Graph.png
L0 HVAC Graph.png (483.08 KiB) Viewed 1732 times

Posted on
Sat Feb 02, 2019 12:10 pm
dduff617 offline
Posts: 454
Joined: Jul 05, 2006

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

At first, I thought I had a "clean" story that the thermostat was reliably reporting heat-on/heat-off events when "enable polling of this device" was on, then when I turned it off I observed missing reports, then turned it back on and things went back to being reliable. Unfortunately, this is not the case.

After I turned "enable polling" back on (with frequency "Only when activity detected"), what I actually see are some periods that I can see all the on/off events (good) and then other long periods where I can tell am not seeing events (bad), and if I search, I can find a few periods where I can tell I am seeing a some events and missing others (one such is shown in the graph I posted previously). So something more complicated is going on with this device - maybe a bug? I don't know.

Some observations:
  • I have never observed anything less than 100% reliable communication to the device when initiating from Indigo - that is, when I am actively transmitting commands. I can send commands to change setpoint for example and they seem to work reliably.
  • I have tried re-running the z-wave "optimize" function for this device a few times. It always succeeds and seems to have converged to a stable configuration.
  • ping tests from Indigo to the device are 100% successful with consistent 16-20ms latency.
  • I have tried re-running "define and sync" (thinking that maybe an association might be getting lost or something).
  • I tried hardware-resetting the device and it seemed to snap things back to working again for a while (limited experimental data on this).
  • The device seemingly reports temp/humidity changes consistently even when it stops sending or fails to send heat on/off status. (odd)

Any ideas or suggestions?

I will try to do more experimentation and see if I can identify any causes/cures of the problem.

Posted on
Mon Feb 04, 2019 2:50 pm
jay (support) offline
Site Admin
User avatar
Posts: 15289
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Radio Thermostat (2GIG) CT100 Plus Thermostat

This is strictly my opinion, so use the appropriate amount of salt: I don't trust Radio Thermostat products. I have some prior experience with them (specifically the extremely poorly implemented WiFi one) that really leads me to believe that they are, in general, just not reliable.

As for your specific problem, it sure sounds like the thermostat isn't reliably broadcasting out status changes. As I mentioned above, the polling option shouldn't make any difference because of the patent issue I mentioned, and I believe that related specifically to lighting/switches.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Who is online

Users browsing this forum: No registered users and 0 guests