The Look of the blueprint, to overload in first look in my oppinion.
Check Cover Control or advanced heating
1 Like
Indeed the deletion of empty lines helps - ignore my issue 
1 Like
It is a large blueprint (over 1000 lines now) and precisely for that reason I have laid it out to be easily legible (for me). Of course you can delete blank lines and comments if you wish, but I do not see how that is an improvement? 
What I have done in an effort to improve comprehensibility is add an overview in the comments at the start of the file:
### OVERVIEW
### The main action steps are as follows.
### The numbering correspnds to that used by the system log for error messages.
### ACTION[0] -- LOG THE TRIGGER. Starts a new log file entry by writing a bank line and the trigger id
### ACTIONS[1-3] -- FETCH THE CURRENT AND NEXT CALENDAR EVENTS
### Calls calendar.get_events twice, then sets local variables for later use
### ACTION[4] -- RESPOND TO TRIGGERS WHERE NECESSARY. A big choose statement on the trigger_id.
### ACTION[5] -- DETERMINE THE REQUIRED TEMPERATURE ACCORDING TO THE STATE. A big chooose statement on the relevant states variables.
### Decides what teperature is required and why. Sets the 'required temperature' helper and the 'reason test' helper.
### ACTION[6] -- SEND TEMPERATURE CHANGE TO THE THERMOSTATS
### Loops through all the thermostats for the room. If the required temperature is
### different from the actual one, the service call to change it is invoked and the echoblock (response timerout) timer started.
### ACTION[7] -- LOG THE REASON. Writes the last line of the log file entry
You also get a nice picture of how it works if you look at the trace of one of the automations that use it.
Does that help?
… nevertheless, for anyone else who misses this, I have now added code to check whether the max length is set to 255 before attempting to write anything. If it is less than 255, an error messge is written to the ‘setting reason’ instead. 
Minor updates to version 2.2.
None of these affect the basic functionality. Following a period of beta-testing, measures are taken to increase robustness in case of device failures and anomalies, i.e. avoid automation failures and system log errors, improve notifications and logging.
- 01-Mar-2024: 2.2.01. Code added to check that the ‘setting reason’ input_text helper has a max length of 255 characters. Default is 100, which is too short. If not set to 255, an error message is written into the ‘setting reason’.
- 02-Mar-2024: 2.2.02. Added an id to the away_switch_on and _off triggers, now separated, for logging purposes
- 05-Mar-2024: 2.2.03. Added detail to the trigger line of the log entries
- 08-Mar-2024: 2.2.04. Correct trigger line of the log entries when calendar event triggers have no entity_id
- 09-Mar-2024: 2.2.05. Tidied up logic of ACTION[6] using choose, to ensure there is always a log message
- 09-Mar-2024: 2.2.06. Warmup timer reset only if nothing is scheduled (previously sometimes premature with consecutive events)
- 09-Mar-2024: 2.2.07. Improved notifications. Additional unknown and offline every time a setting is needed. Dismissed when online. Only ever one notification per device.
- 09-Mar-2024: 2.2.08. Now ignores false ‘set temperature change’ from a device when it goes unavailable, and other out of range (false) temperature settings
- 13-Mar-2024: 2.2.09. Added ‘continue_on_error’ and ‘parallel’ to thermostat service call, ‘continue_on_error’ to logs and notifications to better cope with device errors
- 14-Mar-2024: 2.2.10 Thermostat available trigger time increased and now resets manual override, because sometimes TRVs go offline for just a few seconds (might be a ZHA glitch?)
1 Like
This is just superb - thank you so much! One suggestion to make it even better - how about introducing a dynamic warmup time per zone, like some systems such as Honeywell Evohome do? @tommypearse looks to have done a lot of hard work in that department here: Optimum Start for Heating Systems, or alternatively something that uses statistics from logs of previous heat up times as a guide, maybe even something that’s influenced by the weather too?
1 Like
Sounds like a great idea. I do not know the Honeywell system, but I guess you mean you want to set the time the room needs to be warm and have the system calculate an earlier time to actually turn it on?
At the moment, my warmup time starts at the calendar start time and all it does is to tell the automation to ignore the fact that the room is unoccupied.
Yes that’s exactly right - I think it has calculations based on how long it’s taken over previous days to heat a room up and uses it to work out when it needs to begin heating to get to the desired target temperature at the specified time. It could even be used in conjunction with the method I linked above to work out the expected heat loss for a room (as an option only for people who want to go to the effort of punching in all the relevant data for each room!)
Weather compensation is also worth considering too - so based on either the weather forecast or an outdoor temperature sensor, increase or decrease the warmup time accordingly.
I imagine it’s a pretty complex thing to work out though, and is probably something that would require a lot of testing and tweaking!
Mmm. So it is a substantial change. I think the way I would approach it is
- set up [room]_warmup_time as an input_time variable for each room (instead of a constant, as now)
- using whatever algorithm you have – based on past data perhaps with outside temperature and weather forecast – give it a value every day in a separate automation
- modify the calendar event start trigger in the blueprint with a negative offset so that it starts at the calendar time minus the [room]_warmup_time.
- start the [room]_warmup_timer (to ignore presence) using [room]_warmup_time as its start value.
If you want to show off, you could do the converse with a ‘cool down’ time that turns the heating off a little before you plan to vacate the room.
Do let me know if you get it working!
If this blueprint was of use to you. please buy me a coffee!
Hi @AndySymons. I’ve been using Schedy Schedule via AppDaemon to control my 3-zone heating and hot water system for a few years. It’s been working well, but I’ve been on the lookout for a more graphical way of scheduling my heating and came across your projects. They look great & I’ve followed your installation guides, however I’m getting an error when I run a test Y2 schedule saying that my automation “has an action that calls an unknown service: script.heating_xyz_logfile_entry”.
I have a scripts.yaml file and have also included script: !include scripts.yaml in my main configuration.yaml.
One thing that I have noticed is that the logfile_entry_script-yaml on your github calls for a script logfile_entry:, whereas the Y2 automation calls for service: script.heating_xyz_logfile_entry.
I tried renaming the script from logfile_entry to heating_xyz_logfile_entry but I still get the same error.
Any suggestions what I’m doing wrong? Cheers, Craig
Sorry, that is my fault. I changed the script name yesterday from heating_xyz_logfile_entry to just logfile_entry because it has more general use than just heating, but I neglected to immediately retrofit it to Heating X, Calendar Y and Zone Z. I have now done so, and did a brief regression test with no problems.
You can now re-install from the gists, or alternatively make your own global replace of script.heating_xyz_logfile_entry to script.logfile_entry. I did not have a chance to re-run the entire installation, so let me know if you encounter any problems.
Thanks Andy, that seems to be working fine now. I’d also made another schoolboy error and had just copied the sample script file across into my scripts.yaml, but (because it’s not in the main configuration.yaml file, but is referenced by script: !include scripts.yaml) I’d forgotten to remove the script: text at the beginning of the script! Hence HA hadn’t been able to find the script as the syntax was wrong…
I’ll continue testing for now before I move my heating controls across (luckily it’s summer, so no rush!!), but it’s looking great - thank you.
1 Like
The method I use (which is why it has ‘script:’ at the start) is to install it as a package. (Did I not put this in the installation instructions?) I find that method easier to manage, though your method is also correct.
- Create the folder
/config/packages - Create a file
/config/packages/logfile_entry.yaml - In your
configuration.yamlfile, include the lines
homeassistant:
packages: !include_dir_named packages
Then reload.
I presume you found my code generator?
I agree fully with plenty of testing before you commit. I created a test dashboard with cards that expose all the helpers, so you get a good idea of what is going on. Remember you can also disable each automation or use the ‘Away’ switch to stop the automations doing anything.
In my last installation, the biggest problem was building a strong enough Zigbee network to keep the TRVs online. That is why I have so much checking, notifications and logging (which I recommend you use). I recommend that you have a Zigbee repeater (any mains powered Zigbee device or an IKEA Tradfri repeater) in every room.
You may find my unavailable devices sensor useful.
I found it useful to create a card with all the ‘identity’ attributes of the Zigbee repeaters. That gives you a quick overview of which ones are not working (they are greyed out).
And I use the Low Battery list by Smart Home Junkie.
Thanks Andy.
I’d been using the downloaded pdf file as the installation guide, which mentions mentions script: !include scripts.yaml, but the use of packages makes total sense (it’s quite possible that I’ve missed this if it’s written elsewhere!). I used the code generator, which was very helpful (& saves a lot of time!).
I’ve got a reasonably straightforward heating system in that it’s an Air Source Heat Pump (so it’s more efficient to minimise temperature changes) with 3 zones and a further switch to demand hot water. My temperature sensors for the generic-thermostats are all hard-wired ESPHome sensors so that I don’t have to worry about battery issues or zigbee problems. I’ve got numerous zigbee temperature sensors, but they don’t influence the heating controls (I’ll checkout the Low Battery list though as that sounds useful). I usually only change the house temperature by a couple of degrees between day & night setting (or if we’re away for several hours) & then use the “away” setting for longer periods away.
I’ll come onto this after a bit more testing, but at the moment I use a dropdown box to choose various heating presets (for example to set different heating profiles for a zone dependant on who is in the house rather than just using one profile and the “away” mode). Have you done similar? One thought that I’d had is that I could setup different calendars & then use a new automation to change which calendar your automations use?
Note to self: need to update that guide
1 Like
No I haven’t but it sounds interesting.
My system is essentially calendar-based; you have a different calendar for each room already so can do a lot with that. The ‘Away’ function overrides the calendar. You can have more than one ‘away’ switch; each automation selects one to use, so you could group rooms into zones that way.
The calendar selection it a blueprint parameter, so to switch it you would need to change to a helper that points to a calendar – not a well supported function (see how for log notifications I had to use a text field).
When you say 'depending who is in the house" …
a) do you use an automatic way of detecting that?
b) do you mean that different people like different temperatures, or that they occupy different rooms?
Remember that I also have the ‘manual override’ feature; this kicks in if you change the temperature by any means outside the automation: on the dashboard, physically on the TRV, using a voice assistant, or indeed by another automation. You can change how long the manual override takes effect (default 2 hours).
OK, thanks. One to investigate when I have some more time !
My son has some complex disabilities, so I tend to keep certain areas of the house warmer when he’s staying with me. It’s not automatic (at the moment!), so I just change the selection in a dropdown box within a HA dashboard.
I do use a manual override with ShedyScheduler,but I normally need to change the temparatures for much longer periods of time.
1 Like
There are several options
- With Heating H2 you can manually override the calendar set temperature. The manual setting remains valid for a time set as an automation parameter; you could set that to 24 hours.
- You can set up the calendar for the ‘normal’ scenario (not there) and change them or write in additional events when he is present.
- You could up two automations for the same room - one for when he is there and one for when he isn’t, each with its own calendar. You can then switch between the automations by enabling and disabling them – which you could do from another automaton if you have an algorithm to do that.
- I don’t support it (yet) but someone took a fork of Heating X2 and modified it so that multiple temperatures can be specified in one calendar by prefixing each with a specific character. In your case you could specify different temperatures for when he is there and when he isn’t, and add an input switch “he’s here” to the blueprint to decide which of the two temperatures to adopt.
Heating X2 has now been consolidated with related components of my Home Assistant smart heating system into the new topic Project HEATHER.
This topic is therefore closed; please make further comment in the new topic.