I am using 2 sets of Radio Thermostat CT101 devices. When first installed a few weeks ago, they worked fine with being in sync with my SuretyDIY online monitoring as well as on my Android app. That is, I could control them programatically thru schedules as well as interactively change the settings. The remote readings would also pick up any manual changes directly at the thermostats.
However, the updates were always slow, sometimes taking more than a minute for the remote apps to see changes. This was fairly acceptable, even though I don’t understand why thermostats react so much slower than Z-Wave switches.
Anyhow, now they are reacting even worse. The schedules work fine, and sending temperate changes online also work fine. But any manual changes directly at the thermostats no longer register remotely. That is, when I change the temp at the unit, the heat does respond, but this change is NOT reflected online. Any reason for this? Is it that this model of thermostat is not fully supported, even though they seemed to work properly for a short while? I also have a third thermostat, the ADC-T2000, which works perfectly fine with manual and online updates.
However, the updates were always slow, sometimes taking more than a minute for the remote apps to see changes. This was fairly acceptable, even though I don’t understand why thermostats react so much slower than Z-Wave switches.
Thermostat schedules and settings are much more complicated, command-wise, than on/off for a switch, and it can take a bit more time to confirm status when making a change from the app. The app will not update before the command is acknowledged and the status confirmed.
But any manual changes directly at the thermostats no longer register remotely. That is, when I change the temp at the unit, the heat does respond, but this change is NOT reflected online. Any reason for this?
There could be a few culprits. To get a better idea:
Have you run a network rediscovery?
Are you checking exclusively in the app? If you make a manual change, check the Alarm.com website as well, is it updated there?
Note that you may need to refresh the app page if you have it open and checking it. Try making a manual change, wait a moment, then reopen the app. Go to the Tstat page.
When opening the app and tstat page, background status requests are made to verify the current temp setting.
Yes, manual local thermostat changes are not reflected on the app or on the website, even after several “refresh” commands, and its been about an hour since I made the local temp change. Prior to today’s testing I have done both a “Check Network” and a “Network Rediscovery”.
New development: now a local change did show up briefly, and I even got a notification that I set up for any changes, but then both the app and website revert to a value that was set previously on the app. So I then set a different value using the app, and it worked, and just now a local change does not show up on the app.
To confirm your question depends, seems like there are cases when a local device change does not show up online, not sure when, maybe when local and remote commands get set too close together? Anyway, yes all thermostats were learned in with AC power and are currently powered by AC. Here is the scenario:
Starting with Target at 68, current temp at 68 on the local device.
The app reads target=65, temp=68 (note that 65 was the last online target command from previous test).
User set local device target to 67 from 68.
App changes to 67 briefly then after about 10 seconds reverts to 65.
I get notification of change to 67.
From the App change target to 66, device gets changed and notification sent, and App stays at 66.
User sets local device target to 67 from 66.
App does NOT see this change.
From the App target changed to 65, device gets changed and notification sent, and App stays at 65.
User set local device target to 69 from 65.
App changes to 69 briefly then about 10 seconds reverts to 65, I get notification of change to 69.
Note that when the App reverts to the “last-sent-target”, the device does not change to that value, it remains at the user locally set value.
Your description matches what I see in the device command and status history.
I see no original change to 68 from your prior test. I see no switch to 67. The two instances where the app did not change, Alarm.com did not receive a status update from those changes.
Where you say the app changes but then reverts, I do see event entries as normal for the correct initial change. Nothing there for the reversion.
Status commands are separate and distinct from commands to actually change the target temp, so I would not expect it to have any impact on the actual function.
One thing I am seeing is very strange readings for cellular signal strength here and there. Signal strength is listed as “Unknown” in spots which I believe ADC did not receive a full status response.
Can you try powering down your alarm panel, transformer first, then battery, then checking to make sure the antenna is firmly attached to the module? Ensure the module is likewise firmly connected to the board and screwed in place. Make sure you are not using a smaller 2G antenna and that the antenna in use is the one that came with the 3G cellular module.
Also check to be sure that no high voltage wires are running in the wall close to the antenna. Any of these seem applicable?
To answer the equipment question, I’m using “2gig GC3GAA AT&T 3G Cell Radio Module with ANT3X” on my “2GIG-CNTRL21-345” module. Since the antenna came with the radio, I’m assuming it’s correct.
There are no high voltage wires near the panel, not even an electrical outlet or switch.
I can’t comment on the reason for variable cell signals, but this does seem to be an ongoing issue in my area. Why would this only affect thermostat signals and not all other Z-Wave devices in my mesh?
I can try your panel reset and hardware connection suggestions sometime this weekend, and get back to you, thanks.
I can’t comment on the reason for variable cell signals, but this does seem to be an ongoing issue in my area. Why would this only affect thermostat signals and not all other Z-Wave devices in my mesh?
This is deceptive, because we do see something affecting signal status. It is really hard to say with certainty, but I have seen carrier packet shaping cause issues selectively before with certain commands. I’m not guessing that is the cause here, but issues causing selectivity are not improbable.
A power cycle is a good panacea to try first when no obvious fix presents itself. Make sure to leave the module and panel powered down for at least two minutes before booting back up. This will also force re-registration to carrier network and should result in the best tower signal. Check radio status after a few minutes. What does the signal strength say on the Radio Status button in the installer toolbox?
We will report this to ADC to see if there are other reports in the area as well.
I did the power reset and the problem still exists. Signal is the same as before, around 10-11.
I don’t think it is a carrier packet not being received issue. The app will see the temp change, so the data is being sent and received. The problem is that within seconds the app will revert to the value that was there prior to a local change. The device remains with the changed value.
Last week this issue also happened with my ADC-T2000 thermostat, but worked today prior and after the power reboot. So the ADC is inconsistent, but the CT101 always has this issue.
Well, device model differences are certainly possible, and thermostats and locks are far more likely to be affected by that. Strange to function normally other than that specific instance, and it is strange to see the other inconsistencies along with it, like the signal strength readings (we see an “unknown” level today too)
Officially, the CT101 is not listed as a supported model, though it is largely just the iris version of the ct100.
I am updating Alarm.com at the moment to try and get some commands sent to resync the system and check for anomalies. Please test again later when available.
I just tested again and the ADC updated fine and the CT101 did not, so same problem. What I don’t understand is that the value change shows up momentarily in the app and then reverts. Is this some sort of acknowledgement problem?
My guess, barring any sort of selective signaling issue, is that the 101 confirmation status is slightly different in response than other compatible models and is throwing it off. Without support documentation there is limited ability to confirm.
It might be good to try updating to the latest alarm panel firmware (1.17.0.3) to see if that makes any difference, as there are some Z-wave updates.
Update: I swapped out the CT101 units with the officially supported CT100 ones and now the local settings are persistent as they should be. So I guess this is an anomaly of the similar CT101’s. Thanks for your help with this.
On a similar vein, the Android version of the ADC app has update issues. If I click on one of the thermostats and make a local temp change, it does not update the on the app. Even if I pull down to refresh, the temp value in the app does not update. I need to go back to the main screen, and then the current value updates, and also shows updated if I click back on that single thermostat. This odd behavior is not a problem on my iPad IOS app which seems to update with a refresh on either screen (although on iOS you can’t view just one thermostat at a time like on Android). It would actually be nice on all platforms to have an auto-refresh and not require a user pull-down. Manually updating seems counter intuitive for an automated system, lol.
Even if I pull down to refresh, the temp value in the app does not update. I need to go back to the main screen, and then the current value updates, and also shows updated if I click back on that single thermostat. This odd behavior is not a problem on my iPad IOS app which seems to update with a refresh on either screen (although on iOS you can’t view just one thermostat at a time like on Android)
We are happy to send this to ADC as a bug report of sorts. It sounds like something with an easy change if the correct temp is pulled on the home screen, though I believe I know why it works that way. Note that whenever loading the home page, Alarm.com polls new data from the panel with a few commands related to the type of equipment you have. The app is designed to do this as when an individual naturally interacts with it, they open the app to check something, then move on.
Each time you open the home page to check something these status polls get sent.
Local changes do get sent by the panel without being polled, but I’d need to check if ADC still sends a polling command to verify the temp.
It would actually be nice on all platforms to have an auto-refresh and not require a user pull-down. Manually updating seems counter intuitive for an automated system, lol.
I think this may be a case of testing something that is not intended. If utilizing the system unnaturally, patience is required with status updates and confirmation. It is not intended to provide instant status reflection of quick local changes while staying on one page of the app. Automatically polling the panel repeatedly creates a lot of unnecessary cellular traffic.