Good Morning. I have a T40K thermostat that has been working great for months. This morning we noticed a change in behavior or an error.
We always have it running on a schedule. Typically, if we manually adjust the temp at the thermostat, that change is temporary, and the next time the schedule calls for a change, the schedule resumes automatically. It has worked this way since we installed it.
However yesterday around noon I changed the temp manually to 67, and that temp stuck all night long until just now when I noticed it was too warm in here. The system said it was in āSchedule Onā mode, but it was not following the schedule. It should have changed to 62 degrees at 8pm, but it did not. I see no errors anywhere (on panel or in ADC site or app).
The only way I could get it to honor the schedule again was to turn the schedule off and then back on again. Now it seems to be following the schedule.
My question is: is this a malfunction, or did ADC change the way the thermostat behaves to temporary temperature adjustments?
Suggestion: Most other smart thermostats have a āholdā button where you set whether a temp change is temporary or permanent, or for how long ā the T40k doesnāt seem to have that feature, which is definitely an improvement that is needed, IMHO.
Also, the thermostat actions shown in the activity log need to be enhanced. That log does not show ALL thermostat actions that are driven by a schedule, only human-made temp changes and for some reason only the schedule driven change that happens at 8pm !?! the other schedule driven changes never appear in the activity log (?).
Thanks for your help!
One thing I do see is that there was never a network rediscovery command being performed. There isnāt really a way to check on the status of the thermostat without that command being sent first. Would you like me to send this command? There might be a few devices that may show up as poor signaling and create a trouble on alarm.com
I did talk with alarm.com and unfortunately the thermostat does not have a hold option. The only way would be to turn off the schedule from alarm.com.
Hello.
First of all, thank you for asking about the hold feature. Good to know it isnāt a functionality change.
Iām not sure what you mean by āneverā - lol - I typically run a rediscovery whenever a device moves or is added/removed. My ZWave has been very stable for weeks so no rediscovery has been needed. In any case, Iāll check the network map when I get home tonight to see if there are any issues and run a rediscovery if needed. I really donāt think or see this as a ZWave issue (I could be wrong, of course) since the TStat has been online the whole timeā¦ I have no malfunction issues, the ADC app seemed to always know the statās status, etc. What malfunctioned was the schedule was no longer being followed.
I suppose the question is - how does ADC handle the schedule? Does the ADC cloud issue commands to the stat at the scheduled times? If so, if it issues a command and the stat ignores it, wouldnāt I see one setting in the ADC app and a different setting on the stat itself? Or at least see the stat āflashingā in the ADC site since it couldnāt refresh?? In this case, this morning the app and the stat both said 67, and when I refreshed the stat display it came right back, and reported a setting of 67. BUT the setting should have been 62 for that time of day.
It almost seems that whatever is in charge of following the schedule simply decided to not follow the schedule last night. I just donāt know who/what that is. I suspect it is the ADC cloud, but maybe it is elsewhere.
In any case, since I first authored this, our schedule has had TWO additional temp changes (due to the schedule itself) and the stat and schedule is working and applying properly. In other words, it is now working with me doing nothing other than turning the schedule off/on early this morning. If it was a zwave issue, Iād expect it to still be broken, no? I feel like this might be an error/issue at ADC cloud level that was transient and now resolved. Of course, I could be wrong.
Thatās interesting. Last rediscovery is showing up as blank and thatās usually because one hasnāt been performed. It probably hasnāt been updated on my end. Is it okay if I run one so that the devices update on my end?
All Z-Wave schedules are activated through the ADC cloud. When the schedule is triggered, it send the command to the panel which makes the appropriate changed to the Z-Wave devices. The schedules are not triggered directly from the panel.
I canāt currently see the link quality but if something was low in signal, it could have just been that the command was lost between devices. Cant really say much more until Iām fully able to see link quality between devices.
Thank you so much for the detailed reply. I really appreciate it.
I just got home, and pulled the zwave ānetwork health statsā on the stat (pic below), which seemed rather ok to me, although I was surprised the transmission count was so low.
What I should have checked this morning was the device history. When I check it now I see the command going to the stat (pic below) at 459a (when I manually turned the schedule off/on). There is no command history for when the schedule should have fired (8pm 2/12). Not sure this means anythingā¦ just interesting.
The system said it was in āSchedule Onā mode, but it was not following the schedule. It should have changed to 62 degrees at 8pm, but it did not. I see no errors anywhere (on panel or in ADC site or app).
