Howto use versatile thermostat and scheduler to set desired temp at a time

[RastaChaum]

Hello everybody,

I use versatile thermostat with scheduler for a long time ago. It's really usefull. But there is a missing feature for me : when i schedule to pass the temp from 18⁰ to 20⁰ at 07:00am, i would like that the temp be at 20⁰ at this time. Not that it starting to heating.

Because of the type of heat, the diff between initial temp and target temp and the external temp, it could take from some minutes to some hours !

And so it's hard to anticipate with the scheduler at witch time to really start the heat. But with TPI algorithm i think that it could be possible.

Does anyone already do this ?
Do you think that it need a new specific scheduler integration ?

Thanks a lot for yours answers and helps !

[jmcollin78]

Hello, this has been requested so many times I cannot count them. But I cannot access to the Scheduler value to anticipate the change of preset. I have no solution for this.

[doubledrat]

hehe - this was going to be a future suggestion of mine! My nest thermostat does this. You say 'I want the temperature to be 20 at 07:30' and it works out based on outside temperature what time it needs to start heating to achieve this.

I think it would need a new custom scheduler integration

[RastaChaum]

Hi, Thanks a lot for you mr replies. I searched some threads of discussion about this feature on google, but i never found one... I probably not used the good terms. I have some programation notions, but i never watch how to developp on HA. It could be the time for it 😅. @jmcollin78 : do you think that i can get thermostat values from scheduler ? Or it is not permitted by HA ? Le mar. 11 févr. 2025, 12:10, doubledrat ***@***.***> a écrit :

…

hehe - this was going to be a future suggestion of mine! My nest thermostat does this. You say 'I want the temperature to be 20 at 07:30' and it works out based on outside temperature what time it needs to start heating to achieve this. I think it would need a new custom scheduler integration — Reply to this email directly, view it on GitHub <#900 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAD25G5CH3EXUGCLFOLIXD2PHLEBAVCNFSM6AAAAABW3AIOUGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJTHEZDONQ> . You are receiving this because you authored the thread.Message ID: <jmcollin78/versatile_thermostat/repo-discussions/900/comments/12139276@ github.com>

[jmcollin78]

You will need an internal scheduler in the VTherm so that it could be aware of the next change. And developing a scheduler is something very hard. The HA Scheduler is perfect for this.

Then you will need the slope heating curve calculating by previous heating sessions to calculate how many minutes you have to anticipate. This is a research project itself.

What not simply change the setpoint earlier ? Is that not the best way to achieve what you wants ?

[jmcollin78]

Some issue example which aims to do the same: #792. The others are closed or in discussions or the franch HACF forum.

[nicola-spreafico]

Hello,
I found out this thread googling for this exact scenario.

I have rooms with different isolation and different heaters size, so it takes a different amount of time to reach the target temperature.

A feature where I can set the target temperature and the time of when having it, would be game-changing, basically the system "learns" from temperature slope and previous heating sessions to determine some kind of coefficient on when to start heating in order to obtain that temperature for a giving time.

The interaction with the scheduler card might be a separate issue, but probably the most complex part is to calculate "how much time will I need to move from 18 to 20° in this room considering that the outside temperature is 13°?"

Also the scheduler component provides a list of services that may be used to interact with the existing schedules, such as schedule.edit, with the proper configuration this integration may alter existing schedules fine-tuning the time for the action.

Not easy for sure, but probably one of the best functionalities someone may have.

[RastaChaum]

It might be useful to break the scenario in parts, like a separate integration/sensor that provides only the calculation about the time needed to heat from x to y, and the each one can use that value for its own setup, so you can do your own calculation and enable heating when you wish

That is a very interesting architectural suggestion, thank you!

I think I understand the core idea, which is to follow the principle of separation of concerns by isolating the prediction logic from the actual thermostat control.

My Interpretation

