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

[mrmrmrmr]

Hi,

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.

Thanks.

[RBoy]

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

Check out my post above about lost commands.

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

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)

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.

[mrmrmrmr]

Hi,

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.

[LLwarrenP]

@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?

[RBoy]

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

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.

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).

Will add it our feature request list

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

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

[mrmrmrmr]

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, @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…

[Iguana]

@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!

[RBoy]

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

It started happening in the past 30 days (scheduler worked fine for the past couple years)

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

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

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)

[mrmrmrmr]

in the past 30 days

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.

[Iguana]

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.

[tallzsb]

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?

[RBoy]

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:

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

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)

[tallzsb]

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)

[RBoy]

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

[LLwarrenP]

@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?

[RBoy]

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.

[LLwarrenP]

Ok, I thought about that after reading those posts but somehow didn’t connect it. I reset the settings again and I’ll keep a closer eye on it. As of today, the settings are still what I expect them to be and the logs indicate that the changes are occurring at the desired times.

Thanks!

[Puskaitis]

Maddie:

Thank you again, for your excellent customer service. The Centralite Pearl thermostat is now responding quite well to commands from your Ultimate Mode Based Thermostat Temperature Management smartapp .(http://smartthings.rboyapps.com/Smart%20Apps/Mode%20Change%20Thermostat%20Individual%20Temperature.groovy.txt)

I am now able to run the upstairs thermostat on a different circadian cycle depending on whether I am home or only my son is home. I have two sets of modes that cycle through 24 hours and different settings for each in the smartapp.

The smartapp is also able to heat the upstairs based on temperature in the bathroom that each of us uses, respectively, to accommodate different use patterns.

Really nice service changing the “forced setpoints” to accommodate limitations of those thermostats. If I ever use this smartapp at my cabin, with Sensibo units, I may ask for another update, since the low temp on those units is 50 degrees F.

Thank you for producing really useful smartapps. These have saved me from learning groovy, which I may do in retirement.

Mike

[MRobi]

Having a few compatibility issues here. Using in conjunction with the Ultimate Mode Based Thermostat app to have a schedule and then have different set points for away/vacation mode.

The DH I’m using is this one for my Daikin mini split system.

[RELEASE] Daikin WiFi Split System v1.4.1

[preview] UPDATED 1.4.1 - (11/12/2018) - Implemented fix for B-type adapters (‘Host’ header case). Big thanks to @WGentine This Device type allows the integration of Daikin Split Systems that have the optional “WiFi module” installed. Most commonly, this is the “BRP072A42” module. This Device Type has only been tested with that module, however other modules (such as the BRP069A42) should be compatible. It implements the SmartThings “Thermostat” capability, which means it has full compatibility with most thermostat automations and allows integration with platforms such as Google Home. Note that “P” Series units (FTXMxxP) do not support fan direction or rate controls. Features Ability to set desired temperature Ability to set desired mode (Auto, Cool, Heat, Dry, Fan) Seperate temperatu…

The issues I’m running into:
1: App will not switch between heat/cool modes. If I manually select heat through the device, every command sent from the app is setHeatingSetpoint. If I manually select cool, then it switches to setCoolingSetpoint.
2: This DH doesn’t support fan adjustment with my model. If I select any of the fan options in the settings, it will set the device into full fan mode (blows air in from outside)
3: My solution to #2 was to simply leave the fan options blank however the app appears to be still sending multiple ThermostatFanMode commands which keeps switching my unit to full fan mode.
4: At some point this morning it sent a command to set the heating setpoint to 8 degrees followed by a command to set it to 20. ??

[RBoy]

At the outset it appears to be working as designed and some issues you’ve pointed out all appear to be related to your custom thermostat DTH/configuration.

1. The app does not change the thermostat mode set by the user. It reads the mode set on the thermostat and then sends commands accordingly, if it’s set to Auto mode, the app will send heat and cool setpoints, if it’s set to Heat mode the app will only send heat setpoints etc. The only time it switches the mode is if you’ve configured the outside temperature sensor section and defined a temperature threshold to switch between heat/cool. If you’re looking for automatic switching of the mode the DTH will need to support Auto mode. The point of using a Thermostat DTH is that it needs to be compliant with requirements of a thermostat capability. The app can take over the thermostat responsibilities when a user is trying to create a heating/cooling setup using switches to controls fans, coolers/heaters etc but then you need to select the appropriate switches/sensors in the app so it will emulate the heat/cool/auto modes when a thermostat is not being used.
2. The app will change the fan mode only if it’s defined in the app (check your settings again) or unless an outside temperature section is configured to use sensor to switch between heat/cool modes (in which case it sets the fan to Auto mode). If the HVAC doesn’t support fanAuto mode then the DTH should handle it accordingly. From what I see in the DTH code it turns the fan On when it receives a fanAuto command, and from what you’re explaining, it should be turning the fan Off or ignoring the command. I also see that the DTH doesn’t implement the setThermostatFanMode command.
3. See point 2, the custom DTH needs to be updated
4. Check your app settings