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.
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 
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.
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.