Heating management blueprints (DEPRECATED)

[francois09 (François TOURDE)]

EDIT: I remove source from this post, because it’s no more accurate. Please check the Github repo instead.

EDIT2: Changed Import links because of errors.

EDIT3: This post is DEPRECATED, new post here

These blueprints are used to manage central heating system. It uses Climate valve, door/windows sensors and T° sensors.

Please don’t be too rude with me , these are my first blueprints, and my first steps using HomeAssistant !

You can find more details on the Github repo, but here is some infos about how it works:

Principle

1. Each room is autonomous, and have helpers for their properties
2. Each room should have a climate valve, and a T° sensor
3. A global blueprint is in charge of collecting rooms needs to decide to start heater/climate
4. A global boolean (winter_mode) is in charge to determine if it’s … winter

How it works

Based on triggers, each room will compute the T° setpoint, and if necessary activate a helper
saying it needs heating.

The rooms are also able to determine if they’re linked to inside, outside, both or none. Depending on link,
room climate valve can be set to off, or whole heating system can be stopped.

Room Link	Action taken
Inside	Nothing special (Valve reset to unlocked and started)
Outside	Valve is closed and stopped
Both	Flag setup for shutdown global heater (Valve reset to unlocked and started)
None	Nothing special (Valve reset to unlocked and started)

Another automation will decide to start or stop the heating system if rooms need it or no.

On non-winter mode, all climate valves will be set to “off” and also “child lock” mode, to preserve battery.

How to setup

1. First, you need to create global and room helpers. RO indicates automation don’t touch value, RW indicates value can be
   set by automations.

Room related helpers:

• Comfort T° (RO) : Climate valve T° range values. This indicates the leaving T°
• Eco T° (RO) : Climate valve T° range values. This indicates the economic T°
• Setpoint T° (RW) : Climate valve T° range values. Automation can decide the value based on Planning
• Manual T° (RW) : Boolean indicating that Setpoint is manually determined. Set when climate valve is manually modified
• Heat (RW) : Boolean indicating that the room need heating
• Debouncer (RW) : Boolean avoiding race conditions on starting/setup climate valve
• Used (RO) : Boolean indicating the room (mostly bedrooms) are subject to automations. If not, T° is always set to Eco
• Planning (RO) : Planification for switching between Confort (on) and Eco (off) T°
• Linked (RW) : List (Inside, Outside, Both, None) indicating how room is connected to the house or the outside

Global helpers

• Winter mode (RO) : Boolean indicating if we are in Winter (or heating season) or not
• Room link timer (RW) : Timer used to avoid reacting too quick on a room link status change
• Always Open (RO) : Binary sensor that can be used in room link decision
• Always Closed (RO) : Binary sensor that can be used in room link decision
• Heating automation pause (RW) : Timer used to avoid boot side effects.

2. Then, you have to create some global automations not covered by these blueprints:

2. You need to instantiate heater_switch_mode.yaml, heater_setpoint_compute.yaml, heater_room_link.yaml and heater_request_compute.yaml for each
   room you want to activate automation.

3. Then heater_one_need.yaml, heater_start_stop.yaml and heater_boot_management.yaml should also be created to globally manage heating system.

Blueprints:

Heater system management global script

This blueprint is the global on/off heating system. It collects every heater requests from rooms, and decide if home heater should be started or not. It also check
for rooms links to determine if heating system should be shutdown.

Heater request compute

This blueprint compute the boolean (switch) helper of the room, based on Climate valve setpoint, and room T°. If heating is requested, it aslo fake the local_temperature_calibration to ensure valve is correctly opened. In my case, T° sensor is far from Climate, and close to my preffered location in the room.

Heater setpoint compute

This blueprint compute the correct setpoint based on the room schedule and the potential manual setting, to determine and send it to the Climate valve.

Heater switch mode

This blueprint take into account a manual change on the Climate valve, or the Auto setting to modify setpoint.

Heater room link management

This blueprint use the doors/windows status to determine if a room is linked to Inside/Outside/Both/None. When linked Outside, it stop and lock climate valve. It also setup a link helper to decide if we have to shutdown heating system or not.

Heater Winter mode management

This blueprint is the winter mode heating management system. It turn off and lock every climate valve to preserve battery during non-heating period.

Heater boot management

This blueprint is in charge to lock switch automation during the HA boot process. I noticed that climate valves are sending some messages, and trigger the switch automation, resulting on a wrong setup of the room.

[Patrick4 (Patrick)]

First question: can you explain what you mean with the links?

[francois09 (François TOURDE)]

Hi @Patrick4 , sorry for my late reply. (and also my really late ping with your pseudo)

By “Link” I mean “How a room is currently connected to”. For example, imagine a bedroom with a door and a window. If door is closed and window opened, then the room is linked (connected) to Outside.

This allow blueprints to decide if the Valve should be turned off, or the whole heating system should be stopped.

I hope it replies to your question.

