SmartAway stopped working a while ago.
After I noticed the issue, I tried turning SmartAway off and back on, turning schedule off and back on, however this did not help|
E.g. today, we armed the system away at 9:09 AM. The thermostat was supposed to switch to the away temperature, however, this did not happen.
Can you confirm roughly when you first noticed this occurring?
Does Smart Away work sporadically or does it always fail?
Not sure how long ago it broke, i’d think it’s been more than a month, maybe several months.
i recall that one day i noticed it not working. It was working the previous day. i don’t recall making any config changes to the thermostat before it suddenly stopped working.
Since it broke, it never worked again.
It looks like a network rediscovery was run recently. Have you tried a power cycle of the thermostat?
I’m sending a few troubleshooting commands to the system.
Wait about 30 minutes to test. If no luck, try deleting that thermostat, waiting 10 minutes, and then re-adding it to the panel. Afterward, recreate the schedule and away rule and test.
So far no luck, powering off the thermostat did not help either. When we armed the panel away at 6:54 PM CST, SmartAway did not kick in.
If I want to try excluding / re-adding the thermostat from the panel, should I also remove temperature sensors (ADC-S2000-T-RA) from the panel (and if so before or after the thermostat) or should I leave them?
Also, after deleting the thermostat, should I also reset it before re-adding?
For now there is no need to remove the temp sensors. Those shouldn’t be having an effect in this case.
Yes, you can perform a reset on the thermostat as well while it is deleted so we can avoid trying it as a separate step later.
I deleted the thermostat from the panel, reset it, re-added it and configured schedules and SmartAway.
However, SmartAway still does not kick in when we arm the panel away (e.g Friday 7:21 PM CST, Saturday 7:14 PM CST)
Just to be 100% sure, your schedule was turned on at the time right? I can have ADC rebuild rules as a troubleshooting step. I will let you know when to test again.
Yes, the schedule was on and the thermostat was in auto mode.
I noticed that when we armed away this morning at 9:03 am CST, SmartAway kicked in as expected for the first time in a long time.
Do we know, was anything done by alarm.com on their end?
No, ADC did not send any specific commands yet. We sent some general troubleshooting commands.
Can you test a few more times and let us know if consistent? Keep in mind that manually adjusting the temp locally will override schedule changes.
Since my last update, I’ve seen SmartAway working as expected for two days (Tuesday and Wednesday). Both days we armed away in the morning and disarmed in the evening. The thermostat went from Home to Away and back as expected in each case.
Today however something strange happened, but it was a kind of a corner case:
7:44 am: panel disarmed as I left the house
7:48: armed away - my son was leaving and since my wife was still sleeping, he wanted to arm stay but mistakenly armed away instead
8:01: disarmed - my wife woke up and noticed that the panel was armed away so she disarmed
8:01: armed stay - she armed stay the same minute
8:30: I checked the app and noticed that the thermostat was at Away. So SmartAway did not turn off when the panel was disarmed at 8:01
9:10: disarmed
11:39: The thermostat was still at Away, manual setting to 74
Is this expected, given the quick transition armed away → disarmed → armed stay?
If the schedule was active and the temp hadn’t been manually adjusted locally, the schedule should have reverted after disarming.
I’ve spoken with ADC on this and they are looking into this. We do not see definitive confirmation in event history when the Away temp is applied or removed, which makes it a little more difficult. I’ve put in an enhancement request to get more visibility into that.
In the meantime, the next time you notice when either Smart Away doesn’t kick in or when it doesn’t turn off can you take a photo of the Tstat target temp showing as well as a screenshot of the thermostat page in ADC with time-stamp? That will let me escalate it with engineers more easily.
I can confirm that for today’s issue, the schedule was active and the temp was not adjusted manually.
The schedule is programmed with 2 settings per day, changing from Sleep to Home at 8:00 am and back to Sleep at midnight. So the arming away happened when the system was still at Sleep and the disarming was one minute after Home would apply.
I’ll collect the requested info if I again see an issue.
It would be great if temperature settings changes that happen due schedule or due to SmartAway were reflected in the alarm.com activity log, it would make it easier to report intermittent issues such as this one.
It would be great if temperature settings changes that happen due schedule or due to SmartAway were reflected in the alarm.com activity log, it would make it easier to report intermittent issues such as this one.
Yep, some changes do show up in dealer history but smart away confirmation does not, which is part of the enhancement request.
Today SmartAway did not change the temperature back to Home when the house was disarmed at 4:55 pm CST. There were no manual tstat inputs. There were also no other interactions with the alarm system from the time we armed away at 9:42 am CST.
A couple days ago we actually got confirmation from Alarm.com that they are aware of an issue where Smart Away is not firing in some cases. They received multiple reports and are investigating now.
For this last occurrence, the system was disarmed at the panel in case that matters. In most cases, we tend to disarm from the app.
Another occurence when we armed Away 7:17 PM CST. No manual tstat settings.
It was working since summer, however, it seems to be broken again as it did not work twice in a row.
The last time it worked was when we armed away yesterday morning at 9:06 am CST. It did not work when we disarmed at 5:19 pm CST and again today morning when we armed away at 9:26 am CST. In both cases there were no manual tstat inputs since the previous schedule applied.