[SmartHRT] Smart Heating Recovery Time - (Cool Sleep, Warm Wake-Up!)

Hi :call_me_hand: ! Here is a full pack of script that works quite well for several weeks for me, and that could be called Cool Sleep, Warm Wake-Up!

Anyway, most of the project description, and all source is on github (only missing is the documentation for equations and the advanced mode):

The thermal mass of my radiators and walls provides good thermal comfort but makes it hard to predict the heating recovery time in the morning. Without predicting the correct time to start heating at night, it is either too late (and too cold) or too soon (heating the living room unnecessarily while sleeping).

The principle is simple: while sleeping, heating can be completely turned off and boosted at the correct recovery time.

Alt Text

The challenge is to identify the recovery time, neither too soon (to avoid wasting money, emitting CO2, and using excess kWh), nor too late (to obtain thermal comfort). This problem involves:

  • 2 variables: interior & exterior temperatures (Tint & Text)
  • 1 objective: set point temperature Tsp at wake up time target_hour

Preview

This is an ongoing development…

So… any advice and support is more than welcome :pray:

  • this is a basic package, I’m not sure where to go now for better usuability, any advice from all experts here? I’m not familiar with blueprints, hacs module, native modules, … Let me know if this package is really wrong and what are the best options (though I’m not trying to sell anything, and I always prefer simplicity!)
  • it works perfectly well for me every days, though there are certainly possible bugs…
  • i’ve seen various similar requests or developments (e.g. Thermostat recovery mode (or when to start heating to reach the set point)), though none of these were satisfactory → to many simplistic and linear correlations, without real physics nor learning process… give me links if you know similar alternative that I could have missed ! I’m always interested, even if i had fun at developing mine and trying to get the simplest system (way too much parameters from what I’ve seen in some advanced dashboards :smiley: )

EDIT Feb 5 update

NEW option: additional wakeup automation template (see wakeUp_automation_for_smartphone_alarm_sync.txt) to automatically sync the target time with the smartphone alarm (no more need to set target time manually)
NEW: time lag monitoring after heating systems is turned off for better prediction of temperature's decrease parameter (RCth)
FIXED: no more initial values that overwrite parameters when HA reboots
3 Likes

Looks interesting :slightly_smiling_face:
I use 🔥 Advanced Heating Control with schedulers for heating plans.
Schedulers have an attribute with time of next event.

In my case i think its important to also use the flow temperature for calculation. I dont switch heating off at night, i set it to eco temp. So you dont know if all water is cold or already heated up - which takes longer with more TRVs open of course.
I need it in the evening too to heat kitchen/TV room (the coldest room in house),

1 Like

The flow temperature is similar to the ceramic temperature of my electric radiator, which is a part of the overall thermal mass of the room. If you need this temperature you might need the wall temperature too :sweat_smile:

This is the ambition of the calculation my script is doing, all the thermal mass is taken into account: emitter, furniture, walls,… I don’t have water emitters, but they should have less thermal mass than my ceramic radiators, so I can imagine it’s ok, no?

And of course, if there is no calculation, you cannot anticipate enough the recovery time. This is why the eco mode is used then. I wanted here to not use the eco mode.

I am not sure about the meaning of this. Can i use it to get a warm kitchen or TV room in time or only with no heating inbetween?

I am not sure if its a good idea to let it cool down all night. I read, it needs more energy to heat it up again rather then maintaining it on a lower level. But i dont know if its true. Our flat is not very well insulated.

Both are possible:

  • the simple use is with no heating in-between
  • though it’s still possible with heating in between , but you need first to “train” the model during few cycles in self calibration mode with no heating in-between in order to calibrate the 2 necessary parameters of your room (named RCth and RPth)… And then it will work also with heating in-between because the calculation is updated until the recovery time limit taking into account the real interior temperature (BUT self calibration has to be turned off while using like this).

It’s wrong, if your flat get cooler there will be less thermal loss at the end. There are 2 main reasons to advise to heat in between:

  • as you don’t have the recovery time prediction, you will tend to heat up much sooner than needed to avoid too much discomfort… With a minimum you have faster heat up and less discomfort risk
  • if you have lack of ventilation in occupied rooms, you can get moisture issues… This can be an issue mostly in an occupied rooms. Typically, when I’m not at home this is not at all a problem, and neither in my living room while I sleep in the bedroom (no humidity production).

