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

Share your Projects! Scripts
,
21

Thanks for sharing :+1:

So you don’t take into account the external temperature :thinking:, 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.

22

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

1 Like
23

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:

grafik
grafik1534×489 12.1 KB

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!

24

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 :see_no_evil:)

image
image611×400 21.8 KB

image
image
image
image

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

25

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!

1 Like
26

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

27

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.

1 Like
28

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.

29

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 :star_struck:

1 Like
30

Thank you :+1:

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.

1 Like
31

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!