A smart thermostat was one of the first connected devices I purchased when I started building our smart home. I wanted automatic presence detection so the thermostat could set an away mode when we leave and "we're home" mode without us having to do anything. Never mind the fact that Rachelle and I both work from home and are both homebodies. On the rare occasion that we're both away from home, the house knows it, automatically! ;)

Throughout the year, I'd find myself fiddling with the set points though. 68°F (20°C) in February feels different than 68°F in August. So twice a year, as the seasons started to tip over into warmer or colder weather, I'd change the upper and lower bounds.

It feels weird to run the AC in winter or the heat in summer. We sleep with the thermostat set at 65°F (18°C). Our preference for day time temp is 68°F to 72°F (20°C to 22°C). So when we wake up, and toggle sleep mode off in Home Assistant, the thermostat sets itself to the day time values and turns on the heat to raise the temp from 65 to 68; even in summer. That bothers me. I'd rather the thermostat just set the lowest temp to 68 and allow the house temp to naturally rise.

Plus, I have all these damn sensors in the house, outside the house, and a weather forecast available. I feel like I have all the inputs needed to make some data-driven decisions.

My climate dashboard.

Goal

My goal was to stop running heat on summer mornings and AC on winter evenings. The set points stay fixed. What changes is the HVAC mode: heat-only, cool-only, or both.

Data

For Home Assistant to pick the right mode, it needs to know what's going on outside, so I made a couple of template sensors.

Outdoor Blend

It all comes down to one template sensor: sensor.outdoor_temp_blend. It's the average of three numbers: the current outdoor temperature, today's forecast high, and today's forecast low. The result tells me what kind of day this is rather than what the temperature is right this minute. That blend feeds sensor.thermostat_season, which labels the day heating, cooling or shoulder-season. The season is what picks the HVAC mode.

Why average instead of just reading the current outdoor temp? A 50°F dawn before a 75°F afternoon shouldn't kick the heater on for an hour at sunrise. The blend flattens out the time-of-day swings so the thermostat isn't reacting to a number that's about to change anyway.

- sensor:
    - name: "Outdoor Temp Blend"
      unique_id: outdoor_temp_blend
      device_class: temperature
      unit_of_measurement: "°F"
      state_class: measurement
      availability: >-
        {{ state_attr('weather.forecast_12_grimmauld_place', 'temperature') is not none
           and states('sensor.today_forecast_high') | float(none) is not none
           and states('sensor.today_forecast_low') | float(none) is not none }}
      state: >-
        {% set current = state_attr('weather.forecast_12_grimmauld_place', 'temperature') | float %}
        {% set high = states('sensor.today_forecast_high') | float %}
        {% set low = states('sensor.today_forecast_low') | float %}
        {{ ((current + high + low) / 3) | round(1) }}

Thermostat Season

sensor.thermostat_season reads the outdoor blend and labels the day as one of three states:

• cool once blend reaches 68°F, holds until blend drops below 65°F
• heat once blend falls to 55°F, holds until blend rises above 58°F
• heat_cool for everything in between

The mode scripts (thermostat_active_mode, thermostat_sleep_mode, thermostat_away_mode) read this sensor to decide whether the thermostat should run cooling only, heating only, or both with a deadband.

That 3°F gap on each side is on purpose. Without it, a blend hovering right at 68°F would flip the HVAC mode every time the value bounced from 67.9 to 68.1 across forecast updates. The hysteresis means the season has to meaningfully change before the mode does. Once it decides it's summer, it doesn't second-guess itself over one cool morning.

