SmartThings Community

[RELEASE] 5-2 Day Programmable Thermostat Scheduler (Weekday, Weekend) with Remote Temperature Sensor for each Schedule

For the advanced version of the app, have you considered doing a runtime monitor. Something that would let me see the runtime for the day at a minimum.

I have switched from the wifi version of the thermostat to the zwave one, and the one thing I miss in the RadioThermostat mobile app is the runtime reports that are available.

1 Like

That’s a neat idea for the Thermostat DTH since it has an interactive user interface v/s a SmartApp that runs in the background with just a configuration interface.

Hello everyone,
New ST user here. First, thank you RBoy for putting out this SmartApp. To one degree (no pun intended) it is exactly what I’m looking for. I’ve been trying the free version before I commit to purchasing the advanced, but I am having an issue that I hope someone can help me with.

I recently purchased a home with all electric baseboard heat (woof!). I plan to change it out, but will have to suffer through this winter with it. Because it’s line voltage, I essentially had only one option for a smart thermostats. I went with the Stelpro Z-Wave Plus KI STZW402WB+. I have two of them in bedrooms. I have a brand new Samsung STH hub. I have created the SmartApp based on the code provided here. My problem is that it only switches scheduled entries correctly intermittently. For example, I have it set to start heating at 6am to 69 degrees and then to let it drop to 63F at 8am. Often times, it won’t switch either thermostats to 63F @ 8am. If i go into the SmartApp, change nothing, and simply hit “Save”, it will then switch to the proper temp setting for that time period. The behavior is intermittent. Sometimes it works as scheduled, other times it requires the “fix” I mentioned about which defeats the entire purpose. I have verfied my settings in the SmartApp. I have modified my schedule in the SmartApp. I have manually reboot both the thermostats and my STH hub. The problem still exists. One thing I will do over the weekend is look through my firewall logs to make sure nothing is being blocked. Outside of that, I’m at a loss and I’m considering going back to just plain old non-“Smart” thermostats. Any input is greatly appreciated.


1 Like

You’re welcome.

What you’re describing sounds like a typical mesh issue. Is the mesh is weak it can “lose” commands so it appears that sometimes it works and other it doesn’t.

The solution is to add a repeater close to your device.

It a very common issue especially with locks and thermostats. Here is a topic explaining the issue and why repeaters are needed even if the hub is close to your devices. (It’s for locks by applies to most beaming and sleepy devices)

1 Like


I am using 5-2 Day Thermostat Scheduler on my Zwave thermostat.
But it does not decrease the temperature setpoint when the time comes.
For example, I have a "sleep time " set to 22:00 and the “sleep heat temp” is set to 20 (celcius)
The previous setting is 22 (celcius)
When the time comes, (22:00) it writes to the thermostat history “thermostat program sent setHeatingSetpoint command to Heater” but the temperature setting did not change . It is still 22.
What is wrong ?

smart app version : “03.09.00”
device handler version : “04.03.03”

the devicehandler works fine as a standalone device.


Check out my post above about lost commands.

Also try wiring your thermostat with the C-Wire which helps it not “lose” commands (it switches from beaming mode to active listening/repeating mode). After adding the C-Wire your thermostat you will need to be excluded and re paired with the hub for the changes to take affect.

EDIT: Maddie is working with you on this, looks like your hub has a wrong/different timezone assigned to it which causing the app to fire at time different from your local time.


There is no problem of operating the thermostat as standalone device with the device handler.
It gets the command each time I try.

The problem is between the Smart app (from RBoyAPPs) and the device.

And to clarify, my thermostat is running on C-Wire and very close to the ST Hub.

There is a problem of setting heatingsetpoint through the 5-2 Day Thermostat Schedule app.
I am waiting for your further instructions about my situation.

@RBoy I’m experimenting using the Sinope thermostat (heating only) with the app and was wondering about a permanent hold as well as a seasonal or vaca hold.

I saw someone asking about permanent hold in the thread but didn’t see an answer. Thoughts?

As far as seasonal hold, that would be a sweet feature for the app if you could have a modifier for the schedules that allows you to set months of the year or similar where you want the thermostat held to a certain temp (like say 50F during the warmer months).

For a vaca hold, I guess you could create a ST mode for that to and set the app to not do control during that mode only which I think would stop the scheduled changes. Any other possibilities?

This feature already exists. If you want a “permanent hold”, just deselect the thermostat from your list of thermostats in the app. It won’t program the thermostat. All the settings will remain as is. When you want to re-active it, select your thermostat. This was implemented in this manner (rather than through a button) because some folks synchronize multiple thermostats schedules within single app, this way they can put some thermostats on permanent hold while other continue to operate normally.

Will add it our feature request list

This feature already exists. You can select the Operating Modes in the app. E.g. you can select Home and Night from the list. When the hub changes to Away, the app won’t operate

