tried the hard reset. it actually solved the issue.
the disturbing beep was gone for about 10-12 hours.
but then my ISP had a cutout and ST hub went offline.
after it came back, the beep started again.
now I have to hard reset again I guess. It’s not so easy. Especially when I have about 8 smart apps connected to the device. I have to delete the device from each and then re-add.
[RELEASE] 5-2 Day Programmable Thermostat Scheduler (Weekday, Weekend) with Remote Temperature Sensor for each Schedule
tried the hard reset. it actually solved the issue.
Try using the reset button. It doesn’t do a hard reset and tapping the refresh tile will resend all the settings back to it.
Just to get it right, are you hard resetting the hub or the CT100+ thermostat? You shouldn’t need to reset anything other than the thermostat and when you get your Internet access back everything should function as they did before. Am I missing something…
ok. got it.
I had thought that after resetting the device I have to delete and add it to ST.
RBoy, what’s up with the smart app version v03.09.04?
There seems to no longer be a way to change the temp without the scheduled temp overriding it within a minute or so. I have tried using the lock function, but nothing seems to make the manual temp setting actually last more than a minute.
Can we get a config to turn off this new behavior?
Open the app and enable the option for
Allow temporary hold if you want to manually override the thermostat set points.
Thanks, that did the trick. No sure how I missed that one.
@RBoy To add to my RFE request, would the team be interested in implementing a pairing for thermostats and door/window sensors. I just installed the new Sinope TH1300B Smart Floor Heating Thermostat and it’s working great alongside the other thermostat in a different room. While I could have multiple instances of the app it would be so much more cleaner to have the ability to pair a open/close sensor with each thermostat instead of just having a pool.
Also, not to press my luck, just wondering about the RFE for seasonal hold.
I just subscribed for rboy lifetime license. However, I am having issues with any @RBoy thermostat smartapp with a nexia thermostat (@edk208). Not sure if it is the rboy smartapp but there seems to be a bug in the rboy smartapp because if I use the embedded smartthings smartapp like the ‘Keep me Comfortable’ it works great. It sets the Nexia thermostat to the desired temperature. The rboy thermostat smartapp sets the desired temp but puts it back right away for whatever reason. I can see in the thermostat how the temp was changed by the rboy app but then the temp is put back to default within a second. As I looked into the events of nexia thermostat, it is indeed the case. Has anyone experienced this?
@RBoy, @maddie I’ve been having some odd behavior with the app. I’ve observed it on a couple of occurrences so it’s not just a today or this week thing AFAIK. Basically, I have the app controlling two thermostats. What has been happening is two things:
- Sometimes the temp changes way late according to the logs. For instance, I have a schedule of 5am @ 70F and in the logs I see the app sending the command at 5:00am to one thermostat but the log indicates that the other one was sent the command at like 5:46am.
- On some occasions, the logs never show the schedule change for one app. For instance, I have a schedule of 64F @ 8:00am and in the logs I see one thermostat being set but there is nothing for the other one at all so it stays at the previous setpoint.
To be clear, I am not looking at the live logging but rather the rather high-level events for the App in the IDE and the events for the thermostat in the ST mobile app.
If it’s happening randomly then it’s an issue with the platform timers associated with your account. It means that that platform either missed the timer or it overloaded and it timed out. It’s rare but it’s known to happen.
The best way to verify is this to look at the app schedule execution history. You can find this in the IDE under My Location -> Click on SmartApps next to your location -> Click on your SmartApp name -> Scroll down to the bottom of the pop up screen and it’ll show the schedule and history of scheduled executions for that instance of the app. If you’re seeing that schedules are missed then report it to ST support to investigate why your account is missing schedules.
There are a few suggestions from the ST staff:
- Try to uninstall and reinstall the app
- Don’t use half hour or full hour schedules as most schedules tend to run at the time which overloads the servers. Try to use an offset, like 4:55 or 5:32 etc.
According to ST, if a schedule is missed it’ll try to run it at the “earliest” opportunity (which could explain why it ran 45 minutes later). Since ST runs on many different servers/shards, some servers which are facing heavy load/issues at specific times explains why it’s inconsistent.
Jut to be clear, I am using a single app instance to control two thermostats and not two separate app instances. I haven’t really looked through the code but is the app designed to have multiple executions when you have multiple thermostats? To me that didn’t seem to make sense given that you have one schedule for all thermostats
I do understand what your are saying about ST scheduling. I would agree if both thermostats were delayed or neither were changed but it’s one of the two that is missed. Meaning that the I’m seeing that the app runs at 5:00am as expected but the logs only show one thermostat being sent a command sometimes.
Here are some screenshots to give you an idea of what I am talking about.
At 8:00am, I see the app being called per the schedule:
But, if I look into the event history, I only see one of the two thermostats at 8:00am:
Actually it explains what I pointed out above. If you see the numbers next to the schedules, that shows the delays and execution times. At 8 am it was delayed 20 times longer than other execution times and it took 10 times longer to run than other times. The platform limits execution time for an action to 20 seconds and this one seems to take 32+, so the platform is timing out because it’s overloaded and running too slowly and terminates the instruction before the second thermostat receives it (this is specific for the server assigned to your app/account)
And like you said it’s happens sometimes, so it’s something outside the app that’s causing it. You’re best bet is to try the above steps or contact ST support to investigate why the apps are timing out/running slowly at those times.
I’m getting the following errors when I try to change the device type on my CT100 to the 5-2 Day Programmable Thermostat device handler.
Anyone else have this issue or know how to fix it?
There are two types of custom code here: apps and device type handlers. This is a thermostat app and not a thermostat device handler. I don’t have one of these CT-100 thermostats but you would need to first look for the 2GIG device type handler to get the thermostat working with SmartThings and then you can install this 5-2 Day Programmable Thermostat Scheduler app to control the 2GIG thermostat.
I think @RBoy has a thermostat DTH, probably what you were looking for:
@LLwarrenP Thanks for the help and devise handler link! Got it working, operator error was the issue.
Thanks @RBoy, this makes more sense in that context. I do recall reading in the docs about ST killing long running processes but I didn’t connect that when looking at those long execution times.
The delay I can live with as this is still < 1 sec but what I am wondering about is the long exec time which could be getting killed off by ST. IMO, this long exec time is probably code execution time and not caused by ST running slow. If it is ST crawling then I would agree that there is nothing we can do to fix that other than open up a case which who knows how long it would take to have addressed, sorry to say - I had one case to delete two phantom devices that took in excess of a month.
Regardless, I’m curious to see if I can figure out where the slowness is coming from. I’m not saying the thermostat app is to blame but rather that something is getting hung up. What about connectivity to the device? In this case it is two ZigBee devices but they both seem pretty responsive normally. Or maybe some coding issues in the DTH. Is there a way I can up the logging on the app to sort of profile it a bit? I’m going to try and force some manual executions of the initialize() to see if it happens repeatedly.
@RBoy, I observed that if I forced the initialize(), it would on average take 2-6s which is fine and well below the observed 30s+. So maybe you’re right (Who, you? Go figure!) and it’s nothing happening more than the ST shard is crawling.
However, one thing that occurred to me was that you have some simple intelligence in the app to basically resend the last setting if the previous attempt failed and in this case it seems as though it is failing but it seems the code thinks that it was successful as I don’t see a warning in the logs. It seems like the best solution here would be to improve that success/fail tracking logic and simply resend the commands at the next heartbeat. Obviously having multiple devices complicates it a bit since one could be successful and another fail and if someone happened to put the one that was successful on a temporary hold and so on…but I think tweaking the thermostat app has a better chance of success than hoping ST buys more bandwidth from AWS or whomever.
In the meantime I changed the thermostat schedules to 5 and 35 past the hour to see if that helps.
I came from IRIS and ported my CT100 Thermostat and was wondering if there is a basic smartapp that can basically operate in heat mode and set a wake up and sleep time.
I see the paid app but not sure if I need all the features.
@Rboy, just to close the loop, it seemed that settings the schedules to trigger at 5 and 35 minutes vs 0 and 30 minutes seemed to make this occur way less frequently. In the meantime, I was also wondering if you are considering any enhancements to the “checking if successful” logic when you have multiple thermostats as noted above?
Also, given that we’ve finally started to have an occasional nice day or two it reminded me about the above and was also wondering about these RFEs as well, especially the seasonal hold / shutdown. LMK if a contribution to the beer fund would help, ha ha.