You are suggesting the creation of a separate Home Assistant entity or integration (let's call it the Thermal Prediction Helper) that would have a single job:

• Input: Take a starting temperature ($T_{start}$) and a target temperature ($T_{target}$).
• Output: Provide a sensor value, sensor.time_to_target, in minutes or hours.

This sensor value could then be used in any automation, or even by the Scheduler Component, to trigger the VTherm's setpoint change early.

Is that correct?

Next Questions to Define the Architecture

If this architecture is correct, the biggest challenge is where this new component would get its data, specifically the room's "Learned Heating Slope" (LHS):

1. LHS Source: Do you suggest that this new Thermal Prediction Helper should be responsible for calculating and storing the LHS itself (meaning it would need to listen to VTherm's heat calls and the temperature sensor)?
2. LHS Dependency: Or do you suggest that VTherm should expose the calculated LHS as an attribute (e.g., attribute.max_heating_slope) so the external component can read it?

I am eager to hear more details on how you envision the data flow, as this solution would indeed increase the modularity of the entire heating system.

[nicola-spreafico]

You are suggesting the creation of a separate Home Assistant entity or integration (let's call it the Thermal Prediction Helper) that would have a single job:

Basically, yes. I'm still thinking that some sort of machine learning may be involved to get an accurate assesment, but maybe I'm wrong.
You should store data such as external temperature, internal temperature, target temperature, probably the open percent of the valve and also probably the day of the year (different seasons, different temperatures) and do this for each room.

From there you should have a model to calculate some kind of coefficient in ther formula you already suggested

(Target Temp - Current Temp) / Learned Heating Slope (LHS)

But what you do with this coefficient, and here is my idea, should be isolated by the termostat itself, this allows you to cover all kind of scenario, automation, setup, heaters, ... making it more flexible and reusable. Maybe you want to do more advanced automations such as "if the anticipation time is greater than xx don't do it, set a lower target temp to save on fuel", something like that.

[jmcollin78]

If the HACS Scheduler Component is used, and it creates a switch for each schedule (switch.red_day_schedule, switch.blue_day_schedule, etc.), @jmcollin78 : could you tell me if theses schedules are all on in the same time ? Or is there just one activate ?

The 3 are active at the same time but a set of conditions make only one controlling the preset of the VTherm:

[jmcollin78]

It might be useful to break the scenario in parts, like a separate integration/sensor that provides only the calculation about the time needed to heat from x to y, and the each one can use that value for its own setup, so you can do your own calculation and enable heating when you wish

That is also my idea:

1. creates a new integration,
2. make this integration able to control a VTherm (through preset action change),
3. make this integration able to calculate the LHS (listen to VTherm events -> change of hvac_mode, change of current temperature)
4. make this integration able to listen Schedulers. Scheduler entities have interesting attributes:

5. when one of the attributes changes, then start a timer until the next change and anticipate the action sends to the Vtherm (ie the action which is stored in the Scheduler switch entity attributes).

This seems now feasible when I look all this steps. Point 3 is the most difficult point. Maybe we should turn VTherm into a learning mode or something like that to take only a correct period in calculation (and not listen every changes). Maybe an IA is finally the best way to obtain something: give it the different temperature measurement during a heating phase and see what is the answer. My fear is that LHS is not a constant but will vary over time depending of the season, humidity, wind, room insulation, ...

[RastaChaum]

Hello everyone,

Thank you all so much for your replies!

This discussion—and especially the suggestion of a new custom scheduler integration —is very reassuring. It confirms that I am not alone in needing this feature and, more importantly, validates the feasibility of moving forward with a dedicated solution.

I understand the current requirements regarding access to the existing HACS Scheduler values, as @jmcollin78 pointed out. Developing a new component, a "custom scheduler integration" specifically designed for heating anticipation (or "optimized start"), seems like the best path to implement this functionality.

I will therefore be moving forward with the creation of this new integration.

I'll keep you posted on the project's progress!

Thanks again for the input!

[jmcollin78]

Thank you @RastaChaum !

Of course I can help, you can rely on me. Please give us some news when you have something to share.

[RastaChaum]

Hi everyone,

I have some exciting news to share.

After a few days of hard work, I'm proud to present my first Home Assistant integration, which I've named Intelligent Heating Pilot (IHP).

The "intelligent" part is mainly for future versions where I plan to integrate machine learning and heating optimization algorithms. It's really a complement to the Versatile Thermostat, which already does a lot, but remains focused on controlling the "heating" or "cooling" mode when it's running.

My ambition is to implement additional features like those found in Netatmo products, for example.

In short, this version is, I hope, just the first step. I wanted to move quickly to prototype the feasibility and understand what Home Assistant development entails. And I was pleasantly surprised by how relatively easy it is to implement integrations. I understand better now why there are so many of them! :)

My next step (besides fixing the initial bugs) will be to lay the groundwork for future code architecture and potential contributions. As it stands, the code is rather "monolithic" (which I don't like :) )

Feel free to try it out if you're feeling adventurous, and tell your friends or colleagues who use Home Assistant.

See you soon.

[RastaChaum]

With the URL it's better !!!

https://github.com/RastaChaum/Intelligent-Heating-Pilot

[jmcollin78]

Hello glad to here it is already in the way !

I've heard about one integration that could really help:

Schedule State Card
Schedule_state (intégration requise)

The way the Schedule state works seems promising a lot: it separate the 'when' by changing state when an event will occurs from the 'what' should be done. What you need for your integration is exactly the "when" part. When do I need to change de preset ? And then anticipate this "when" event. What you dont need is the Scheduler to do the change itself at the scheduled time.

With the regular Scheduler you will need to cancel the scheduled change to avoid overwriting the change you will made. I think this is not an easy step in your integration.

[jmcollin78]

Hello @RastaChaum ,

I read your first integration step, and it is really impressive the job you have done in fews days and the documentation you have made.
Maybe you should open the discussion in your Github so that I will be able to discuss directly in your Github and not here. As you want, there is no trouble to continue the discussion here.

One important think is that, I just publish the v8.0.0 release of the VTherm which changes many thing notably on custom attributes. There is now a structure which is documented here: https://github.com/jmcollin78/versatile_thermostat/blob/main/documentation/fr/reference.md#attributs-personnalis%C3%A9s

I add sections for attributes (kind of sub-attributes structure). Typically, the temperature_slope is now in the specific_states attributes. So you need to access it like that:

event.attributes.get("specific_states").get("temperature_slope")

and so one for the others attributes you need.
Maybe you should consider switching directly to VTherm v8.xx to avoid strong refactoring.

Keep on this excellent work !