[Monster_D (Gernot)]

Hi,
thanks for sharing your blueprint / heating management. Why are switching the system only on/off and not use incease/decrease heating demand?

I rather don’t need an on/off for start the heater but an increase of the temp. “thermostat_hc1_selected_room_temperature”.
My idea is to have an heating demand like described on page 10-11 here: https://github.com/tp1de/ioBroker.ems-esp/blob/5fade71fbb3aecc9f8d2d24c33040112aa4cfb9b/doc/ems-esp-es.pdf
The described program is running for the last 2 years quite smoothly - unfortunatelly on io-broker - and if possible shoud be moved to HA.

[francois09 (François TOURDE)]

Hi @Monster_D,

Turning on/off the central heating system instead of selecting a T° is a choice based on … my heating system … It only accept on or off so I don’t have (and don’t need) something else.

Feel free to adapt to your heating system, or better, propose a PR on my scripts to take into account a manageable central heating system.

Hope this help

[AndySymons]

Sound like a great approach

You might like to compare it with Heating X2: Schedule Thermostats with Calendars, which includes the facility to turn off heating if a door or window is open, or if the room is left unoccupied for a while.

Heating X2 features:

• Schedule by calendar: set the temperature of each room with a local calendar and as many heating events as you like
• Multiple thermostats: One or more thermostats per room: multiple thermostats are synchronised together. Works with smart TRVs, any smart thermostat, or Generic Thermostat
• Manual override: a change on the thermostat, dashboard or by voice assistant remains in effect for a defined period (default 2 hours)
• Door or window open: heating turns off heating in the room if any door or window is left open for a defined period (default 3 minutes) – optional list of zero or more closure sensors.
• Occupancy: heating turns off heating if a room is left unoccupied for a defined period (default 1 hour) – optional list of zero or more motion or human presence sensors.
• Warmup period: occupancy is ignored for a defined period at the start of a calendar event (default 2 hours)
• Away mode: set all rooms to a temperature specified per room (default 5C) when there is no one at home
• Background temperature: used when there is no calendar event (default 5C but specified separately from the frost and away temperatures)
• Zone control: can switch one or multiple heating zone valves, or a boiler that needs a heat demand switch, based on heat demand from a group of thermostats
• Notifications: if thermostats do not respond to a new setting, go offline, or come back online
• Robust: Graceful degradation when a thermostat or a sensor is offline
• Battery-efficient: conserves TRV battery life by only transmitting real changes
• Code generator: uses mail merge (!) to automatically generate YAML code for helpers, timers, template sensors, groups, automations, and dashboard cards from a single EXEL spreadsheet that lists zones, rooms and thermostats

[francois09 (François TOURDE)]

Hi @AndySymons,

Thanks for your link and for your remarks (and ads description of your bluerints ).

My blueprints already includes openings, taking care of outside vs inside openings, and shutoff one room or the entire heating system depending on the room “link”.

Occupancy is already managed, but only with a manual boolean.

[AndySymons]

Yrs, I was comparing because we had many of the same ideas.

What do you mean by ‘manual boolean’ for occupancy? If you use detectors, they are also boolean, so you should be able to connect them?
Having said that, I have found it difficult in practice to get reliable presence detection — I tried several motion and human presence devices. Has anyone else succeeded?

[francois09 (François TOURDE)]

Yrs, I was comparing because we had many of the same ideas.

What do you mean by ‘manual boolean’ for occupancy?

I use a human actionable indicator, a HA input_boolean. Not related to any sensor. My usage is to leave a room out of management when nobody use it. Mainly for bedrooms, that are only maintained at Eco T°.

[vajdum]

@francois09

Heater system management global script

Heater request compute

Heater Winter mode management

Heater boot management

This links do not work

[francois09 (François TOURDE)]

Thanks @vajdum

Fixed with new links, I hope it will work now

[vajdum]

I try to set up this thing, but its not so straight forward. So i may give you an outsider point of view. Maybe you could change text / adapt naming to actual names for users to better understand what to do?

There are a lot of helpers and blueprints needed and i think more consistent naming would be helpful.
F.e.

@francois09

You need to instantiate heater_switch_mode.yaml, heater_setpoint_compute.yaml, heater_room_link.yaml and heater_request_compute.yaml for each
room you want to activate automation.

and then

Heater system management global script

import Blueprint

so i need to look at github files to find out heater_switch_mode.yaml is a blueprint and its named Room heating mode switching.
Maybe remove the first quoted part if we simply can use the blueprint buttons?

I have imported all the Blueprints, but there is no “Heater system management global script” in my blueprint list. So i need to look at the git file - ok, i have to look for “Heating system should start”.

I would propose to

• use always the same naming
• use always the same sequence 1. 2. 3. …
• maybe remove unneeded Texts in first post or link to an install text
• put heating and lighting on different pages in git.
• add some explanation in the blueprints for selecting entities (like in this BP i currently use: 🔥 Advanced Heating Control)
• add which blueprints are needed and which ones are optional (room link?)
  I think my setting is similar to yours and i hope i can optimize my heating, so i really want to try it - i am able to find out which is which:-)

