Hey guys - smart away was working just fine to keep the furnace off when we’re not at the house, but in the last few weeks, it seems to have become un-trustworthy. Here’s sample logs of thermostats being instructed to change while the alarm’s armed:
I’ve just set up a rule to notify me if the thermostats change, but I’d rather they - you know - not change. 
Any ideas?
Is the problem that it’s not changing the target temp down to 40 degrees when you arm away or that it is changing to 40 degrees when you arm but then it’s changing back up to 60 something before you disarm?
I’m having trouble finding an example in your event history were it is working correctly. Do you know of a time when it worked as you expected?
Hey Ryan…huh, it’s not always showing in the history, but if I disarm/arm the thermostats are set to the correct temperatures within a few minutes. Notice there’s a lot more entries for the “dining room” thermo vs the “furnace” one.
Anyways - specific issue leading me to post is at some point after that (looks like next day after arming?) something is sending commands to adjust temperature/fan modes.
I’m not sure it’s ever worked 100% - There’s been a few times where I pulled up the mobile app to see a thermostat running in the 60s when nobody’s been in the house for a few weeks…
John
It looks like the temperature is changing according to your schedule even when your panel is armed away. Do you notice this happening when your schedule has a temp change programmed?
The times don’t seem to line up with the schedules. Looking closer, seems to be happening more often with one thermostat than the other.
I just disarmed the alarm from the web, waited to see what would happen to the thermostats. After a few minutes, they did as they should and returned to a “home” setting (determined by “updating” the thermostats on the empower tab in the webUI). Key here: there’s no log of the thermostat changes in the event history. Also, I got no notification of changes to thermostat settings, so I guess those notifications only go out on manual changes, not automated. Went ahead and re-armed, temps dropped back down as expected, nothing in even history except the arming.
I’m going to try and watch things carefully for a week or three and see if I can figure out a pattern to things…
Alarm.com is looking at the Smart Away rule. A new command will be sent to re-instate the rules and make sure it wasn’t incomplete or improperly saved at the panel.
Cool, thanks!
Update: Looks like temp settings were updated sometime between 5:20pm yesterday and 8:30am this morning(pacific time). I don’t see anything in history that points to a reason. The updated temps are what are set on the schedule.
Let me know if you want me to leave it as is, otherwise I’ll turn the temps back down instead of heating an empty house…
No, no. Go ahead and set it to the proper temp. Thanks for the follow up, I will update ADC with the times the error occurred and post responses.
Temps reset again overnight…
What is the model of the affected thermostat?
1 each:
I’m fine with being told they’re “not supported,” but if ADC responds that the models are the reason this is happening, I’ll be expecting a detailed technical response. 
Happy Friday!
Well, the good news is it is definitely a supported model. The bad news is the thermostat itself is possibly causing this issue.
Supposedly this model (The GE) has a firmware coded override which adjusts the temperature after 24 hours without any commands. The manufacturer will not fix this with firmware update, apparently. Smart Away function stops schedule commands, so does it look like it is roughly 24 hours that these problems occur?
An easy test (but would take a bit of time) would be to send a command shortly after you arm the system, then roughly 24 hours later does the set point change?
OK, will try that after the weekend and update tues or wed.
Doesn’t really explain the Honeywell temp getting reset though… (it’s happening on both)
It may be something nearly identical with that thermostat, basically an internal schedule or override which the manufacturer thought was a good idea. That model may have the ability to shut it off however, as many do. The CT20/GE TSTAT 100 is coded into the firmware.
Try using the “Hold” feature on the Honeywell thermostat when you test the other. Enabling “Hold” should keep the thermostat from changing the set point due to internal schedules, but should still allow Zwave command changes when applicable.
For what it is worth: I have recently had to have my ADC account deleted/readded (Vivint f’ed up my 2G card switch, long story). In that process I have had to resetup ALL of my ADC schedules/notifications/actions.
One that I noticed (yesterday) is that if the thermostat is set on schedule and I modify the schedule then that new schedule will not take affect until I switch to manual cool (in ADC, turn off scheduled cool and just regular cool) and then back to scheduled.
My thermostat is a CT100 running on batteries which may or may not affect this.
It sounds like Jason has already pin-pointed your problem, I just wanted to share the knowledge for others looking for help. It might just be worth the 30s to toggle scheduled on/off.
I vaguely recall there is some kind of an issue with Ct100’s running only on batteries… setpoints not working, zwave signaling issues…
see, the 24VAC is less of an option and more of a necessity. Battery operation severely limits the Zwave transmission, which under normal circumstances would likely not be causing too much of an issue, given it is that close to the panel. However, the battery voltage is dropping as it runs, and if the device is just running on battery all the time, there’s no telling what signals would be missed.
Another point to consider (which may or may not be relevant to this particular issue), is that Vivint runs old outdated firmware on the 2GIG GoControl panel which may cause issues with how the zwave gear operates/functions, and what the panel can support.
To my knowledge, Vivint’s most current “up to date” panel firmware is 1.9.6 (four update releases behind what everyone else is running).