Thermostat Scheduler App?

Ok, so I was all stoked for smartthings like Im sure most of you are. I went out and bought a CT100 thermostat and put it in the house. I love being able to control it from smarttthings.

One thing I did overlook, however, is I thought I would still have my 7-day programmable settings on the thermostat that I could then override or control on an action basis from smartthings. Unfortunately its like a completely dumb thermostat without a z-wave controller telling it what to do on a constant basis.
My question is if there is any ideas or plans in the works for creating a Thermostat Scheduler App that would allow you to put in all the times and temperatures for the week? I could create a lot of different smartapps that would accomplish this, but having the ease of the 7-day programming in one screen would be really nice.

I suppose I could spend double the money on a honeywell wifi thermostat but that just seems like a waste.

Thoughts?

Honeywell scheduler

I was told a few weeks ago by ST support they were working on making these programmable either through the Dashboard or an App.

I love the CT100 but I hate the way you have to use the slider to adjust temperature. It takes me a while sometimes to slide it at exactly the temperature I want. I also relayed this to support.

Thats encouraging news @gores95
For now, give this code a shot. It solves the slider problem until something official comes down the pipe. Iā€™m still working on getting it working 100% but others have had great success.
http://build.smartthings.com/forums/topic/better-different-thermostat-device/

I have built a project BTW for this
http://build.smartthings.com/projects/thermostatscheduler/

Iā€™ve had good luck with the ā€œcozyā€ apps: set them to change based on the mode, and then as your modes change the temperature does too.

What I would like to see are ā€œmode groupsā€ so I could have a set of modes for ā€œwinter/summerā€ and ā€œon-peak/off-peakā€ for instanceā€¦ Maybe I should start a thread on that.

The problem I have with the cozy apps is that they happen after a mode has changed. Which means I have arrive at home before the mode changes and the heater begins, or I have to create a ā€œLeaving workā€ mode and remember to change to that mode every day when I leave the office.
I want the thermostat to adjust temperature based on time, not necessarily on mode.

Another cool thing would be if ST would allow thermostat control to IFTTT.
I have Automatic in my car so I could build an IFTTT statement to do ā€œIf Ignition turns on near ā€˜Workā€™ then set ā€˜Thermostatā€™ to ā€˜72ā€™ā€

Agreed on modes!
Is there an easy to program my Smartthings friendly thermostat to not turn on based on external weather forecast from sat weather.com, ie when itā€™s 72ā€™ outside, I donā€™t want thermostat to kick in, but do when itā€™s 53ā€™.
Also how can I program for weekday vs weekend?
I do have it programmed for different times of day & triggered for when I leave & arrive.
Thanks
George

I really think thermostat control is an area that SmartThings could see some huge improvement at. Look at Nest and the amazing UI they have built for it. Having some of those same functions within ST for other z-wave stats would be fantastic.

Using parts of many different smartthings code writing by others, I have developed a 5-2 thermostat program. This code uses an outside temperature sensor (user selected temp) to determine if the thermostat should be cooling or heating. The code schedules for weekdays (Monday - Friday) and weekends (Saturday - Sunday), with four (4) temp/time changes per day, very similar to commercial programmable thermostats.
This code can easily be modified to remove the external temperature sensor.

In previous versions of the code, the program would send the command for fan mode ā€œautoā€ alot, but this is believed to be corrected in this code.

The code can be found at;

Again, I did not write all of this code, mainly assembled pieces and parts from other codes, all believed to be open source. Feel free to use the code as you see fit.

Mike

1 Like

thanks for the effort!
with a new device of type ā€œthermostatā€ applying your code, i get the following error

groovy.lang.MissingMethodException: No signature of method: script1398263568358440900019.section() is applicable for argument types: (java.lang.String, script1398263568358440900019$_run_closure1_closure9) values: [Monitor the temperature..., script1398263568358440900019$_run_closure1_closure9@3177df80]
Possible solutions: getLog(), setLog(java.lang.Object) @ line 8

It looks like this is actually a separate smart app, not a device type. Looks like a great start. I wonder how this would work if I already have a program set on my Filtrete thermostat through their website/app

