Thermostat Scheduler Revisited

In Release 2.2.0 there are some significant improvements to Thermostat Scheduler ("TS"). These are discussed below:

New Features

Some thermostats do not do a good job of reporting the current temperature on their own. So, the ability to refresh the thermostat periodically has been added. This can be set in the Manual Setting page.

Logging is now an option for TS.

When a thermostat is in either Heat mode, or Cool mode -- as opposed to Auto or Off modes, only the corresponding setpoint is set by Thermostat Scheduler. Previously both heating and cooling setpoints were both set in all modes.

The user interface has been reworked in a number of areas. This was necessitated by fully implementing the Required Setpoint Separation feature. Thermostats that support Auto mode usually have a Required Setpoint Separation, where they will not allow the heating and cooling setpoints to be too close together. This is to avoid the risk of the thermostat cycling forever between cooling and heating a space due to temperature overlap from overshoot. TS now fully supports this feature. When enabled, TS will change an offending setpoint setting to always maintain the required separation. This happens when manually setting the setpoints, when establishing the scheduled setpoints, and when external control of TS occurs from Rule Machine. It should be noted that Rule Machine is unaware of the required separation, and could send commands to TS that would violate the separation. However, in this event, TS will adjust a setpoint to avoid this. It will always adjust the setpoint not being set. In general, when both setpoints are set, the heating setpoint is set first, and then the cooling setpoint.

Example: Suppose the required separation is set to 3Ā°. Suppose RM sends a command to set the heating setpoint to 74 and the cooling setpoint to 76, which would violate the required separation. Suppose the current settings in TS are heating 72 and cooling 75. When the command is sent by RM, and TS sets the heating setpoint to 74, it would discover that the then current setting for cooling of 75 needs to be changed, and would set it to 77. Then, when TS sets the cooling setpoint to 76 a moment later, it would discover that the heating setpoint of 74 needs to be changed, and would set it to 73. These adjustments would occur before TS sets the thermostat itself.

There is a new command available in Rule Machine that will cause TS to set the thermostat according to the current schedule. A number of users have found a need when using Hold in TS, and expecting the thermostat to be set to the current schedule when Hold is released. While releasing Hold will not by itself do this, a new command "Set Scheduled Setpoints" does this. So if one desires this to happen when Hold is released, simply add the additional action to that rule. Some thermostats have this feature with a button called "Run", that is, run the scheduled settings.

When using the "Use Days" feature in Rule Machine to set the time period setpoints in TS, this will only work if you select days that correspond exactly to one of the days selections in TS already setup.

6 Likes

I just updated, and one of the new features doesnā€™t work for me. My thermostat doesnā€™t support auto mode, so Iā€™ve had a rule that switches it to heat or cool mode as needed when the temperature goes beyond threshold in relation to either the heat or cool set points. Now that only one of the set points in the schedule is being applied. My RM implementation of Auto Mode is no longer working. Is there a way to make it set both set points on schedule, regardless of the thermostat operating mode?

Interesting case. I'll look into it. Gonna be fixing a bug in it tomorrow, so perhaps I can solve this at the same time. It's a pretty simple option to offer, for how it should behave.

Thanks, I would appreciate it. WAF requires that I get it working, so I created a couple of virtual thermostats for TS to control and then used RM to sync set points, mode, and temp between the actual and virtual thermostats. Itā€™s a little clunky, and TS doesnā€™t pick up when the virtual thermostat has its set points manually set from outside of TS, but scheduling seems to be working for now. I also had to turn off the set point separation s as itā€™s new Logic was causing some set points be set incorrectly on schedule.

The ability to choose whether to set one or both setpoints will be in the next release. This should be coming out in a hot fix release update for the hub, probably today or tomorrow.

Hi @bravenel
I'm not sure if there is a bug which you have already identified but I noticed today that something strange is happening.
I can see in TS that the heating setpoint is correct and showing scheduled. Unfortunately the set point doesn't look like it is being 'pushed' to the thermostat. I'm sure it was working yesterday but doesn't seem to be today.
We did have a small power outage but my hub is on a UPS so the hubs stayed powered up OK.
Just seems a bit strange.
Also in TS there is a button called 'Set Scheduled Setpoints'. With logging turned on in TS, when I hit the above button, nothing is recorded in the logs.
Is this correct or is there an underlying issue.
Thanks.

Show me, either here or by PM, your main page for TS. May also need the App Status

It should definitely send the setpoint when you hit that button. One exception is if the setpoint to be sent is what is already set in the thermostat, then it does nothing.

Thanks for this @bravenel.

I've finally bit the bullet and ordered 2 gocontrol zwave thermostats to replace my Nests.

I've been spoiled by @tonesto7's excellent NST manager app on ST that's worked great for the past 4 years, until google pulled the plug.

Any chance we'll see remote temp sensors, and contact/presence based schedules in HE Thermostat Scheduler?

Would you explain how you see this working. A remote sensor is a thermostat function, not really a thermostat scheduling function. See below about Rule Machine.

You can do this now with mode based scheduling. Modes can be based on presence. Thermostat Scheduler does have settings for Away. And Eco Mode allows for the same thing, where Away changes the setpoints. As for contacts controlling it, Rule Machine can control Thermostat Scheduler, so this can be done as well, with your own logic for what to do based on contacts or other temperature sensors.

fair enough... just trying to figure out what combination of apps I need. My first look at Thermostat Scheduler it looked like it could do triggered (mode based) schedules or time-based schedules. Could it do both?

ex.

  • from 8-12am I want the coolingsetpoint to be 77 and observed temp to be average of living room, bedroom, office, and kitchen
  • from 12-8pm I want the coolingsetpoint to be 75 and observed temp to be the average of the living room, office, and kitchen (since the sun shines right on the bedroom temp sensor in the afternoon)
  • BUT if I close my office door (contact sensor) at any time and I am home (presence), I want the temp to be 75 with the observed temp only reading from the temp sensor in my office
  • when my office door contact opens, it's returns to one of the 2 schedules above based on the time

Modes was the lightning bolt I had earlier today, but then I remembered I had 2 thermostats. So if I have 5 schedule scenarios per thermostat, I'd have to create 45 modes to handle each possible schedule combination! Seemed excessive to me...

btw, I am in no way expecting you to do this for me. Just looking for ideas on how I could do it myself.

I know there are apps to get the average temps (think you wrote one of them actually ;). And this app (Thermostat Scheduler) can help with time-based scheduling, and maybe switch/contact/presence scheduling through Rule Machine. I'm just not clear yet on how to do both.

I can use another Rule to update the zwave thermostat temperature based on the average temp, but not clear how to tell it to use the avg temp sensor that corresponds with the temps sensors defined in the schedule

Guess I need to explore Rule Machine some more :wink:

Any ideas the community has would be appreciated.

1 Like

Yes, this is not the right way to go.

Perhaps the answer is in a clever combination. Use Thermostat Scheduler for basic every day schedules, just like you'd program a programmable thermostat. Then use Rule Machine to handle the exceptions. You don't necessarily need to muck with Thermostat Scheduler for the exceptions, some of these you can do just by controlling the thermostat itself.

1 Like

Just a note to let people know that the latest hotfix has fixed the issue that i reported in post #5.
Thanks Bruce. :+1:

If anyone has an issue with setpoints not pushing to your Thermostat, try toggling the switch below on and back off. It seems to have worked for me.

I have an instance where I have a virtual thermostat for a single room, to make it simple I set it to a constant temperature. Right now I guess I need to use RM to change temps based on a motion sensor?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.