Thank you. I moved away from the Thermostat Scheduler because of problems like this. My rules were working well until just recently when they started misbehaving also. The old issue of the setting being changed and then immediately reverting to the previous setting has cropped up again. The odd thing is that it will work several times and then misbehave. I thought it was a WiFi issue, but even trying to set up my WiFi to use 2.4 GHz band channel 1 while the hub to which the thermostat is linked (C4) is set to Zigbee channel 20 which should be more than far enough away from the frequency to minimize the possibility of interference. I am also trying to use the 5 GHz band WiFi channels as much as possible.
If the scheduler is fixed now, I may start using it again instead of the rules I made.
I've happily converted to using Thermostat Scheduler the last couple of months versus some RM rules I had previously created. Along with Mode Manager I've found the maintenance much easier!
As a couple of enhancements I'd like to request the following:
Add the ability to configure temperature threshold(s) (I happen to use the OpenWeatherMap device) for setting the thermostat mode to Cool, Heat or Off. I like to set adjust these thresholds during different parts of the day (now set via Mode Manager). I currently do so in a very long and hard to maintain RM rule.
Add the ability to configure temperature threshold(s) for setting the thermostat fan to Auto or On. I don't currently adjust these thresholds during different parts of the day but may want that as an option. I also currently do so in a somewhat less complex RM rule.
Could you explain how this would work (in the app). Where would the temperature for making the decision come from? Same question for the fan to Auto/On? Do you want to simply select some temperature sensor as the source?
Yes I'd like to select a device with temperature as an attribute. In my case I have a virtual weather device using the built-in OpenWeatherMap device type. For illustrative purposes, here's some of the logic I use to set the thermostat mode based on time of day (hoping to move to modes soon) and weather device temperature. I'm sure there's a better way to build the rule, but I'd prefer to have some configurations available in the Thermostat Scheduler in a table-based layout. One thing to note is for cooling I have a single lower threshold, for heating a single upper threshold and for off I have a range that's inside the heat and cool thresholds. I keep the off threshold range a few degrees away from the other thresholds to prevent multiple mode changes occurring too quickly.
Why is this approach better than just having a thermostat with automatic heat/cool mode, where that is implemented by Thermostat Scheduler. Say the indoor temperature is below the heating setpoint, it turns on heating until the indoor temperature reaches the setpoint. If the day warms up, and the temperature exceeds the cooling setpoint, it turns on cooling until again the setpoint is reached. Wouldn't this be a better approach to indoor comfort that an external temperature source?
That's a good question. To your point, regardless of outside temperature if cooling setpoint is at 72 and indoor temperature goes above 72 then set the thermostat mode to cooling? I could go with that if I'm able to have cooling turned on if indoor temperature goes x degrees (e.g. 2 or 3 degrees) above the indoor temperature. Similarly turn on heating if indoor temperature goes below heating setpoint by y degrees. Is this currently possible, and if so, how is it done? I'd prefer to not have heating/cooling turn on/off by going above/below setpoints by a single degree. I say that because I'm okay if my family learns to live with temperatures that aren't always 'perfect'!
This is a function of the thermostat itself. All thermostats have a delta that they use to switch from idle to demanding heat (or cool). They are also designed not to cycle the heat/cooling source too rapidly (would damage a/c). In some thermostats this is settable, but not in most. Thermostat Scheduler itself has an optional required offset between cooling and heating setpoints. A thermostat with a true auto function also enforces an offset between heating and cooling setpoints. This is obviously to prevent a thermostat from demanding heat, warming up the interior, and then immediately demanding cooling to cool it back down, thus setting up a vicious cycle. Instead, the indoor temperature drifts between the two setpoints leaving the heating/cooling source in idle. This offset varies, but is typically 2° or 3° F. In most climates, auto mode is only relevant during a brief period of the season, where it's cold enough at night for the system to demand heat, while warm enough during the day to demand cooling. After this brief period in the fall, the system will remain in heating mode 24 hours a day until the next spring, when it again will utilize auto for a brief period before going into cooling mode 24 hours a day (even with no cooling demand, the house will be above the heating setpoint).
The design of heating and cooling systems is an engineering discipline with some depth and complexity to it. Generally speaking, this is best left to experts in the field and with an eye to the specific furnace and air conditioning units actually installed. There are issues about the rate of heat loss / gain to be considered in the design, which are factors of the design of the home, its construction, materials, insulation, etc.
At one point earlier in its life, Thermostat Scheduler always enforced a 2° F separation of heating and cooling setpoints. Then, some users with a valid use case requested that this be optional, as it now is. For an auto mode to make sense, it would have to again force that the separation be enforced, so as to avoid vicious heating/cooling cycling that is possible with auto mode. Irrespective of Thermostat Scheduler, some thermostats do enforce this separation. The Lutron Honeywell thermostat does this. If Thermostat Scheduler sets the heating and cooling setpoints too close, the thermostat overrides the setting, and enforces the separation. This is reported by the thermostat back to Thermostat Scheduler, who will dutifully make note of it in its settings, thus foiling the attempt by the user to violate the separation.
Is it possible to maybe add a date scheduler within the thermostat scheduler?
I currently have a rule set up that if it's between October 1st and May 31st then set the heat to-xx. If between June 1st and September 30th then set heat to XX.
the reason I have this currently is because sometimes in the Summers where I live it could get a little chilly and I really don't want my furnace to come on if the house gets below a certain temperature as if it were winter.
Looks good to me. Easy to test it. Just change the condition to one involving between two times, and see if the thermostat is set the way you expect. Then change it back. You can create a new condition, and edit the rule to change which condition is used in that IF-THEN action.
@bravenel. I changed the trigger so it won't run everyday. I've tested and seems to work great.
I do have a 3rd thermostat down in the family room. This one is set to 62 unless my stepson is home. Which is every other week. I don't think the thermostat scheduler works on presence does it?
Instead of triggering once a month and using a conditional, why not just use Periodic to trigger it on the dates you want to change it? I'd use two rules, Winter and Summer (or whatever names), each triggered on the date that change should take effect -- and there would be no Conditional Action at all -- it would just change the thermostat on that date.