Heating system should start

(switch heating on if needed)

• Request heater switch - which one of the new helper should i use? A global one? all of the single rooms? - ok, i can add more then one so all “Request heater switches” from my rooms? is this correct?
• Heater switch - my boiler switch
• Room link status - i think same as Request heater switch
  I think its not very attractive to users if they have to use a lot of helpers and blueprints and are not sure what to do.

Heater request compute

• My EQ3 TRVs have an offset i can set, but no internal thermometer.

Heater setpoint compute

• can i switch between several heating plans?

Heater room link management

*In-/outside aperture?? opening? Not used now, i set room link dropdown to none

Heater Winter mode management

• yaml called start stop, title Heating system operationnal or not
• Request evaluate automation - name it Request compute like above?

Ok, now i deactivate it to not switch of my boiler, i have to the add the other rooms first - tomorrow.

[francois09 (François TOURDE)]

Hi @vajdum , thank you for your feedback Always interesting to have this kind of feedback

First of all, don’t hesitate to place a PR (or more) or an issue on github, for proposed changes !

I try to set up this thing, but its not so straight forward.

Agree

i think more consistent naming would be helpful.

You mean replace heater_switch_mode.yaml by Room heating mode switching for example ?

Heater system management global script is not a blueprint name, but the description of the blueprint importable by the button below this title. But you’re right, it’s not clear .

About your proposals:

• use always the same naming
  I agree ! Please post an issue about this point.
• use always the same sequence 1. 2. 3.
  I don’t get it, could you be more explicit ?
• maybe remove unneeded Texts in first post or link to an install text
  I will use github README.md as first post text, easier for me, so please propose PR on the README file and I will check.
• put heating and lighting on different pages in git
  For now, I use this repo this way because it’s automatically installed/refreshed on my HA install (using GH integration on HA) with automatic reload. But yes I can split it into multiple repo. Please could you open an issue ?
• add some explanation in the blueprints for selecting entities
  I don’t really understand. You mean description: entry in input: selections ?
• add which blueprints are needed and which ones are optional (room link?)
  For me, all are needed ! Room links are essential to shut off one valve or the entire system.

Ok, I’ll reply to other remarks/question in another post, it’s a bit late here and I’ll go to bed right now

Thank you again for your post and your remarks !

[vajdum]

@francois09

use always the same sequence 1. 2. 3.
I don’t get it, could you be more explicit ?

you have a list of needed yaml in what to do + a list of Blueprint imports:

You need to instantiate heater_switch_mode.yaml, heater_setpoint_compute.yaml, heater_room_link.yaml and heater_request_compute.yaml for each
room you want to activate automation.

Blueprints:

Heater system management global script, Heater request compute, Heater setpoint compute, Heater switch mode, Heater room link management

@francois09

I don’t really understand. You mean description: entry in input: selections ?

yes, like this:

regarding optional, i have only one window sensor and no door sensors at all. So i created the helper, set it to none and i think i can go without room link blueprint.

[vajdum]

Heater boot management - what is needed for “Switching manual/auto/setpoint automation”???

[francois09 (François TOURDE)]

Heater boot management - what is needed for “Switching manual/auto/setpoint automation”???

During boot process, I don’t know why, but some MQTT messages are received, as if the valve was manually updated (T°, auto mode, …), so I deactivate the “Switching” automation for some minuts, as explained in my original post:

This blueprint is in charge to lock switch automation during the HA boot process. I noticed that climate valves are sending some messages, and trigger the switch automation, resulting on a wrong setup of the room.

[vajdum]

the “Room heating mode switching” ones?

[francois09 (François TOURDE)]

Yes, because this automation is in charge to take care of manual actions done on the TRV. If you change the setpoint T° on a valve, it switch to manual. If you set the TRV to automatic (mine is a TuYa TV02-Zigbee control via MQTT | Zigbee2MQTT able to send when you press the knob), then the automatic mode is selected on HA.

Process is not (yet) described in the blueprint README

[vajdum]

I use this TRVs: GitHub - dbuezas/eq3btsmart
I am not sure about the function -

Manual T° (RW) : Boolean indicating that Setpoint is manually determined. Set when climate valve is manually modified
So i change the TRV temp. to heat a room outside of the schedule?
It get not set back automatically?

What happens if temperature is reached, but TRV is still heating?

Does it only switch off if all TRVs are at 0%?

[francois09 (François TOURDE)]

It get not set back automatically?

No, once in manual mode, the system will stay in manual until you modify it on HA or with the TRV knob in my case

What happens if temperature is reached, but TRV is still heating?
Does it only switch off if all TRVs are at 0%?

When the T° is reached on all rooms, then heating system will stop. If the T° is reached in a room, the TRV will close, no more heating in this room.