1: Variables, currentTemp and currentOutdoorTemp will now be converted to BigDecimal before being rounded. Thanks to SmartThings Community member, @gsgentry for submitting logs showing that Honeywell Total Connect WiFi thermostats report temperature values as strings.
2: Selecting armedModes values on the Mode Based SetPoint Enforcement page is no longer required. Not everyone uses SmartThings Home Monitor.
@hsbarrett – This issue with the temperature variables appears specific to Honeywell WiFi thermostats. I’m hoping this will solve your temperature setting issue!
As always, if anyone has any issues with this new build, please let me know and I’ll get on it.
1: The value of the currentOutdoorTemp variable will now be correctly reported as null in the case that an outdoor temperature sensor has not been selected. Thanks to SmartThings Community member, @gsgentry for reporting this issue.
Sorry for the rapid pace of releases lately. @gsgentry has been helping me test. This release fixes a bug from the previous overhaul that added the alternative thermostat configuration.
@jmarkwell
Sorry for my lack of communication… been dealing with hail and floods.
The 03/28 release I believe has done it. ALL as of this point of testing is working great. Thanks also to @gsgentry for the assist. Until they screw with the DH again, all seems to be working as before. Thank you for all you have done, absolutely appreciated.
getSHMSetPoint() will now account for null modeConfig values. Thanks to SmartThings Community member, @gsgentry for reporting this issue.
disableSHMSetPointEnforce has been renamed to enableSHMSetPointEnforce and Mode Based SetPoint Enforcement will now be disabled by default.
Updates to code comments.
A note for current users: If you use Mode Based SetPoint Enforcement, check your settings after you update. I had to change a variable belonging to this system and that may cause some of the Mode Based SetPoint Enforcement settings to revert to default.
Hi,
I installed your app and I was hoping you can offer me some help. I was previously using the Thermostat Mode Director app to control my 2 Honeywell WIFI thermostats. I had it set up that when selected doors and windows were open it would shut off the AC and when they were closed to turn it back on. it was working perfectly for about 6 months. I then notched that it stopped working a few weeks ago and the reason is the thermostats for some reason were removed from the Thermostat Mode Director app in the thermostat and doors section of it where you select your thermostat. to make it more strange the thermostats are still available in the main smartthings app and can be controlled from there. Smartthings has not corrected the issue after being in contact with them about it
I don’t see how I can set your app to do the same thing and I was hopping you can direct me how that can be done
I believe you are experiencing these problems due to a SmartThings software change made that regards cloud based device handler capabilities. This change happened earlier this year and many people who use, “Wi-Fi” thermostats have had this happen.
Make sure you are using the latest Thermostat Manager version and then try configuring it using the, “Alternative Thermostat Configuration”. Most likely, this will get you going again. If not, let me know what happens.
thanks for responding its much appreciated. I have installed your app and have a few questions.
I did indeed use the Alternative Thermostat Configuration. So once in that section you have 4 areas that you can select the thermostats. (1) thermostat mode controller (2) thermostat heating setpoint controller (3) thermostat cooling setpoint (4) thermostat fan mode controller. I selected the thermostat in all 4 locations as I am no sure what each of the 4 do but I figured the 4 areas should have the thermostat selected. let me know if that is correct and if you can provide info you want to add to what each of the 4 areas is for or does.
the controlling of the thermostats AC and Heat with thesmartthings door and window sensors to turn the thermostats on or off as a sensor is open or closed for a period of time described previously should be done in your “energy saver” section correct?
In your “thermostat mode controller” section where you select the thermostats both of my thermostats are available but you can only select one or the other not both. So if I want, for example to set the thermostats to shut off after the front door sensor is open for two minutes and turn back on after its closed. the only way I can do that for both thermostats is to go through the set up twice, once foe each thermostat. then I have to repeat that process for every situation I want to set up a different sensor or situation. Is there any possibility to be able to select both thermostats at once instead of individually one at a time,
If the energy savor triggers the thermostat to shut off the AC because the front door is open for two minutes, when the door is closed does the thermostat go back to what it was set on previously. meaning if it was set to Auto, Cool or Heat it will go back to whatever is was set on before.
sorry to ask so many questions. I am trying to do this from a different location then where the system is, it is difficult to test it to make sure it is working properly and it is doing what I think it should be doing. The only way to test it is to schedule someone to go there to open and close the doors to see what actually happens. so any help, explanation or direction is greatly appreciated.
So it appears that SmartThings and/or cloud-based thermostat manufacturers have begun removing support for the older, “thermostat” device capability. In its place, there are 4 capabilities that do what the single one used to do. It allows for more precise control on a broader range of devices but it also makes for an awkward configuration session.
Correct.
That’s right. Currently you’ll need a separate instance for each thermostat. I’ve been thinking about adding support for multiple devices for a while, but when/if I implement it, I want it to work well. If/when I implement that functionality, it will be announced here. The more people that ask for something, the more priority it will be given, but thus far, not that many people have been interested in that.
Yes. The previous setting is saved and re-established when the user configured timers have completed after all of the contacts have been closed.
No problem. Happy to answer any questions – and am happy to listen to any requests for enhancements.
I started using Thermostat Manager recently with a Honeywell 9000 series wifi thermostat. I have Energy Saver enabled and it seems to be working fine for shutting the thermostat off when a door is opened.The problem is that it sometimes doesn’t turn back on after the door is closed. Any idea why that would be? Logs from the most recent failure are below. Thanks.
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 72
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 68 | Cooling Setpoint: 73
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Mode: off
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Fan Mode: auto
9:54:14 PM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
9:54:14 PM: debug Thermostat_Manager.tempHandler(): At least one contact is open: false
9:52:12 PM: info Thermostat Manager - All contacts have been closed. Restoring cooling mode.
9:50:11 PM: debug Thermostat_Manager.esConflictResolver(): esConflictResolver() will be run again in 121 seconds.
9:50:11 PM: debug Thermostat_Manager.esConflictResolver(): All contacts have been closed. Discontinuing any existing thermostat pause countdown.
9:50:11 PM: debug Thermostat_Manager.contactClosedHandler(): A contact has been closed.
I am putting out a new release soon that might have some effect on some of this (although it likely won’t fix your issue). Subscribe to this thread and give it a try when I release it within the next few days and let me know if you see any changes. At the very least it should provide more evidence into what is going on.
Also, could you post a screenshot of your Energy Saver configuration?
So far it seems to fail to turn back on at least 50% of the time. I’m going to try to do some more testing with it tonight. I’ve had no problems turning it on and off via the ST app. Just wondering…does your app do any sort of verification that a change has taken affect?
Adding capability to enforce Energy Saver pauses. This feature was requested by SmartThings Community member @gsgentry.
Removing the no longer used ignoreOverride state variable and the code that references it.
Modifying conditions on the verifyAndEnforce() function’s mode enforcement operations in order to allow for proper enforcement of “off” mode.
Added a help tip to the Energy Saver configuration page.
This one’s for you @gsgentry! OK so a couple of you guys are having issues that may be related to a minor bug I found in the code while doing this, so I sped up my testing a little. While writing a feature for @gsgentry, I discovered that the verifyAndEnforce() function may not work properly in the case of an Energy Saver pause. There are no significant issues with Energy Saver so nobody probably noticed, but it may help in the case of @Yossarian.
As with any new feature, I may have to make a couple of revisions to refine it. But this one looks pretty good and it tested perfectly in my house. Enjoy!
Yes, it does. And it works pretty damn well if I say so myself. That is, I thought so until I yesterday when I discovered that it doesn’t work properly in the case of an Energy Saver pause. It is a situation that would largely go unnoticed because most of the time the first time a command is issued it will take. But the verification checks are there in the case of network problems or other unforeseeable circumstances. Anyway, I was working on a new feature for @gsgentry and so I fixed the issue at the same time. I was just taking a little time to test it.
Now, as I said earlier, I don’t think this will necessarily solve your problem @Yossarian. 50% is a high failure rate. But once we see the verifications working in your logs, it should provide us with more clues as to the real culprit in your case.
Please make sure that debug logging is on and record a couple instances of this functionality, both successes and failures. It can take a few minutes for the verification checks to run so make sure to capture those. And don’t forget to update to the new version. Post your results and we’ll go from there!
I updated to the new version and tested it twice. The first time it failed to return to cooling mode after closing the door. The second time it succeeded
Here are the logs, thanks!
11:52:08 PM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has successfully entered cool mode. (1/3)
11:51:08 PM: info Thermostat Manager - All contacts have been closed. Restoring cooling mode.
11:49:07 PM: debug Thermostat_Manager.esConflictResolver(): esConflictResolver() will be run again in 121 seconds.
11:49:07 PM: debug Thermostat_Manager.esConflictResolver(): All contacts have been closed. Discontinuing any existing thermostat pause countdown.
11:49:07 PM: debug Thermostat_Manager.contactClosedHandler(): A contact has been closed.
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 75
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 50 | Cooling Setpoint: 73
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Mode: off
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Fan Mode: followschedule
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
11:46:27 PM: debug Thermostat_Manager.tempHandler(): Thermostat Manager is currently paused.
11:46:27 PM: debug Thermostat_Manager.tempHandler(): At least one contact is open: true
11:42:11 PM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has successfully entered off mode. (1/3)
11:41:11 PM: info Thermostat Manager is turning the thermostat off temporarily due to an open contact.
11:39:12 PM: debug Thermostat_Manager.contactOpenHandler(): Initiating countdown to thermostat pause.
11:39:11 PM: debug Thermostat_Manager.contactOpenHandler(): A contact has been opened.
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 76
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 50 | Cooling Setpoint: 73
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Mode: off
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Fan Mode: followschedule
11:32:18 PM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
11:32:18 PM: debug Thermostat_Manager.tempHandler(): At least one contact is open: false
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 75
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 50 | Cooling Setpoint: 73
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Mode: off
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Fan Mode: followschedule
11:29:47 PM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
11:29:47 PM: debug Thermostat_Manager.tempHandler(): At least one contact is open: false
11:28:21 PM: info Thermostat Manager - All contacts have been closed. Restoring cooling mode.
11:26:20 PM: debug Thermostat_Manager.esConflictResolver(): esConflictResolver() will be run again in 121 seconds.
11:26:20 PM: debug Thermostat_Manager.esConflictResolver(): All contacts have been closed. Discontinuing any existing thermostat pause countdown.
11:26:20 PM: debug Thermostat_Manager.contactClosedHandler(): A contact has been closed.
11:17:36 PM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has successfully entered off mode. (1/3)
11:16:36 PM: info Thermostat Manager is turning the thermostat off temporarily due to an open contact.
11:14:36 PM: debug Thermostat_Manager.contactOpenHandler(): Initiating countdown to thermostat pause.
11:14:36 PM: debug Thermostat_Manager.contactOpenHandler(): A contact has been opened.
@Yossarian, it appears that I only fixed half of the problem. Here’s the other half!
New Build 2021061601
Modifying conditions on the verifyAndEnforce() function’s mode enforcement operations in order to allow for proper enforcement when exiting the Energy Saver pause state.
Install this one and then run through the test steps as before. As previously stated, this won’t fix your problem. It is more of a workaround but it should provide clues as to the real cause.
Progress I think! It didn’t turn back on after 2 minutes but another minute after that it retried and was successful. I’ll do some more testing later to see if I get any more failures. Thanks!
1:49:30 AM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has successfully entered cool mode. (2/3)
1:48:30 AM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has failed to initiate cool mode. (1/3) Trying again.
1:47:29 AM: info Thermostat Manager - All contacts have been closed. Restoring cooling mode.
1:45:28 AM: debug Thermostat_Manager.esConflictResolver(): esConflictResolver() will be run again in 121 seconds.
1:45:28 AM: debug Thermostat_Manager.esConflictResolver(): All contacts have been closed. Discontinuing any existing thermostat pause countdown.
1:45:28 AM: debug Thermostat_Manager.contactClosedHandler(): A contact has been closed.
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 75
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 70 | Cooling Setpoint: 73
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Mode: off
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Fan Mode: followschedule
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
1:45:10 AM: debug Thermostat_Manager.tempHandler(): Thermostat Manager is currently paused.
1:45:10 AM: debug Thermostat_Manager.tempHandler(): At least one contact is open: true
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Thermostat Manager standing by.
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Indoor Temperature: 76
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Heating Setpoint: 70 | Cooling Setpoint: 73
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Heating Threshold: 68 | Cooling Threshold: 73
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Mode: off
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Fan Mode: followschedule
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Hello Home Mode: Home
1:42:30 AM: debug Thermostat_Manager.tempHandler(): Thermostat Manager is currently paused.
1:42:30 AM: debug Thermostat_Manager.tempHandler(): At least one contact is open: true
1:40:41 AM: debug Thermostat_Manager.verifyAndEnforce(): Thermostat has successfully entered off mode. (1/3)
1:39:41 AM: info Thermostat Manager is turning the thermostat off temporarily due to an open contact.
1:37:41 AM: debug Thermostat_Manager.contactOpenHandler(): Initiating countdown to thermostat pause.
1:37:41 AM: debug Thermostat_Manager.contactOpenHandler(): A contact has been opened.
@Yossarian well, I can’t think of what else might be going on to cause this delay. Maybe the cloud based device handler has some sort of forced pause in processing commands? I would suggest looking at My Decices > Thermostat > List Events (in the IDE) when the problem occurs and see if you can get further clues as to what is going on. I suspect that this workaround may be the best we can do though.
