Use a weekly schedule to select the target temperature

A Home Assistant heating schedule needs two parts: a weekly timetable and an automation that sends the right temperature to your thermostat. The built-in Schedule helper supplies the timetable. The example below adds the automation, a pause switch, and a check that applies the current target after Home Assistant starts.

First confirm that you can change the thermostat’s temperature from Home Assistant. Then create the schedule and pause control, add the example, and test one short time block. You do not need a custom scheduling integration for this two-temperature version. A helper is simply a saved setting inside Home Assistant.

This guide is for one existing thermostat with a single target temperature in Heat mode. An entity is its named control in Home Assistant, such as climate.living_room. A radiator valve that changes one room’s temperature does not, by itself, establish a complete boiler-control system. Keep that system’s existing controls in charge of producing heat.

Researched from current Home Assistant documentation on September 15, 2026. The weekly plan is an illustrative configuration, not a heating-efficiency recommendation. YAML syntax and example logic were checked locally; this automation was not run in Home Assistant or tested on physical heating equipment. The cover is an AI-generated residential illustration.

1. Decide where the timetable should run

Use the smallest setup that gives the household the control it needs.

On a phone, scroll the table sideways to see every column.

Your situationStart hereWhat to check
The thermostat’s existing weekly plan is enough.Keep that plan; use Home Assistant for viewing or carefully chosen adjustments.Confirm where the plan is stored and how a manual change returns to it.
You want to edit two temperature periods in Home Assistant.Use the built-in helper and automation below.Confirm single-target Heat mode works, and prevent another comfort schedule from competing.
You need heating/cooling ranges, coordinated zones, or equipment-specific optimization.Keep the existing controller while you choose a design for that system.This example does not coordinate pumps, boiler demand, cooling or multiple zones.

For outage planning, see which thermostat functions survive an internet outage. For a thermostat you have not bought yet, use the separate Home Assistant thermostat buying guide.

Keep equipment protections intact. This is a software schedule for an already installed thermostat. Do not bypass frost protection, temperature limits, compressor protections or wiring controls. Have an installer confirm suitable temperatures and schedule behavior for a heat pump, underfloor system or unfamiliar heating installation. The two example numbers below are not universal recommendations.

2. Confirm the thermostat control and units

  1. Open the thermostat in Home Assistant. Confirm its target-temperature control works and note its full climate. entity ID from the entity settings.
  2. Check whether the temperature shown uses Celsius or Fahrenheit. The code below uses 20 and 18 for a Celsius installation. Replace both numbers with appropriate values in your installation’s units before enabling it. For a Fahrenheit demonstration, 68 and 64 are roughly comparable.
  3. Confirm that the thermostat supports the mode named heat. The example deliberately waits for that mode. If your integration only offers Auto or a heating/cooling range, use a configuration designed for it.
  4. Record the current thermostat schedule and manual-hold behavior before changing them. If you proceed with this Home Assistant timetable, use the manufacturer’s supported manual/hold setting to prevent another timetable from overwriting it. Keep a way to restore the original arrangement.

In Home Assistant, Heat describes the selected operating mode. It does not mean the furnace or radiator is heating continuously; current activity is reported separately when supported. The temperature action can change a single target without changing the mode. Heating/cooling ranges use different fields.

3. Draw the comfort hours and add a pause switch

Go to Settings → Devices & services → Helpers → Create helper → Schedule. Name it “Living room comfort.” Draw and edit these example blocks:

  • Monday–Friday: 06:30–08:30 and 17:00–22:00.
  • Saturday–Sunday: 08:00–22:30.

Inside a block, the helper is on; outside it, the helper is off. Here, off means use the lower target, not turn the heating off. A 06:30 block requests the comfort target at 06:30; it does not predict when the room will reach that temperature.

Create a second helper, this time choosing Toggle. Name it “Living room schedule enabled” and leave it off during setup. A Toggle helper gives you a visible on/off switch and normally restores its previous state after restart.

Check both helper IDs in their settings. The example expects schedule.living_room_comfort and input_boolean.living_room_schedule_enabled. Your installation may add a suffix; replace every occurrence in the code if yours differs.

Put the pause switch where the household can find it. On a dashboard you already edit, select the edit button, add an Entities card, and include the schedule-enabled toggle. Give the card a clear title such as “Heating schedule.” Keep your thermostat control nearby.

4. Add the automation

Open Settings → Automations & scenes → Create automation → Create new automation. In the editor’s menu, choose Edit in YAML and replace the new automation’s contents with the example. YAML is the text format for the same automation. The long code block scrolls sideways on a phone. Replace the three entity IDs and both temperatures before saving.

The checks at the start of the action list require scheduling to be enabled, a known schedule state, and a thermostat already in Heat mode. An action-list condition stops the remaining steps if it fails.