@RBoy, @maddie
Thanks to Maddie from RBoyapps, we could finally solve the issue using a workaround on the smart app code.
Actually it is a issue to be solved on the ST cloud. But nowadays ST support is too SLOW…
I will be waiting a permanent solution from ST support anyway…

@mrmrmrmr, thanks for the update. I have also been experiencing this intermittent issue where my thermostats are all individually controllable but the 5-2 app scheduler does not consistently take effect. It started happening in the past 30 days (scheduler worked fine for the past couple years) so your note about this being a ST cloud issue would make sense.

In the meantime, can you share the workaround you used in the smart app?

Thank you!

In his case the timezone assigned to the hub by ST was incorrect which was causing the timers to fire at the wrong time.

If it’s started recently then it’s more likely a mesh degradation issue, check out this post:

my problem is directly related to wrong DST and Timezone setting for my region and it started after DST change at US. So I believe your problem is different.

1 Like

Thanks @mrmrmrmr and @RBoy, I have 7 Zigbee thermostats and 2 smart plugs scattered around the house so coverage should be very good but I will check out the mesh issue details if this persists. I updated to Rboy’s latest app and at the moment the thermostats are behaving according to their schedules.

New rboy subscriber here.

I just installed the Programmable Thermostat Scheduler smart app. I’m using the rboy Device Handler (“Enhanced Z-Wave Plus Thermostat”) to control the thermostat.

I just purchased a Smartthings Multipurpose Sensor, which I’m using as the remote temperature sensor for all schedules.

I went through and set all the schedules for 70 degrees heat, 75 degrees cool.

It seemed to work at first, setting the heat temp to 85 degrees when the remote sensor registered under 70, and then down to 45 when the sensor registered 70.

But last night, the heat ran continuously, even as the remote sensor registered all the way up to 80 degrees.

Is there something I’m missing?

Add some repeaters if you’re using a remote temperature sensors. You mesh is weak and the events/commands aren’t reaching the devices/thermostats consistently. If you have a CT-xxx thermostat model running (and pairing) it with a C-Wire helps improve the mesh/device reliability greatly. Also helps to reboot the hub and do a Z-Wave repair.

Discussed a few posts above:

Thanks for the advice, but the mesh doesn’t seem to be the problem. We have a pretty small apartment, and looking at the logs in the Smartthings app shows plenty of communications sent by the sensor and received by the thermostat while it was failing to turn off. (attached some screenshots)

The images are a good start point, you may need to dig deeper into your device events logs as the Recently tab is only showing that the SmartApp has sent the command to the DTH. I’m not seeing too many acknowledgements (it just means that you can’t tell if the command reached the device or not from the Recently tab). For example at 9:02am I see the acknowledgement from the thermostat that the setpoint was set to 68F. I don’t see any during the night (just commands being sent to the DTH).

In general there could be three reasons for what you’re seeing:

  1. There is a communication issue (quite common with beaming devices), I’m sure you would read from my previous post why beaming devices (thermostats, locks etc) can suffer from mesh issues even if they’re sitting in front the hub. FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?
  2. You can wait for a few days and see how it behaves. If it happens again but at a different time of the day/night then it’s likely the first point. However if it happens at the same time/schedule everyday it’s likely a setting in the app (e.g. folks forget to select a remote sensor / incorrect settings etc)
  3. There’s another app which is overriding the settings of the thermostat/causing a conflict. This one is easy to figure out, if you click on the SmartApps tab under your thermostat device page it’ll show all the SmartApps that are controlling/using the thermostat

These are starting points but likely you’ll have observe it over a period of time to narrow it down

@RBoy @maddie I’ve been having an odd issue with the app. On a couple of occasions, like at least 2-3 I can recall, the times in the schedules have flip-flopped their AM/PM settings. For instance, here is the schedule I have for one Thermostat that is correct:

But. just earlier, I was looking in the app and the 12-hour times were all correct, but the schedule was off by 12 hours (so 5:00pm Wake, etc.). I have no idea what could be causing this to seemingly revert. The first time I assumed I had just goofed the settings, the second time I thought well, maybe I didn’t fix it the first time, but the third time I’m sure. When I saw the AM/PM shift I looked in the IDE and the settings seemed to match what was incorrectly shown in the app - off by 12 hours (sorry, no screenshot of that FWIW).

But, having said that I’m not sure if the AM/PM thing is the real oddity. The other thing I can’t seem to explain is that the historical IDE logs don’t seem to be matching the schedule either. For example:

Seems like the app is issuing the command an hour off from when it should if I compare the schedule to a few of the times in the log. Even if the AM and PM are swapped the actuals still didn’t seem to quite align.

I am running v03.09.02.

Any ideas?

Sounds like the recent platform outages may have played havoc with your account schedulers or corrupted some settings. A few posts above you’ll see Ilker has similar issues and it turned out that the platform had messed up the hub timezone interpretation and was firing this schedules one hour ahead of the time that the app was asking it to fire them.