Z-Wave Thermostat Not Following Schedule

My Trane thermostat has stopped following the set schedule through Alarm.com. It is confirmed as connected as I can change the temp via Alarm.com.

I tried to turn the tstat off then on and then I tried to uninstall and re-install the thermostat, neither of which did much good.

Then I went into ADC to re-build the schedule but it still won’t work properly.

Any other steps/help would be greatly appreciated.

Thanks!

I have the EXACT same issue! Trane thermostat worked for ages, then noticed a week or so ago it wasn’t following the schedule. Confirmed the internal schedule is off, have rebooted, have un-enrolled and re-enrolled, rebuilt schedule, etc. but still not following schedule. I can control the thermostat fine via Alarm.com app/desktop so the Z Wave connectivity isn’t an issue. It just isn’t receiving the schedule that is set on Alarm.com.

I have the EXACT same issue!

It looks like this was a thread started to assist with your issue :wink:

It looks like this is a brand new suretyDIY account connected to ADC yesterday, so this would actually be regarding a brand new schedule set up in ADC, regardless of having the thermostat for a while.

Are you instead referring to a different account, maybe?

Also I think one thing that may be of confusion here is that when you have two back to back thermostat schedule periods with the same temp scheduled, the second one there will be no change occurring even if the thermostat was manually switched in between. Likewise when you first send a schedule to the thermostat it will not immediately change. The first time the schedule would change the temp is the first time it would at the tstat.

In other words, if today’s schedule is the following:

8am: 70. → 2pm: 70 → 9pm: 72

and you saved the schedule at 8:30 am, the temp would not change at all at the tstat until 9pm.

Also, setting the thermostat to be at 70 at 8am, then 70 at 2pm is no different than not having a 2pm section. The schedule temp must actually change from the prior schedule section in order for it to be processed.

Thanks Jason, I had to double check the post to make sure I hadn’t written it myself:)

I had this issue on Alarm.com with my previous provider (Frontpoint). It’s not something new with my new account with you guys (although researching the issue is how I found out about you, which is great)

Anyway, I understand how the settings work, and how they won’t change when schedules are the same back-to-back. I’ve been using Z Wave thermostats on Alarm.com for 8 or more years and know how they work. Something has happened in the last couple of weeks that has stopped the schedules from being sent to the thermostat.

I’d be happy to adjust the schedule to any values, or you can feel free to do it, to confirm the issue. I’m at home now and happy to assist with any testing.

I see, alright, probably the best way to go about this would be a full rules rebuild sent to the panel. Can you let us know when you have the schedule set up the way you would normally set it up?

We will then have ADC push a command to resync the system and rebuild all device rules to ensure the panel is sending exactly what it is supposed to.

Thanks, I just set up a simple schedule to change at 1PM (it’s 12:38 MST now) to 85 degrees. Right now the thermostat is at a set point of 76, which is where it stays until I make a change at the panel or through Alarm.com.

I’d expect the set point to change to 85 at 1PM if things were working correctly.

As this requires ADC to perform a command which can take 10-15 minutes to complete, that is probably not a workable test. I would suggest moving that change back to 1:30 or 2.

No problem, I just changed to 2PM.

Thank you for confirming. Once the commands have been sent and confirmed acknowledged by the panel we will follow up here.

This is sort of a nuclear option which would resolve a handful of various issues.

As an aside, did you add any devices or make any other changes around the time it stopped working?

I have a lot of Z Wave devices (over 20) but nothing new when it started happening. I did have a light/dimmer that was inoperative and couldn’t be unenrolled, although that device was sitting out there for months in that state before this issue cropped up a couple of weeks ago. (I did have you remove that orphaned device yesterday)

I was hoping with my migration to a fresh Alarm.com account (from Frontpoint to you guys), that it would go away, but no such luck. This makes me wonder if the issue is buried in the panel itself. I’ll report back after I get word from you the “nuclear option” is complete.

I was hoping with my migration to a fresh Alarm.com account (from Frontpoint to you guys), that it would go away, but no such luck. This makes me wonder if the issue is buried in the panel itself. I’ll report back after I get word from you the “nuclear option” is complete.

It is definitely strange that the issue should persist with a new account and new schedules, but that does suggest a local device process failure of some kind. It is why I jumped to this option first.

Looks like all those commands have been acknowledged at this point, so check around the scheduled time (give or take 5-10 minutes or so) for a Tstat change to be sure. Let us know what you see.

Unfortunately it still isn’t following the schedules. No problem accepting commands to change temp but still not picking up on the schedules. I unenrolled and reenrolled too but that didn’t change anything.

Absent any other ideas I suppose I should look into a new thermostat. I’m a bit worried that something would be hosed up elsewhere, but guess that resynch/rebuild on the panel should have cleared things out. Any thought of doing that same action when the thermostat is unenrolled? When it was done this time the thermostat was on the account, but would it possibly change anything to do it when unenrolled, then reenroll after it’s complete?

Have you tried resetting the thermostat to factory defaults before re-installing?