Has anyone managed to get a 7 days multi times a day scheduler smart app thatā€™s working for the CT-100?
@Ben Iā€™m looping you in to bring this to your attention, there is no app for a 7 day/multi time scheduler functionality for a thermostat. Pretty basic I would say.

@RBoy
3 posts up by @mwoodengr

also

2 Likes

Okay so the code posted by @mwoodengr doesnā€™t work and has some bugs in it, so I took the liberty of trying to rewrite it.

Itā€™s not really a 7 day thermostat but rather a 5-2 day. Anyways Iā€™ve posted the updated code below (and will continue to update it based on inputs here).

@tslagle13 I look forward to your expertise also here and also @docwisdom and @minollo

UPDATE: Removed the code from here, the app is now available here:

[quote=ā€œRBoy, post:15, topic:1480ā€]
1.When I schedule more than 4 items it gives an error in the log ā€œMax number of jobs reached: 4ā€. Why is this and how do I work around this?[/quote]

A trick I often used to take workaround that limitation is to not schedule N events, but only schedule one ā€œtimerā€ event (every 5 minutes or so); the timer event takes care of verifying if the actual time when the event takes place is inside a specific time range in the day, and performs the proper actions based on that. It allows for plenty of plenty of flexibility.

location.timezone is what I typically used; you can use it in Java APIs or to do timeToday(userSetTime, location.timeZone) - to translate the userā€™s set time (say, 8am) to the correct time today in the correct time zone (11/8/2014 1pm UTC in my EST case).

Iā€™m facing a wierd problem While trying to schedule an event but ST is moving the date back by a month.

Hereā€™s the code

    	if (timeNow >= timeToday(time1).time && timeNow < timeToday(time2).time) { // Are we between 1st time and 2nd time
    		changeTemp1()
        	schedule(time2, initialize)
            log.debug("Scheduled next adjustment for ${time2}")
    	}

Hereā€™s what I see the log:

11:03:44 AM: debug Scheduled next adjustment for 2014-10-06T11:02:00.000-0500
11:03:44 AM: trace Scheduling ā€˜initializeā€™ for InstalledSmartApp: d2f62a07-acfa-448a-a859-94b4af249cd6
11:03:43 AM: debug checking mode request = auto
11:03:43 AM: debug Current time is Sat, 8 Nov 2014 11:03:43

If the current date is Nov 8 2014, why is it scheduling it for Oct 6th 2014?

Okay Iā€™ve finally managed to figure out how to handle the time issues and updated the code above. Apparently when one takes a time input from the user the platform assigns a date about 1 month prior to it so I needed to user timeToday() to work around that and reassign the time today.

Thereā€™s however one bug I canā€™t seem to figure out, when I say enter 12:00 at the time (Iā€™m in EST) the system translates it to 18:00 UTC and not 17:00 UTC.

Can someone help me understand why thatā€™s happening? Iā€™m guessing itā€™s something to do with the timezone.

@bflorian could you comment on this please.

The date corresponds to the day when the input was originally set, so I am guessing that you first installed the app about a month ago. Itā€™s mostly ignored for daily schedules though we do use it, in some cases, to guess the time zone if the location does not have geo-coordinates set. I canā€™t tell exactly whatā€™s going on with your incorrect offset without looking at that specific installed smart app, but Iā€™m guessing the problem might be related to the fact that it was daylight savings time when you first installed the app and now itā€™s not. That shouldnā€™t matter, but maybe there some scenario that we missed where it does. Can you try passing in the location time zone to timeToday() and see if you get a different result, e.g.

timeToday(time1, location.timeZone)

Yes @bflorian that seemed to do the trick and how it appears to be showing the correct time.
So 3 questions:

  1. Should the system be taking the date when the was installed or when the user input the time - I guess this question would be redundant in light of question 2 and also for the fact that even if it took the user input date (which should technically be correct), one cannot rely on that as future events would be based on time and date would need to be adjusted.
  2. What is the correct way to handle the inputs given this use case. Is timeToday the right approach or should be some way else?
  3. Why is taking the wrong timezone with timeToday, ie. why should one have to specify the timezone for the current location?

thanks.