2 CT100 thermostats with alarm.com - rules not working

I just finished my install yesterday so am still feeling my way around a bit. However, I setup schedules for both of my thermostats and now over 4 scheduled periods the thermostats have not changed the setpoint temps. Alarm.com shows my thermostats and I can manually control them - but the schedule is not pushing.

Could you guys please look into this for me?

Also - while at it for the sake of learning, how does this work behind the scenes? I see one of three scenarios as possible…

  1. Alarm.com sends a command to the 2gig to change a thermostat every time there is a scheduled change. The panel then sends zwave to the thermostat to manually set a new setpoint.

  2. Alarm.com sends a schedule to the 2gig. The panel stores the schedule and it sends manual zwave command to change the setpoint at every schedule change.

  3. Alarm.com sends a schedule to the 2gig, the 2gig sends the schedule to the thermostat and the thermostat runs the schedule directly.

I doubt it’s #3 as the CT100 does not have an interface to program a schedule that I’ve seen.

If it’s #1 - is it possible that the change is sent but lost? I’ve seen some posts where you push a sync for people and it fixes the rules not working situation, but what is that doing behind the scenes?

Thanks tons. So far loving the features.

Schedules are stored locally on the 2Gig controller. Unfortunately, an issue arises once in a while due to the fact that the thermostat (and lighting) time-based schedules take up the most memory and are typically the largest data transfers. I can’t say for sure that this is the issue, but it is easy to check.

First the basics:

  1. Run cell phone test.
  2. Run network rediscovery.

These two you’ve likely done, but just to make sure communication is clear and uninterrupted, running both is a good idea to troubleshoot.

After that, edit and re-save one thermostat schedule in Alarm.com and verify it is functioning. Then add the other.

Hi - yes, I did both - did it again just now for giggles. All looks clear. In fact I know that communications are working on both ADC/cell and z-wave sides because I can interact with the web site and control zwave devices manually. Take a look at this screen shot. You can clearly see that the schedule is on and the setpoint at 72 but according to the schedule should be 66. Hitting save after changing a value still doesn’t change things.

Only thing that looks odd to me is that in the zwave screen showing all devices on the panel, both thermostats are yellow wheras all the other devices are plain/blue. I’m guessing this is indicating that these are repeaters as well - but there is no way to see any additional error/message regarding why they are yellow. I’ve removed and re-added them yesterday already - they were yellow before the re-add and after.

A yellow button color indicates a malfunction. If you run the “Check Network” function on your panel, do the thermostats come back as failed nodes?

When learning in the thermostats, where were they in relation to the panel? It is recommended that zwave devices be within 6 feet or so for the learning process. (I have seen them learn in fine at a distance, but it can play a major role in successful inclusion into the network.)

Running the panel off of battery power and bringing it to the device is recommended in order to learn in the thermostat.

That’s what I thought (re yellow). The thermos were learned in place - one is about 12’ from the panel, the other is 10 feet above the first. So call it 15-17’ on angle but through a ceiling.

Here’s an issue though. I was told that the thermo won’t act as a repeater unless it’s learned in while connected to the C wire. So I can’t relearn them on battery alone as I need them as repeaters - which they seem to be doing (I have a lamp module that was unreachable until I put these on C wire).

I just checked again on zwave tools show all devices. Only one of the thermos was yellow. Thankfully the closer one. I deleted it, opened the thermo, clicked reset, added it and it was yellow again. I then did a zwave network check, went back to all devices and now yellow is gone. Too many gremlins in zwave. For the future, is there a log that is accessible, or in the advanced section a way to view why it’s yellow to troubleshoot better? 25 years in IT tells me that resetting something over and over is not a great way to fix a problem :wink:

We’ll see what happens at next temp change time too. I’ll report back.

There are a few Gremlins here and there. However, I did not mean remove the thermostats and learn them in at the panel, I said it is best to unplug the panel and run it on battery and bring it to the thermostats. Much easier to learn in devices that way. You will want to remain in close proximity to the zwave node for a couple minutes, until the device is properly discovered and labeled on your panel. Only then move on to the next.

When you have added all new devices, you will want to plug your panel back in at its permanent location (or table stand location) and run the Network Rediscovery immediately.

Wait a few minutes until the rediscovery is complete, then test.

Got it - didn’t think to bring the panel over. DOH.

I just set a temp change for the next :00 hour change. We’ll see what happens. If no go - will delete/re-add with panel in hand.

For now at least all yellow is gone - so baby steps. It’s crunchy around the edges but still cool tech.

Sadly no joy. I’m really confused though. Through ADC I can manually change the setpoint which tells me that communication works just fine. But the schedules, while turned on, don’t do anything. Since you said that the panel stores the schedule and then sends setpoint commands at the various times - I can’t see that repairing the thermostats will make any difference. After all - both ADC and the panel can manually control the thermostat. Even from the remote touch screen panel.

So what next? I can re-pair the CT100s by walking around with the panel - but again, I don’t see how that would be any different. Do you folks have additional views in ADC that can give a clue to what’s going on? Ryan mentioned (in another thread) that you can see if the C wire is powering the tstat. I’m hoping there is additional info there that you can see. If so would you please check? Also let me know if the C wire is working on both tstats?

Thanks much as always. I’m an inch short of the finish line, just this one last nagging issue and then automation greatness!


I have spoken at length with ADC reps. They are looking into this and sending some commands to re-establish the schedule. Check back and see if your thermostats begin following the schedule that was previously set. If not, the next step would be to remove the schedule, save, then re-add to force a new schedule to be sent to the panel.

Communication seems clear though, so it looks to be an issue with the schedule being saved at the panel side. You have AC working on both thermostats.

Thanks Jason - this morning I took the panel for walkabout. Deleted and re-added every z-wave device in place. Then put the panel back and rediscovered the network. One of the tstats is working correctly now - the other not yet. We’ll see in a few. I’ve also gotten intermittent ‘device reported a malfunction’ errors from two other unrelated zwave devices. It may be a range issue as well internally between the devices. I have some switches I’ll be putting in today to hopefully extend the repeater network. Will then rediscover the network and see how it goes. I’ll report back for closure to others that may read this in the future.

I just saw the second tstat is taking a schedule update. So either ADC’s reset or my re-add of the devices worked. I know they did their thing because I was in the area when the panel restarted on its own. Either way, thank you again. I’ll watch this for a while and report back if issues return/persist.


Not a problem. And yes, the more AC powered devices in your zwave network, the better the network functions.

Not only does that extend range, but also offers alternate routes should one device have interrupted communications.