- sensor:
    - name: "Thermostat Season"
      unique_id: thermostat_season
      icon: >-
        {% set s = this.state %}
        {% if s == 'cool' %}mdi:snowflake
        {% elif s == 'heat' %}mdi:fire
        {% else %}mdi:swap-vertical{% endif %}
      availability: >-
        {{ states('sensor.outdoor_temp_blend') | float(none) is not none }}
      state: >-
        {% set blend = states('sensor.outdoor_temp_blend') | float %}
        {% set prev = this.state if this.state in ['heat','cool','heat_cool'] else 'heat_cool' %}
        {% if prev == 'cool' %}
          {# stay in cool until blend drops below 65 #}
          {{ 'heat_cool' if blend < 65 else 'cool' }}
        {% elif prev == 'heat' %}
          {# stay in heat until blend rises above 58 #}
          {{ 'heat_cool' if blend > 58 else 'heat' }}
        {% else %}
          {# in heat_cool, transition based on outer thresholds #}
          {% if blend >= 68 %}cool
          {% elif blend <= 55 %}heat
          {% else %}heat_cool
          {% endif %}
        {% endif %}

Helpers

I built some helpers that allow me to easily set the temperature range. They're just input_number helpers, one pair per mode: day, night and away. The scripts below read them by name, so when I nudge the day time high from 72 to 71 on my dashboard, that's the number the thermostat gets the next time anything runs.

Putting it all together now

Three scripts do the actual work: thermostat_active_mode, thermostat_sleep_mode and thermostat_away_mode. They're deliberately dumb. Each one reads sensor.thermostat_season, picks a branch, and writes to the thermostat. That's the whole job. None of them know a thing about the weather.

Here's the day time one. I trimmed a couple of housekeeping steps off the end (it also flips some booleans and sets the fan mode) to keep the important part visible:

thermostat_active_mode:
  alias: Thermostat active mode
  sequence:
    - choose:
        - conditions:
            - condition: state
              entity_id: sensor.thermostat_season
              state: cool
          sequence:
            - action: climate.set_temperature
              target:
                entity_id: climate.t6_pro_z_wave_programmable_thermostat
              data:
                hvac_mode: cool
                temperature: "{{ states('input_number.thermostat_day_temp_high') | float }}"
        - conditions:
            - condition: state
              entity_id: sensor.thermostat_season
              state: heat
          sequence:
            - action: climate.set_temperature
              target:
                entity_id: climate.t6_pro_z_wave_programmable_thermostat
              data:
                hvac_mode: heat
                temperature: "{{ states('input_number.thermostat_day_temp_low') | float }}"
      default:
        - action: climate.set_temperature
          target:
            entity_id: climate.t6_pro_z_wave_programmable_thermostat
          data:
            hvac_mode: heat_cool
            target_temp_high: "{{ states('input_number.thermostat_day_temp_high') | float }}"
            target_temp_low: "{{ states('input_number.thermostat_day_temp_low') | float }}"
  mode: single

In cool season the script sets hvac_mode: cool and one number, the day time high. That's it. No lower bound anywhere in that call, so nothing can ask for heat. Winter is the same trick backwards, hvac_mode: heat and just the day time low. Only the shoulder season sends both numbers as a deadband, which is what I had before.

Sleep and away are the same shape. They just read their own pair of helpers.

What calls the scripts

Mostly, nothing new. My wake, sleep and away automations already called these three scripts, because that's how the house has worked for a while now. They picked up the season awareness for free. I didn't have to touch a single one of them. So that's cool.

The one thing I did have to add is an automation for when the season itself changes:

- id: thermostat_reevaluate_on_season_change
  alias: Thermostat, re-evaluate on season change
  triggers:
    - trigger: state
      entity_id: sensor.thermostat_season
      to:
        - heat
        - cool
        - heat_cool
  conditions:
    - condition: template
      value_template: >-
        {{ trigger.from_state is not none
           and trigger.from_state.state in ['heat','cool','heat_cool'] }}
  actions:
    - choose:
        - conditions:
            - condition: state
              entity_id: input_boolean.thermostat_away_mode
              state: "on"
          sequence:
            - action: script.thermostat_away_mode
        - conditions:
            - condition: state
              entity_id: input_boolean.thermostat_night_mode
              state: "on"
          sequence:
            - action: script.thermostat_sleep_mode
        - conditions:
            - condition: state
              entity_id: input_boolean.thermostat_day_mode
              state: "on"
          sequence:
            - action: script.thermostat_active_mode
  mode: single

Without it, a season flip in the middle of a Tuesday afternoon would just sit there. Nothing would be calling a script until bedtime. This one re-runs whichever mode is already active so the thermostat catches up.

The condition looks fussier than it needs to be. It's there because the season sensor drops to unavailable for a split second now and then, usually when the weather integration hiccups or Home Assistant restarts. Without the guard, every one of those blips would re-fire the thermostat. I went back through the last couple of weeks of history and it happened 16 times. So, worth having.

Conclusion

So, back to the thing that bugged me. Summer morning, house is sitting at 65, I toggle sleep mode off. The season is cool, so the script sends cool-only at 72 and there's no lower bound for the furnace to chase. The house drifts up to 68 on its own, for free, the way it would have anyway if I'd just left it alone.

I pulled the history to make sure I wasn't fooling myself. Over the last twelve days there were 13 mornings where the house was sitting at exactly 65°F when we got up, and the furnace ran for zero minutes. Under the old setup that's 13 mornings of running heat in the middle of summer.

I should say though, it's August. The heat branch has never actually fired for real. I've read it a dozen times and I think it's right. Ask me again in December.

I'm not an HVAC guy and there's almost certainly a smarter way to do this. What's your approach? Does your thermostat know what time of year it is, or do you fiddle with it twice a year like I used to?

tttldr

This is great!

One of my big disappointments with HA is the lack of well-developed user controls for this type of thing. I'm not a coder, so just a simple trigger like "turn on the driveway lights when I get home" was an achievement.

I would have to spend months learning and deploying any kind of smart features, even though HA has the hardware and controls to do all of it. I basically use it as a remote to control the thermostat, which is pretty lame. It does come in handy when we go on a trip.

Saving this for when I get outdoor sensors integrated with HA. I applaud your efforts here! My smart thermostat is as dumb as a bag of rocks and I need something like this. Thanks for sharing!

I would say this community and the HA forums are a great place to ask and search for code or ways to do things.

Absolutely a great community! There are a lot of scripts, etc. that people offer (like this post). That's one of the best things about HA. For someone who's not very techy, none of that is easy, unfortunately. For me, I know that if I spend the time to learn how to do something, I know I will get plenty of support from the community - I just have to decide whether the improvement is worth the time it will take to learn and implement it. Also, whether it is worth messing up my current setup, since I will almost certainly make some mistakes along the way.

I've always used heat-only, cool-only, and off modes on the thermostat, but I set them manually. Actually, I think it's only a relatively recent firmware update that the thermostat even got dual-mode. In my climate, there's probably not much risk of triggering both heating and cooling on the same day, anyway.

My comfort range is 68-78°F/20-26°C, though, and in I'm generally in heat mode Oct-Mar & cool mode Jun-Sep. The transition months I generally manage by manually opening windows at the appropriate time. It'd be nice to get some window servos, because sometimes it's not cool enough to open the windows until well after I'm asleep. Or I just forget. Window program would definitely need an outdoor humidity condition - don't want to open summer windows, even if the temp is down to 72, when the dewpoint is also 72.

I'll have to look at this more closely, but it sounds like you've addressed some issues I've had in my own house. We have an ecobee, and while I do like it, I'm also frustrated with its limits. For example, I use different sensors in summer versus winter to keep the house relatively even, so I have to change it up each time. I've had the same thing where it kicks on the AC in winter (not often, but it can happen).

I also dislike how difficult it is to change the schedule for just one day. I have a very variable schedule, and reprogramming the thermostat each week would be tedious. And the "away for now" functionality is limited.

I've been considering turning control of the thermostat over to HA. It has been running extremely reliably for some time now, so I feel safe trusting it. There was a long time when that wasn't true. But I guess I could leave the program in the ecobee, so if the HA goes down, it'll just default back to its own program.

This sounds a lot like what I want to have done. my biggest issue has been figuring out which thermostat to buy? Finding a zigbee vs zwave vs wifi model. Do I need to have 4, 5 or 6 wires or something? Do I need to re-run wires in my wall if I have the wrong number available?

Even just having a manual read-out and the ability to remotely manually change settings would be a win. Everything about this dashboard looks cool to me, but even without the smart auto changing of settings, I want this, but just dont want to spend money and buy the wrong thing.

I have my HA with a set of scripts if the HVAC is set to heat or if the HVAC is set to cool, and twice a year I manually trigger the change on my thermostat. (Okay that's a lie, I also turn it off a few months out of the year and open the windows).
I used to have things way more complicated and it would just fail randomly..

The Honeywell ones are nice and simple and have instructions for whichever number of wires you already have. With stickers for easy labeling as your removing the old one. They have a few models for whichever network you prefer.

The different wires can be intimidating, but they're all standard colors. And your dumb thermostat is already wired with everything you need. The smart one mostly just adds a radio.

The wires are basically: power to the thermostat, ground, and a number of different signal wires for "AC on", "furnace on", etc that when the respective wire gets 5v(?) that device turns on.

Thermostats are very simple devices that just regulate when the high voltage devices should turn on. Things do get a bit more complicated if you have a bigger house with multiple HVAC zones and stuff but most people don't have those. And even if you do, that's mostly just more wires to connect that will already be there.

I was under the impression that some smart thermostats need batteries because the "power to the thermostat" wire was designed for super low power devices, or is otherwise not there at all (thus the different number of wires). So "already wired with everything you need" varies from house to house.

I believe it's that older HVAC controls don't have a true ground/neutral, so they can't actually consume power. Thermostat is (used to be) basically just a remote switch, just connecting the signal wire to its various functions, so there's no need for it to have any kind of power. More recent systems have a ground (C wire), so you can draw power between the 24V R wire and the C common/ground. Some systems even put mains voltage on R.

That makes sense. I have no idea if I have a ground. If I don't I assume I need a battery powered thermostat, which I would then need to periodically change batteries on or externally power?

The fact that I don't know what I have, means I dont know what I need, means I need to bring an electrician or someone who knows what is going on, and suddenly the project becomes more work.

I could totally handle the "build a HA dashboard" part of things... it's the physically setting up devices part that gets me every time.

All the thermostats I've looked at - definitely all the "smart" ones, accommodate all manner of existing wiring. If you just have a 'normal' HVAC with a single aircon, single furnace, and fan, or one with heat pump, backup furnace & fan, then any thermostat out there will work. If it has internal logic, it's going to have a place for batteries, but it will also (probably) have the capability to run off furnace power, if you have the right wires. Smart thermostats will report their battery state to homeassistant, or you can just change the battery when you switch it over to heating for winter.

Swapping a thermostat is pretty easy - it's literally 'connect red wire to terminal labeled red.' It's complicated if you care what the red, yellow, blue &c wires actually do, but the install itself is just color matching.

If you have an extremely high efficiency HVAC, or one with multiple heat sources & multiple compressors, then there may be more than the usual 6-ish wires, but even there, it will be an exercise of taking wire from its current, clearly labeled terminal and plugging it into the same labeled terminal on the new thermostat.

If you can stick with the same vendor for a thermostat upgrade, it may make the job very easy. I replaced a Honeywell programmable thermostat with one of their smart thermostats, and I didn't even have to change wires. Both thermostats plugged into the same backing/terminal block. I literally pulled the old one off and pushed the new one on in 10 seconds. No tools.