Same :sweat_smile:

Hi,
this sounds very interesting to me, so let’s give it a try.

Could it be that I need to set some additional values, such as:

sensor.exterior_temperature
sensor.night_state
and how do I change the interior temp sensor?
grafik

I followed your installation guide on GitHub but encountered some issues that suggest to me that certain entities might be missing.

Thanks in advance for your feedback and help!

Hi,

  • the sensor exterior temperature should be found automatically from the default Home Assistant meteo, it worked for me.
  • for interior temperature, you have to write in text box the name of the entity of your own room temperature sensor. E.g. for my living room I’ve written “sensor.salon_temperature” but you have to find the name of your own temperature sensor and to write it here.
  • I forgot to include sensor.night_state (see mini-graph-card git for the definition of this sensor if you want to add it before I update) is only for the graphics, so it is not at all required… I will correct this in the next update (ASAP) though you can use the package without this.

Thanks for pointing out these things and let me know if it’s ok.

Thank you for your input.

Here’s a quick update on my progress so far:

  • The sensor.exterior_temperature is now working and recognized by my system.
  • The interior temperature sensor has been set up successfully.
  • I ran the test calculation and received some output indicating when the heating should start.

As I understand it, the script should automatically recalculate every 20 minutes and at the start of the recovery time.
However, even though the smartheating_mode is set to “on,” the recalculation does not seem to occur every 20 minutes.

This morning, I manually triggered a recalculation, and as a result, the recovery start time was updated.

I will wait till the calculated start time and see what happens … any other advice?

For the recovery start time, there is a cycle of Recalculation (every 20min) that is starting only after Heating OFF - calc time → in my example it will be recalculated at least every 20min from 11PM (when you stop heating and start anticipate heating start time) and the calculated recovery start time, i.e. let’s say 3am (though this recovery start time of 3am can evolve each 20min).

So this sounds normal that this morning the recovery time does not update every 20min, still you can test (when running the script) and estimate a start hour, but this should be done after the heating is turned off at night.

Maybe some terms could be more explicit? Let me know if you have any suggestion to give better (but not too long) descriptions of the variables.

It might be better in a first approach to keep values of calculated constants (RCth and RPth) from typical nights in the week. Indeed, these values can vary more or less for longer cycles (after week-ends or holidays → I deactivate self calibration or reset value to the previous one during week-ends) due to the simplification of “first order system” (actually this is at least a 2nd or 3rd order system), + this can be sensitive to strong winds (for old buildings with higher air infiltration rate correlated to winds → I have the ambition to take this into account in a future version, that’s why I included wind speed)

For now, it is running fine, and I am checking the recovery start times. The recalculation is working fine now and starts as you mentioned as the heating off time is reached.

Regarding the sensor.night_state, I tried to figure out what it is and how it is calculated, but since only the mini-graph references it, I wasn’t able to find out.

Any hints for me?

1 Like

Wow, thanks for the feed back, you are the very first user and it’s cool to see it works on another machine that mine :clap:

Just one thing to take care: if you update home assistant (other than quick reload), then RCth and RPth will be reset to the initial values (it’s easy then to change back the values to the last one looking at the curve historical values). That’s something that could be improved.

Anyway, almost one month now since i’m using it, and it’s working for me quite well, but as those days are very windy hopefully I will work on auto-adjustments considering wind infiltration rates.

I have lot of other ideas, I just need more time. another easy step is too set the target time to the alarm of my phone, which would avoid to adjust the target time manually.

I’m considering the possibility to make a blueprint too, but that would be mostly for easiest installation for potential users… so it would be time consuming for me for almost no-one

Create a new template sensor sensor.night_state like this :

{% if is_state('sun.sun', 'below_horizon') %}
  1
{% else %}
  0
{% endif %}

Hello again, for the past few days, the script has been running in the background. In the first few days, there was a noticeable change in RCth and RPth. But since a restart, the values remain at their initial settings of 50h / 50°. No changes are observable anymore.

grafik

I have also observed that the set temperature is reached much too early. DESIRED: input_datetime.target_hour: 06:30 / input_number.tsp 19.5°
ACTUAL: target temp reached at 04:30.

I restarted HA now and will see if there is a change. Any other hint forme?

Hello,

