Heating X offers comprehensive control of one or more heater or radiator thermostats in a zone using a calendar. Features include manual override, plus optional door/window opening sensors and/or occupancy sensors.
Note: the word ‘Zone’ is used here in the plumbing sense – typically a room, or a Home Assistant ‘area’, but can also be a single heater, such as a hot water cylinder, for which no door, window or occupancy sensors would be specified. It is unrelated to map zones. Invoke the Blueprint once for each zone in your home.
-
Thermostat(s): One automation typically controls one thermostat from a calendar, but you can specify more than one if, for example, you have two radiators in the same room. If you specify more than one thermostat for a zone, they will share the same calendar and the same door/window and occupancy sensors if applicable; a manual override on one is synchronised to the others.
-
Calendar: Sets heating temperature according to your specification in events in a calendar for each zone.
-
Manual override: Following a manual change – on one of the thermostat devices itself, on the dashboard, or by your voice assistant – that temperature is adopted for a defined period on all the thermostats in the same zone. After the defined period, the temperature setting reverts to the schedule.
-
Door or window open sensors (optional): one or more door or window open sensors can be specified; then, if any of those doors or windows is left open for a defined period the heating is turned off. When all doors and windows are closed, the temperature reverts to the previous manual or scheduled setting.
-
Room occupancy sensors (optional): one or more room occupancy sensors can be specified; then, if the room is unoccupied for a defined period, the heating is turned off. When the room is occupied again, the temperature reverts to the previous manual or scheduled setting.
The following description, the Blueprint defaults, and the temperature icons assume that you are using Celsius as the temperature scale, but they could easily be adapted to Fahrenheit.
It is assumed that Heating X is used for heating, but it could be readily adapted for cooling.
… Or use this link for import in HA https://gist.github.com/AndySymons/911ac751480ca62ce2a562e62b59f3ac
INSTRUCTIONS
1. Install the physical devices
- Thermostats. Thermostats can be physical devices such as radiator thermostats, or a
Generic Thermostatthat links a temperature sensor and a switch – anything with domain ‘climate’. - Door or window opening sensors (optional). Install contact sensors or similar as required. They should have device class ‘opening’. If you have none, the Heating X automations will act as if all doors and windows are always closed.
- Occupancy sensors (optional). Install a PIR motion sensor, mm Wave human presence sensors or similar as required. They should have device class ‘occupancy’. If you have none, Heating X automations will act as if the zone is always occupied.
2. Set up the calendars
- For each zone, create a calendar using the Home Assistant Local Calendar integration (you need Home Assistant 2022.12.1 or later).
- Add events to the calendars for each period that you want to specify the temperature. In the summary field put the name you want to appear on the dashboard – e.g., “Daytime setting”, “Night setting”, “Evening boost”. Set the events to repeat daily or on specific days of the week as required.
- Add the required temperature anywhere in the description field between two hashes: e.g., “Set temperature to #21.5# C”. Do not use another hash before the one that introduces the temperature, or write anything else between the hashes
- Events will be treated as consecutive if a new one starts within 2 minutes after the previous one ended. Otherwise, in the gap between events the heating is turned off.
3 (a). Create Template Sensors and Helpers using the Code Generator
The blueprint requires a number of template sensors helpers and helpers. You can created these by hand, but the simplest method is to use my Cone Generator
AndySymons / Heating-X-code-generator
The Code Generator uses Microsoft Mail Merge, so you will need a system running Microsoft Office (sorry, I could not find a free app for this).
It generates all the YAML code you need to define the template sensors and helpers required by the Blueprints for any size of installation. You simply list your zones and radiators in an EXCEL spreadsheet, then use WORD files with Mail Merge toı create the YAML. Full instructions are included in the ZIP file.
3 (b). Create Template Sensors and Helpers by hand
If you cannot or do not want to use the Code Generator, you can create the following template sensors and helpers by hand for each automation (heating zone) that you are going to create with the blueprint.
- Thermostat set temperatures – for each of the thermostats. Here is an example template
### radiator X set temperature
- sensor:
- name: Radiator X set temperature
unique_id: "5f2be1c9-79a0-410f-b33d-139bbc7f9623"
unit_of_measurement: 'C'
icon: mdi:thermometer
state: "{{ state_attr('climate.radiator_x_thermostat', 'temperature') }}"
Create the following helpers for each zone:
- input_text helpers:
- Event name – to hold the name (aka Summary) of the current event
- Event description – to hold the description of the current event
- Setting reason – into which the automation writes the reason for the current setting (for use
- input_datetime helpers
- Event start – to hold the start date and time of the current event
- Event end – to hold the end date and time of the current event
- input_number helpers
- Event temperature – to hold the temperature specified in the current event
- Manual temperature – to hold the temperature specified by manual control
- Timer helpers
- Warmup timer – to hold the timer for the event warmup period
- Manual override timer – to hold the timer for a manual intervention
- Door or window open timer – to hold the time until the heating will be turned off following a door or window opening (is paused when they are all closed)
- Room unoccupancy timer – to count down the time until the heating will be turned off following the room becoming unoccupied (is paused when it is occupied)
- Echoblock timer – for use inside the automation to distinguish genuine manual changes of the set temperature from those set by the automation
4. Create automations by invoking the Blueprint
Use the Heating X Blueprint to create an automation for each zone.
-
The Blueprint inputs.
- Calendar: Identify the calendar for this zone that you set up in step 2.
- Thermostats – identify the thermostat entity or entities in the current zone.
- Thermostat set temperature sensors – for each of the thermostats you just specified
- Door or window opening sensors (optional)
- Occupancy sensors (optional)
-
Now identify each of the helpers for this thermostat automation, created in step 4:
- Event name (aka Summary)
- Event start
- Event end
- Event description
- Setting reason
- Event temperature
- Manual temperature
- Warmup timer
- Manual override timer
- Door or window open timer
- Room unoccupancy timer
- Echoblock timer
-
Finally, you have the opportunity to modify a number of constant parameters used by the automation. They all have defaults so you might want to skip this step at first and come back later to tune the automation.
- Frost setting – the temperature to be used when the heating is turned off. Default 5. Must not be lower than the minimum accepted by the thermostat(s).
- Minimum thermostat temperature – the minimum temperature that your thermostat can be set to (default 5C)
- Maximum thermostat temperature – the maximum temperature that your thermostat can be set to (default 95C)
- Door or window open delay time – the time for which a door or window can be open before the heating switches off. Default 3 minutes.
- Room unoccupancy delay time – the time for which the zone can be unoccupied before the heating switches off, except during a warm-up period. Default 1 hour.
- Warmup period – the period of time from the start of a new event for which room unoccupancy will be ignored. Default 2 hours.
- Manual override period – the time period for which a manual intervention will override the schedule. Default 2 hours.
- Repeat step 6 for each of your zones. If you change your mind about how to group devices to an zone, go back to step 4.
5. Design your dashboard
For testing, you might like to display a thermostat card and many or all of the helpers in an entities card, all grouped in a vertical stack.
For an end-user it suffices to see a thermostat card and a field that says what event is active (if any) and the reason for the current setting. My suggested design has a card for each zone that displays a half-sized thermostat card for each thermostat in the zone, followed by a half-sized Markdown card with the name (summary field) of the current event and the reason the thermostats have their current setting.
I use the custom “Better Thermostat” card, so if you want to try my card design, you need to install that first from HACS, or change the code to use a standard thermostat card.
- On your dashboard, select ‘Edit dashboard’ and add a card. Select the ‘Manual’ card.
- Delete any YAML that is already there, then copy and paste the code below.
type: vertical-stack
cards:
- type: custom:mushroom-title-card
title: Heating X
- square: false
columns: 2
type: grid
cards:
- type: custom:better-thermostat-ui-card
entity: climate.radiator_x_thermostat
eco_temperature: 5
disable_window: true
disable_summer: true
disable_eco: true
disable_heat: true
disable_off: true
set_current_as_main: false
- type: markdown
content: |-
**Schedule**: {{states('input_text.radiator_x_event_name')}}
**Status**: *{{states('input_text.radiator_x_setting_reason')}}*
- Change the entity names ‘radiator_x’ to yours
- Save the card.
- Repeat step 5 for each zone in your home.
You’re done!
I have 40 years in IT but am new to HA and YAML … so feel free to criticise.