alias: Living room weekly heating target
description: Apply the current weekly target when scheduling is enabled.
triggers:
  - trigger: state
    entity_id: schedule.living_room_comfort
    to:
      - "on"
      - "off"
  - trigger: state
    entity_id: input_boolean.living_room_schedule_enabled
    to: "on"
  - trigger: state
    entity_id: climate.living_room
    to: "heat"
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - condition: state
    entity_id: input_boolean.living_room_schedule_enabled
    state: "on"
  - condition: template
    value_template: >-
      {{ states('schedule.living_room_comfort') in ['on', 'off'] }}
  - condition: state
    entity_id: climate.living_room
    state: "heat"
  - action: climate.set_temperature
    target:
      entity_id: climate.living_room
    data:
      temperature: >-
        {{ 20 if is_state('schedule.living_room_comfort', 'on') else 18 }}
mode: restart

Turn “Living room schedule enabled” on when you are ready to apply the current target. The automation also checks again at schedule changes, Home Assistant startup, and when the thermostat enters Heat mode. It reads the timetable’s current state, so it does not replay every missed transition after downtime.

The state triggers use specific destination states. Changing the thermostat’s target alone does not trigger this automation again. To keep a manual change through the next schedule boundary or restart, turn the schedule toggle off first. The startup check uses the documented Home Assistant start trigger.

What this version leaves to you: it does not retry a failed temperature command on a timer. If a device reports Heat mode but rejects a command, inspect the trace and connection, then switch the schedule toggle off and on after fixing it. After reloading automations, use that same toggle to apply the current plan immediately.

5. Check the worked example before leaving it running

With the example week and Celsius values above, these are the intended outcomes. They describe the code’s decisions, not measured heating performance.

On a phone, scroll sideways to read the expected result.

SituationExpected resultWhy it matters
Monday 06:30; scheduling enabled; thermostat in Heat.Request 20°C.The morning block has started.
Monday 08:30; same settings.Request 18°C.The block has ended; the lower target still permits heating.
At 07:00, turn scheduling off, then manually select 21°C. The 08:30 boundary arrives.This automation sends nothing; the 21°C request is left alone.The pause lasts until you turn the toggle back on. Other controllers may still act.
Turn scheduling back on at noon.Request 18°C immediately.Resume uses the current period; it does not wait until 17:00.
Home Assistant was down at 17:00 and starts at 18:10; helpers are ready and thermostat is in Heat.Request 20°C.Startup catches the current evening block.
Thermostat is Off, Cool, Auto, unknown or unavailable.Send nothing.The automation must not force the system into heating. Returning to Heat triggers a fresh check.
The schedule helper is unknown or unavailable.Send nothing.Missing schedule data is not treated as an instruction to lower the temperature.
  1. Test a short block while you are home. Pick appropriate temperatures and move one block to start a few minutes from now. Watch the target at its start and end, then restore the real times.
  2. Test the pause. Switch scheduling off, change the target manually, and let a boundary pass. Switch scheduling on again and confirm the current period is applied.
  3. Check a routine Home Assistant restart. Keep the thermostat and heating equipment powered. Confirm the current target is reapplied after startup, and that a paused schedule stays paused.
  4. Read the automation’s Traces. A trace shows which step ran or stopped. Verify the thermostat’s displayed target too; a completed software action alone is not proof the room is warming.

The editor’s Run actions button skips triggers and top-level conditions. Here, the checks are inside the action sequence, so they still protect a whole-sequence test. A manual run still does not test the clock boundaries.

When the schedule does something unexpected

  • The helper changes but the target does not: check that the toggle is on, the entity IDs match, and the thermostat’s state is exactly heat. Read the trace for a failed check or command.
  • The target changes back later: look for a thermostat timetable, vendor-app hold expiry, or another Home Assistant automation. Use one timetable for routine temperature changes.
  • A manual change is overwritten: turn the schedule toggle off first. With it on, the next block boundary, startup or return to Heat can reapply the plan. See how to design manual overrides for an automatic timed pause.
  • The room is cold when a block begins: a target request is not a warm-up prediction. Adjust the schedule with your system’s response in mind; get equipment-specific advice before adopting much lower overnight targets.

Frequently asked questions

Does creating a Schedule helper control the thermostat?

No. It supplies an on/off timetable. An automation must turn that state into a temperature command, as in the example above.

Can I use three or more temperatures?

Yes, but this two-temperature example ignores per-block additional data. An expanded design can read a target stored in each block. Touching blocks stay on, so that design must also react to the target attribute changing. An attribute is extra information stored alongside an entity’s main state. Do not just add a third block temperature and expect this code to use it.

Will this work without internet?

The timetable and automation run in Home Assistant. Sending the target without internet also requires a local connection to the thermostat. A cloud-connected integration may still need the vendor’s service. While Home Assistant itself is down, this automation cannot send changes; the thermostat follows its own device-specific behavior.

Does pausing the schedule turn the heating off?

No. It stops this automation from sending new targets. Set the temperature you want using the normal thermostat control, and turn scheduling back on when you want the weekly plan to resume.

For help bringing comfort routines and household controls into one plan, see Tara’s configured Home Assistant setup.