Rules cannot be rebuilt if the thermostat is not connected to the panel, so there wouldn’t be any help there, but it may be good to delete the thermostat and factory default it. Any luck after factory default and making sure internal schedules are disabled again?

Yea, I tried that yesterday. I unenrolled it, set to factory defaults, re-enrolled it, turned off internal schedules, but same situation. Seems to just hold at set point, whether that is set manually at the device or via alarm.com app/site. Never picks up the schedules (and also won’t honor the Smart Away temp setting when armed away)

I can’t imagine it’s the device itself, especially since it is working Z Wave-wise, but I guess that’s all that’s left.

One interesting thing I just noticed. I went through the following steps:

  1. Un-enroll
  2. Restore to factory defaults
  3. Remove thermostat panel from power for 10 minutes
  4. Reconnect panel
  5. Delete internal schedules
  6. Enroll

At this point, thermostat connected, receives the proper date/time. Everything looks good. The thermostat is in mode=off by default, but when I turn on by putting it on cool (using the app), the set point is set to 80 degrees. I made no changes to the default schedule which is provided on Alarm.com after a new thermostat is set up. The default schedule is 77 sleep, 78 away, 75 home. Right now it should be on the away 78 temp. Where is it getting 80? There’s no 80 on either the cool or heat schedule.

I had noticed this before and didn’t think much of it, but now I’m wondering if it’s meaningful.

At this point, thermostat connected, receives the proper date/time. Everything looks good. The thermostat is in mode=off by default, but when I turn on by putting it on cool (using the app), the set point is set to 80 degrees. I made no changes to the default schedule which is provided on Alarm.com after a new thermostat is set up. The default schedule is 77 sleep, 78 away, 75 home. Right now it should be on the away 78 temp. Where is it getting 80? There’s no 80 on either the cool or heat schedule.

Alarm.com is displaying the current set point of the thermostat, not the set point of the schedule.

The set point is off because when you first set up a schedule it does not immediately change the tstat - only during the next scheduled change.

However, in this case you are saying the schedule never works, so ADC would only display a temp matching the schedule if you manually set the Tstat to that temp.

Understand on the schedule. One way I’ve been able to more quickly verify the schedule isn’t being followed is by arming away and seeing that the set point doesn’t change to the Smart Away setting. (I do have Smart Away enabled) Under normal operation, the set point is immediately changed to the Smart Away temp. when the system is armed away and immediately set back to the normal schedule when the system is disarmed. Anyway, I can see the expected temperature changes doing these actions are not being made to the thermostat.

All of this used to work fine until a couple of weeks ago. My guess is that there is either 1) A problem with my thermostat or 2) A bug introduced by some alarm.com update that changed how it interacts with this Trane thermostat. The OP is posting the same issues as me and mentions Trane as well.

Since there’s nothing I can do to further investigate the latter, I’m just going to order a new thermostat (the ADC-T2000. Not sure I want to try another Trane now)

Will report back on that next week and keep an eye on this thread for any further similar reports. Thanks for your help trying to get this sorted.

The OP is posting the same issues as me and mentions Trane as well.

The OP is just an internal account used by suretyDIY to post technical support questions.

The original post is actually in direct reference to your original question, not a different user.

All of this used to work fine until a couple of weeks ago. My guess is that there is either 1) A problem with my thermostat or 2) A bug introduced by some alarm.com update that changed how it interacts with this Trane thermostat. The OP is posting the same issues as me and mentions Trane as well.

Yes, though the alarm panel/module may also affect this as it is the intermediary between ADC and the thermostat device. My guess is it is the thermostat, but since you did not have an account with us when the actual problem started occurring we cannot go back in history to see if any thermostat schedule commands were sent around that time. That might suggest whether there might be a change in how schedules interact with your combo of equipment.

Did you make any schedule changes around that time? Even if not there are certain circumstance where rules would be sent in an automated fashion for maintenance purposes, so I suppose it is possible.

Note that the version of Simon module you have is not compatible with the ADC RTS, (need 183 or later) in case that is a plan.

I double checked with ADC and they only have one recent similar report of schedule issues on that model but that was in July, so if it is a related issue it would be sporadic and very rare unfortunately. You’ve gone through all of the related troubleshooting.

That’s funny, now I know why that original post sounded so familiar:)

No schedule changes back when the issue happened. Schedule has been set for ages (like years). Understand no way for you guys to troubleshoot. The ADC thermostat will arrive Sunday and I expect I’ll be in good shape then. No plans to add a remote temperature sensor, but thanks for mentioning just in case.

Installed my new ADC 2000 this weekend and schedule is being followed. Weird failure of the Trane, but I guess those things happen.

Only thing that doesn’t seem to be working is the Smart Away. I have it set to go to away temp (85) when armed away. I don’t have the geo-fencing options enabled. When armed away, however, the temp isn’t changing.

I’m new to SuretyDIY (from Frontpoint). Is it possible there’s something else going on to keep the Smart Away from working?