Everyone's entitled to their own opinion, so I'm not jumping into the argument part of this thread, but I 100% agree with @Ryan780 that this is a problem.
If you're in cooling mode it shouldn't send a heating set point, and if you're in heat mode it should not send the cooling set point - for the exact reason Ryan described... Minimum differentials on the thermostat side could cause unexpected behavior.
And that is not specific to his thermostat, almost every thermostat works that way.
I was just looking at this issue the other day. I've worked around it by adjusting my set points for the summer (lowered the heating set points past the differential delta), but the long-term answer is that thermostat scheduler needs to be changed, or someone needs to write a better behaved app.
I have no plans on writing a sharable app for this. If I do write one it will be a quick app that meets only my needs, not one that's publicly released. That's just way too much effort for me right now.
I don't know if the Rule Machine would be able to do what you are asking. We all know the Thermostat Scheduler isn't doing what you want because the thermostat itself won't allow the same set points for both cooling and heating. Delete the Thermostat Scheduler and try the Rule Machine instead. If it works, great! If not, you are no worse off.
Yes, and it displays as much in Thermostat Scheduler.
That is what I am currently doing. I am setting the set by modes setpoints based on the Thermostat's operational mode (heat vs. cool). So, when in heating mode, all of the Cool setpoints are 90 and when in cool, all the heating setpoints are 50.
But since this doesn't seem to be getting any attention at all, tagging @patrick@bravenel@mike.maxwell. Would someone from the HE please comment? I would think that anything in the Support category should get some type of reply from staff even if it is to say that you're looking into tit. Some acknowledgement would be appreciated.
So how is it supposed to know whether or not to send a setpoint? If you change the cooling setpoint while it is in heat mode, it shouldn't send it? I don't buy the argument that it should not send a cooling setpoint when it is in heating mode. Then, when you change to cooling mode or to auto, what should happen? If it sends the cooling setpoint then, and it's the same as the heating setpoint, the thermostat is going to react badly.
Thermostat scheduler knows what mode the thermostat is in. Whether it's Heat:
Or auto:
or cool. So, I would think that it would only change the heat setpoints if in heating mode, only the cool setpoings in cool mode and both in auto mode. Wouldn't that make sense?
No, that doesn't make sense. How then could you change the cool setpoint when it is in heat mode? You want to change it in advance so that when you flip to cool mode it has the desired temperature.
This seems to be a special case. Obviously, thermostats don't support what you're wanting to do, and would require manual intervention to get the result you want.
Most thermostats use 2° required offset, some 3°. There would have to be an option in Thermostat Scheduler that would cause what you want to happen -- only when the two setpoints would fall within the required offset, thus avoiding the thermostat from changing the setting you put in.
Logic would be this: If setpoints close, and in heat (cool) mode, only send heat (cool) setpoint. Perhaps the option is as simple as just specifying the required offset, in effect defining what "close" means.
Update: Have added this feature to Thermostat Scheduler. Next release...
No... I don't. A perfectly valid use case is a set point of 70 degrees when it's in heat, and a set point of 70 degrees when it's in cool. You cannot do that today with thermostat scheduler.
Why should I have to artificially lower my heating set point to move it out of the way, when my thermostat is going to be in cooling mode for the next seven months?
Anyway you answered the question. I'll just make my own app that works the way I need it to.
If I flip the mode from heat to cool to auto, I will just proactively send the correct set point. That covers your use case about needing to preload the set point. I won't preload it, I will watch for a mode change and then send it proactively.
Sounds to me like he is going to put in a "gap" setting that won't let you put the cooling and heating set points any closer together than that in thermostat scheduler... Basically emulate what the thermostat does today, but now on the app side. The way I read it, it will still write both setpoints each time.
That's certainly not what I want... No big deal though... I'm probably 80% done with my custom thermostat schedule app anyway.
App development is easy if you don't have to make it pretty, or take user suggestions. Lol
I presume this won't remove the option to leave it working exactly as it does at the moment?
I am using cooling setpoint as a proxy for another function and rely on it being sent every time in heat mode even if cooling setpoint is actually below the heating setpoint.
Yes, it will continue to send both. To get the other behavior, one has to specify a required separation option, and then it won't send both if in heat or cool mode and the two settings are within that required separation.
I still think it should subscribe to the thermostat mode and base what it sends on the mode in all cases, and then on a mode change proactively send again based on the new mode, but maybe I'm the only one that thinks that way.
My custom app is done and working (basically does what is listed above), so no big deal.
This would blow other use cases out of the water. These setpoints are coming from settings that you yourself have setup. It will suppress sending the opposite mode setpoint in the situation where the two setpoints are separated by less than a range that you can specify. So if you want to always suppress sending the opposite setpoint, simply set a wide range. For the original use case above, a narrow range to deal with setpoints that would cause the thermostat to react badly can be used. For those who always want both setpoints sent, they wouldn't specify any range. All up to you.
