Changing mode based on outdoor temps?

[wkearney99]

What's the recommended event structure to handle switching the system mode on a thermostat based on outdoor temps?

I've got four thermostats, all interconnected with a redlink gateway and an on-site outdoor thermostat sensor. During the transition periods between seasons it's tricky to let the thermostats decide whether to use cool or heat. Auto mode really never seems to work effectively. This past week we've seen daytime highs nearly 80F and lows down to 40F.

I have all my thermostats running on their own internal schedules. I don't generally interfere with them via automation as the scheduling meets my needs pretty well.

The system is geothermal, so making the transition for heat does mean a bit of a ramp-up time. Cooling is a bit quicker.

Does the plug-in have a way to see the setpoints for the other modes? Or only the active system mode?

I'm wondering how to best approach automating the mode change between heat/cool. I can see outdoor temp, /current/ setpoint temp and the system mode.

[shill]

One of the decisions I made early on in this plugin (that I wish I hadn't) was to simplify the setpoint process because my then-current logic was much easier to implement this way. So I made a conscious decision to consolidate those setpoints into a single device unless your device supported Auto mode. You can override that by turning on "simulate Auto mode" for devices that don't (or if my detection logic is faulty for some models?). This will give you both setpoints.

In the HS4 version I actually plan to always show both setpoints...

[wkearney99]

Our local weather is getting quite a workout this week.

[ewkearns]

We are seeing the same thing. As I understand it, you may be able to assign a "master" thermostat that overrides the other settings. Failing that, you will have to create a logical master thermostat and give it precedence over the other thermostats.

In my case, I have made the master bedroom the virtual master and if it is calling for cooling and any other zone says, "Heat," I turn that zone (or zones) calling for heat off until morning. The bottom line is that if one or more zones are calling for heat and one or more zones are calling for cooling, the HVAC probably will go into "WTF?" mode and do nothing until all zones agree.

I'm beginning to appreciate the logic behind a gaggle of mini-splits...

[wkearney99]

What are the other implications of using the Simulate Auto mode?

And, curiously, of the four thermostats I have (all are the same model#) one of them is showing me both a cool and a heat setpoint. The others are only showing a single "Setpoint" value. When I use the Android "TCC" app it doesn't show anything different between them. That and the unique one shows just "heat setpoint" and "cool setpoint" and not one called just "setpoint".

Why is that one showing both setpoint types and not the others?

Maybe something like this kind of logic (using easytrigger to get device-to-device comparing logic)

if outdoor temp > setpoint
andif system mode has been heat for at least 5 minutes
then set system mode to cool

This would avoid the event running "all the time" when it's already in cool mode, correct? And this, vice-versa?

if outdoor temp < setpoint
andif system mode has been cool for at least 5 minutes
then set system mode to heat

Or am I setting myself up for a problems with something this simple?

[wkearney99]

We are seeing the same thing. As I understand it, you may be able to assign a "master" thermostat that overrides the other settings. Failing that, you will have to create a logical master thermostat and give it precedence over the other thermostats.

In my case, I have made the master bedroom the virtual master and if it is calling for cooling and any other zone says, "Heat," I turn that zone (or zones) calling for heat off until morning. The bottom line is that if one or more zones are calling for heat and one or more zones are calling for cooling, the HVAC probably will go into "WTF?" mode and do nothing until all zones agree.

I'm beginning to appreciate the logic behind a gaggle of mini-splits...

Mine are not mini-splits, rather I have two geo-thermal well loops (350' deep) and three heat exchangers. One exchanger is integrated to the air handler, but has zoned dampers. The other two have their air handlers located separately and have refrigerant lines pumped between them and their geo-thermal exchanger. It's been a remarkably reliable system. We switched from gas heat, and nearly tripled the available occupied space and our total utility costs stayed pretty much the same (no doubt also due to MUCH better insulation).

The below-ground lower level systems almost never need either heat or cooling. Circulating air, sure, but insulation is such that it stays remarkably stable down there. I don't usually have to ever take them out of heat mode.

The main level for heat is pretty stable. Cooling is sometimes a bit trickier to balance as there really should be different zoning, but I'm not wandering down THAT road. It's mainly summer sun and full southern exposure problem that tends to drive up the temp of the home office, while leaving the rest of the main level a bit too cold.

It's mainly the upstairs level that's more sensitive to heat/cool mode flips. And since all the HVAC is geo-thermal I need to keep recovery time in mind. Making cold air is relatively quick, as underground water temp makes it pretty much "free". But for heat it takes longer to drive the cold out of the spaces. Not "a lot" longer but enough that it's not a simple matter of figuring out at bed time, oh it's cold up here, better flip the mode. Using the built-in 'auto' mode in the thermostats has been less than satisfactory. I don't know why. So I usually just manually change their modes during the month of March or October.

I've been using the on-device schedules and they've worked well. Since the 'school from home' setup is on the lower level I didn't really even have to change the scheduling during the pandemic. Thus I really haven't had to use HS for any thermostat control.

So I don't have much need to address them as a whole system, but could see where others might.

[shill]

What are the other implications of using the Simulate Auto mode?

Turning that checkbox on does 2 things: ensures you have both setpoints AND ensures you have an "Auto" option. The only thing that could caused weirdness is if you actually HAD an auto-capable thermostat AND you were using it in Auto mode. Otherwise I recommend leaving that setting on with the current version of the plugin. If you don't want to use Auto mode, just don't pick it

And, curiously, of the four thermostats I have (all are the same model#) one of them is showing me both a cool and a heat setpoint. The others are only showing a single "Setpoint" value. When I use the Android "TCC" app it doesn't show anything different between them. That and the unique one shows just "heat setpoint" and "cool setpoint" and not one called just "setpoint".

Why is that one showing both setpoint types and not the others?

I can only assume there was a bug in the initial evaluation or by turning simulate auto on/off it failed to react correctly.

Maybe something like this kind of logic (using easytrigger to get device-to-device comparing logic)

if outdoor temp > setpoint
andif system mode has been heat for at least 5 minutes
then set system mode to cool

This would avoid the event running "all the time" when it's already in cool mode, correct? And this, vice-versa?

if outdoor temp < setpoint
andif system mode has been cool for at least 5 minutes
then set system mode to heat

Or am I setting myself up for a problems with something this simple?

That would work if you want to just use a single setpoint. Otherwise turn on the checkbox and just use the same idea but compare the correct setpoint in each.

[wkearney99]

Yes, I enabled the checkbox, stopped the plug-in, restarted HS and re-started the plug-in and now all four show both the cold and heat setpoint device.

As expected, the event logic no longer worked, as the sole "setpoint" device was gone. I changed the devices, accordingly. Comparing the outdoor temp against the cool setpoint IF the system has been in heat mode. Likewise, comparing outdoor temp against the heat setpoint if the mode has been on cool. I'm hopeful that will handle things properly.

I've learned it's useful to take on a speak and an e-mail action so I have notification when testing events like this. Both to make sure it's actually happening at all, and not happening TOO OFTEN.

[wkearney99]

I've refined my event logic a bit to check if the 'outdoor temp has a value that just changed' as the trigger.

For debugging it's been fortunate the temp has been dropping pretty quickly during the past few hours. According to HS it was dropping about a degree F every half-hour. And over the past hour it's been rising a bit. I've been able to manually kick the system mode into 'cool' and wait for the next temp change to fire and it seems to be working.

While thinking about this it also occurs to me that it might also be worth checking the 'hold type' on it, to avoid stepping on any manual intervention.

I know HS gets tricky sometimes with using triggers on values. I don't want to have the system waste effort checking "all the time" but don't want to miss things either.

Should I use (or not) the "Do not update last change time" checkbox for the Outdoor Temp device? I ask this because I just noticed the "Last Change" timestamps on the Outdoor Humidity and Outdoor Temp devices are different. Which, I gather, is based on the fact that the temp value had not changed since then, but the humidity had changed, right?

[Bob-O]

I’ve had this running for over a year with good success. Especially during spring and fall, when the temps vary. It runs when I am not there. It’s a bunch of events.

I have a virtual with 3 states. HEATING, COOLING, OFF. (I like to have my states be in all caps.)

At the top of every hour, 3 event can be triggered. And one of them will trigger every hour, depending on temperature.
1 - if the temperature is below 60°, set mode to HEATING
2 - if temperature is greater than 60° and below 80°, set mode to OFF
3 – if temperature is greater than 80°, set mode to COOLING


There are then 3 more events. One for each HEAT, COOL and OFF. These only get triggered when the mode actually gets changed.