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

ebozonne · February 12, 2025, 6:22am

Thanks for sharing

So you don’t take into account the external temperature , or maybe indirectly while adapting the rate of change?

Before this smartHRT package, I had a very simple linear equation with a fixed coefficient and temperature differences. Now, this is much more physical with the more physically correct equations that takes into account future temperatures and winds, while the final equation is almost as simple to write. I’m still testing the auto adjustment of constants with wind, but it seems I could push the update soon.

It’s not easy to share, because there are always potential bugs for others even if it works for me. Thanks to feedbacks I hope it would work for anyone interested.

Bondo2 · February 12, 2025, 5:29pm

The temperature rate of change will inherently account for external temperature, it is not 100% accurate but it has been accurate within a few minutes (unless external temperature drastically changes)
I shared it here thinking maybe you or others could use pieces of it

Monster_D · February 15, 2025, 10:54am

I love the idea of this script and am still testing whether it fits my needs. So far, the calculated rpth and rcth values are still fluctuating quite a lot:

This leads to an early heat start—let’s see how it performs in the coming days.

For now, here’s what I changed: Since the script does not keep the status of input_boolean.smartheating_mode after a reboot, I created an automation for this.

I also read something about taking windchill into account in the calculation. With which update was this feature introduced, and does it require any adjustments or input?

thanks a lot for your work!

ebozonne · February 15, 2025, 9:14pm

I just made an update I was preparing since several days, it was not easy to set up, but I think it should add more stability ! There are many possible source of variations of your coefficients, one is the wind infiltration rate.

Feb 15 update

NEW: coefficients RCth and RPth are now correlated to average winds, the self calibration auto-adjust values for low an high winds (10 an 60km/h) assuming a linear variation between both
NEW: future exterior temperatures and winds are taken into account to assess recovery start time
NEW: text field to set-up the Next alarm sensor name of your phone (e.g. sensor.mynexus_next_alarm) to automatically sync the target time with your phone alarm in the morning

So now the coefficients RCth and RPth are lineary dependant to the average predicted wind (ideally this should be log, but it will be for another version if I have enough courage). The self calibration process of both high and low wind values for this correlation was not easy to set-up, just to give an idea, here is the allure of the thing (no totally obvious )

PS: ofc I kept also the relaxation coefficient to avoid too fast variations…

Monster_D · March 6, 2025, 9:14am

I’ve been happy with the script and using it for weeks now. What I also changed was resetting the relaxation value to 2.0 after each reboot. This led to quite fluctuating rpth and rcth values, so I set it to 10 to reduce this.

Perhaps you can adjust it in the same way you did with the rpth and rcth values as well.

Thanks!

ebozonne · March 6, 2025, 10:15am

Thanks for the feedback, and I agree this initial value that resets after each boot is uncomfortable. I will try something like this, though the problem is to avoid too much configuration during the first installation. I will try to find a workaround to both keep the values that are set by the user and initialize the values at the first installation of the package to ease the first use (any advice is welcome for this process).

Monster_D · March 6, 2025, 12:38pm

something like this:

automation:
  - alias: "Set relaxation factor only on first startup"
    trigger:
      - platform: homeassistant
        event: start
    condition:
      - condition: template
        value_template: "{{ states('input_number.relaxation_factor') == 'unknown' or states('input_number.relaxation_factor') == none }}"
    action:
      - service: input_number.set_value
        target:
          entity_id: input_number.relaxation_factor
        data:
          value: 2
    mode: single

not tested yet but could work … the thermal_recovery_time.yaml would be extended on te automation-section.

Monster_D · March 6, 2025, 12:41pm

another thing is to have a #comment in your script with some version-information. I am not sure if I still run the latest.yaml script.

Pl1997 · April 11, 2025, 3:53pm

Hello ! Just chiming in to tell you that I’ve been trying to find something like this for MONTHS !!! Thank you so much for your hard work, I can’t wait to try it next winter

ebozonne · April 15, 2025, 6:19pm

Thank you

I’m quite happy, because even if everything is not polished, it worked very well for me this winter (and I’m still using it a bit though spring is not so cold).

For next versions, I really want to find some time to answer @Monster_D requests… But I have started to study the possibility with a combination of blueprint + an integration in Python for global variables. Problem I need more time to figure out how it works and there will be less cold nights to test.

Anyway, the package is fully operational and quite easy to install (everything is included). This is robust for winter season, but when it comes to not so cold nights it’s better to deactivate self_calibration, and to be sure to deactivate smart_heating_mode when no heating season is coming.

Monster_D · April 16, 2025, 1:17pm

Thanks a lot for your work – really impressive! The SmartHRT approach is truly great and very well thought out. You should definitely keep working on it, even with the warmer season coming up. I’m sure many people – myself included – will really appreciate the setup again by fall at the latest. Looking forward to future updates!

Monster_D · September 26, 2025, 6:52am