This is problem that I didn’t anticipate… Actually, the initial values of 50h/50°C are convenient for the first start, but each time you hard reboot HA (e.g. after a core update) the initial values will overwrite your results from Self Calibration learning.
→ So the workaround now for you is to :

  • first click on Self Calibration to deactivate it and change manually the values of RCth and RPth to the last ones of your Self Calibration (I can see on your graph that RPth is below 50 and RCth above 50). Then you can reactivate again the Self Calibration button
  • there is the same issue for the name of your interior temperature sensor that should have been reset to the initial text value (so your interior temperature might broken until you change it again)
  • Next, to avoid further reset at 50, and interior temperature issues, edit the package file and remove all the 3 lines where it is written an initial value (RCth, RPth and interior temperature text)

→ I will correct these in the next version :+1:

Yes, this is certainly due to all previous comments that you can easily correct like I said.

Though, I am preparing an update with further improvements :

  • taking into account the time lag for a better prediction of RCth if your emitter has an important thermal mass (this is working well for me since one week)
  • an option to set the target time synchronized with the wake up alarm of the phone, this is really cool and this works very well too
  • I was waiting to finish the self calibration with wind conditions, the concepts and equations are ready, but it still need to be implemented and tested…

Do you want me to push an updated version even if it I have not totally finished the ongoing modifications ? Or you can manage with the explanations above until then ?

Hello, the calculation of the heating start time from the alarm clock works very well. In the evening, the phone reports the earliest wake-up time to HA and the lead time is deducted from this. It has worked very well so far and the lady of the house is satisfied. :slight_smile:
I would like to use your script for our other rooms, I guess I will have to rename all the sensors etc.?

Otherwise, thank you very much for the scripts, I had also tried the other things you mentioned at the beginning with no good results.

Translated with DeepL.com (free version)

1 Like

Thank you for your feedback and hints on how to solve my issues.

I was aware of resetting the “interior temperature sensor” as well as the “RCth and RPth” to the last known vaues, and I did it as mentioned. So, this cannot be the cause.
I use automation to start/stop the smart heating mode during weekends (as per your hint).

What I also found out is that the
grafik

had been constantly “on” since the issues started. However, after the reboot or the test “calcul relance radiateur,” it is now set to “off.”

I will observe the situation again tomorrow morning and provide feedback. I’m fine with waiting a few more days for an update—step by step.

That being said, I’m looking forward to the new features, and I really appreciate all your work on this!!!

1 Like

thanks for the feedback :+1:

  • Yes this is possible, (not clean but doable and almost easy) → copy / paste the room specific variables and automations in another package, and replace with a new name the variables specific for the new room in order to avoid conflicts…
  • But this is something I want to do asap… but I cannot garantee when, and any help from more experienced developers is welcome to help me on this point (to transpose all automations and variables in a single blueprint or whatever that makes it replicable)

These 2 on/off flags are set in order to identify the ongoing cycle stage:

  • the first one (RCthdyn flag) → switchs to ON at heating stop time (e.g. 11PM)
  • the second one (RPth flag) → switchs to ON at recovery start time, e.g. 3AM (and at the same time the first one switchs to OFF
  • at the end of the cycle (wake up time) → RPth flag switchs to OFF and both ar off until the next cycle.

EDIT: I’ve updated the package + if nothing happens the configuration smartheating is maybe deactivated ? (check also if all the automations have correctly triggered and if interior temperature name is correctly defined)
image

I am completely confused and need further assistance.

As already mentioned, the calculation no longer works. I deleted the .yaml script and all entities, rebooted the system, and set everything up again.

Then I copied the .yaml with the packages, rebooted HAS, set the interior temperature, heating off time, and wake-up time. I ran calcul relance radiateur, checked the correct timestamps at Recovery calculation update - between calc_hour and start_hour as well as the Wake Up Time (e.g., 6 AM), and waited for the heating off time. Unfortunately, I got the same result.

The calculation of RCth dynamique does not start at the recovery calculation hour just after the radiator turns off (e.g., 11 PM) with a 20-minute repetition. recovery_calc_mode remains off, even though the Recovery calculation update - between calc_hour and start_hour has already been exceeded.

I then manually set recovery_calc_mode to on, and as expected, the script performed the calculation every 20 minutes.

However, rp_calc_mode does not start at the recovery start time, and neither mode switches off when reaching the Wake Up Time (e.g., 6 AM).

I really like the idea of this project and would love to get it running… Thanks in advance for your help!