Thanks again for your great work — SmartHRT is back in daily use for me now that the days are getting colder, and it’s running really reliably.

Quick question: Have you made any progress on your plan to build a custom integration (possibly combined with a blueprint and a Python integration for global variables)? I’d find that super helpful — especially for long-term maintenance and easier configuration.

If you need tests or feedback, I’m happy to help!

ebozonne · September 30, 2025, 12:02am

Actually if you can still give feedback and suggestions, it will be a pleasure and to further figure out how to take it into account for next improvements

About future progresses: unfortunately, nothing new excepts some test up to now, but I’m out of Europe until March 2026, so I won’t risk to kill my HA with distant trials and failures

So, I’m planning to work on it as soon I’m back home (in 5 months, sorry for the delay…)

Monster_D · October 6, 2025, 5:09am

I’m curious how you handle the situation when a window is open at the recovery time. That would influence the recovery time following the rcth and rpth values and could lead to incorrect calculations for the next day. Do you have a strategy or mechanism in place to detect and account for such cases?

ebozonne · October 9, 2025, 3:49am

Yes, there are many occupant behavior parameters and this one is a big one. The most important parameter to avoid “errors” with this is the Relax factor:

By default Relax = 2.0, this value is a bit high
- advantage: the parameters self-adjust fast, which is important in the beginning because default values can be far from your real parameters
- advantage (bis): some “exceptional” weather situations (strong winds) are also self-adjusting faster
- inconvenient: like you said some exceptions (windows opening) are impacting in RCth and RPth parameters which are wrongly computed
How I manage
- If I idenfity an issue like that from last nights: I can always have a look at previous values of RCth and RPth → deactivate SelfCalibration → Set manually back the correct values (+ eventually keep Self Calibration deactivated for the following nights if I except these exceptions that I don’t want to manage)
- Given satisfaying behavior of the model I can either
  - deactivate SelfCalibration
  - OR decrease the value of Relax Factor (e.g. Relax = 0.5)
    → interesting to still adapt a bit to the season
Brainstorming for next devts ?
- Behavior is complex (some like Google Nest are claiming IA black box models - I think these are mainly simple regressions with marketing IA-washing) but I like “simple” and “logical” solutions (given that my model is “simple” )…
- Some people are working on window opening detection models, it’s another work, and some might want to just use a window opening detector
  → this could be a custom automation to just deactivate the self-adjust
- Your suggestion about windows makes me think that if this is not systematic, this is more linked to the season or the external temperature
  → this is something I wanted to test → setting up another interpolation parameter from external temperatures (= season) for RCth and RPth (same as I already did for the wind speed)
- More simple ideas are welcome (and more complex too… but…)
And lastly how the window opening impacts this specific night ?
- Interior temperature decreases faster than expected by the model → this is not a big deal because the model recomputes the recovery hourregularly, but the recovery duration will be understimated → so the set point should not be obtained at wake up time (AND eventually, depending on your window impacts, you could never obtain the setpoint because you are heating the outside mainly…)

ebozonne · December 4, 2025, 5:09am

Small update to avoid a future fix:
FIXED: platform: template (sensor) for Phone_next_alarm is now under template:sensor as required by the future 2026.6 depreciation (see Deprecation of legacy template entities in 2025.12)

bbigras · December 15, 2025, 12:02am

In summer, could SmartHRT be used in “reverse” to cool the house with the AC?

ebozonne · December 15, 2025, 9:10am

it depends:

if it’s still similar use, like cooling an office in advance during the night to get the correct set point in the morning, it should be ok. But only after sign modifications in the all equations (temperature increase with heating and positive power <=> decrease and negative power with AC).
if it’s in the afternoon to cool down the house for the evening, I would say it won’t work since I didn’t implemented yet solar gains (it was in my roadmap, and it would be quite easy, it only requires a bit free time)… which is certainly a very important parameter except if you have a bunker

PS: if you have strong internal heat gains (like a datacenter or a kitchen hobbie) it would need adjustment too, like adding a sensor for the power of the device.

bbigras · December 16, 2025, 6:20pm

Another question, is SmartHRT only for people with radiators?

I have electric heating and I tried for 2 nights. The first night, the heat started back many hours too early (maybe like 4 h).

The second night, the heat started exactly at the target time.

I do reboot my home-assistant often. I did yesterday.

ebozonne · December 17, 2025, 1:04am

maybe try 3 or 4 nights without restarting HA, the issue is the first learning process of your dwelling constants.

Yep, I can see from your curves that your heating curve is steep, so maybe you can first set the values a bit differenttly from the default values (50):

clic on Self Calibration to set it OFF
set RC_lowWind and RC_highWind to 50
set RP_lowWind and RP_highWind to a higher value, let’s try with 300 or 500
clic again on Self Calibration to set it back to ON
see after 3 or 4 nights if it’s getting better without restarting HA