-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an adaptative regulation in over climate mode #129
Comments
Thanks. I suggest a development in two phases:
The second phase is most likely much more work (and might not be ready for this winter?) |
Yep. Will see that. |
If you add some kind of own mechanism to control the way the thermostat tries to reach target temperature, could you please nevertheless retain the current mode in which the thermostat does this with its own algorithms? |
In my understanding this feature would only calculate a long term (days, weeks) offset between target temp and room temp and allow to adjust for that by sending the TRV a slightly lower/higher target temp. But of course it should not change the way how a TRV achieves the goal of a certain target temperature. |
That is what I intend to do @Ra72xx. |
This might also solve my issue. I have a innova 2.0, used as AC heater. The temperature sensor is very inaccurate as it's withing the heater and can't be moved outside. Would like to be able to control this behaviour on top of the underlying thermostat (here the innova 2.0) and I think this component is already doing a great thing. |
Development is starting.
It calculates an offset (ajustement in French) which is the combinaison of the error (P) and the integral of the error (I).
Any comments on the plan would be greatly appreciated if any !. NOTE: this will be available only in over_climate mode. |
Thanks a lot for working on it. I can't yet understand the code as I don't speak french and will need to get google translate to translate your code (isn't there a ChatGPT kinda tool that allows code translation? I would hope so). But I'd appreciate it if I could also define a manual offset that is not adjusted at all. And by the way, the outdoor temperature most likely has a strong influence on the offset. The colder it is outside, the higher the difference between the temperature measured at the radiator and the temperature measured in the middle of the room. But as an initial question: What is a "cycle"? Is a cycle something that happens every few minutes or hours or days? |
yes. I will translate the algorithm now and post it with English variables names. |
Haha, so is a cycle minutes, hours or days? :) |
Yes in minutes. All VTherm have a cycle in minutes configured. The algorithm is English have been posted above. EDIT:
It would add another layer of complexity. if the regulation works well, you don't need any manual offset. For now I do not intend to implement this. |
Thanks, I will have to take a look what happenes within a single cycle. I think I remember having seen the cycle length in the config options but though it was not relevant for the "over climate" mode.
Okay, I understand. And as for my personal experience with the needed offset: last winter it ranged from -1,0° C to +2,0° C, meaning that:
I only had to adjust the offset temperature about once every few weeks for a temperature that was "good enough". |
VTherm over switch and over valve are already controller by an algorithm which is a TPI (Proportional and Integral). So we don't need to adapt the target temperature in that cases but eventually to adapt the coefs for the TPI algorithm. The auto-regulation (or regulation by changing the target temperature), only make sens when regulation is not done by VTherm itself. |
OK |
I understand your point but this is not TPI algorithm. TPI doesn't change the target temperature but changes the power percent. In the VTherm over switch configuration, you can choose an algorithm and the only choice now is TPI. This is another algorithm like PID which is not planned to be implemented yet. But it will be one day, I hope so. |
Got your point, but if we use this algo with internal_temp = current temp it should work almost out of the box no ? And at least you can get ride of the external probe sensor ( + I am quite sure the proportinal/integral on error should help smooth the TPI algo) In fact, could be easy to try/use by just running an over_climate vtherm over a switch vtherm EDIT : after receiving the "adjusted temperature" we can convert it to power as usual, instead of replacing TPI, it can just be an addon to the TPI ( ie: we receive 20° target temp, it goes into the new algo, based on previous error we compute that target temp should be 20.5° and then it goes back into normal computation. Or adjust TPI algo to add the offest into the formula ( if the new algo return offset+offset_ext instead of target_temp+offset+offset_ext) |
@maia , @adi90x I have published an alpha release https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.alpha1 if you want to test. i will do my-self in // on my AC device. It is only for VTherm over climate for now. |
it is working in my house. you can test if you want. |
Thanks, I will test it as soon as possible (within the next 24-48 hours). Shall In enable debug/info/… mode in logging to track what it does? Is there anything else I could adjust or specifically test? Any specific kind of feedback you're looking for? |
Huummm, ok thanks for the informations. I don't understand why the temperature don't goes up even if the valve is open at 45% ? Is it normal ? Another remark, can you control directly the valve position of your EVE TRV ? If yes, I add a new VTherm over valve for doing need. |
This is completely normal. The cycle of a central gas heater works the following way:
In my current case, the gas heater was simply off for 20 minutes, as in the previous cycle the water returned was too hot. This is common when the outdoor temp isn't very cold and the gas heater is a bit larger than necessary. The goal is to prevent frequent cycles. A gas heater shouldn't run more than 4-6 cycles per hour. As the the room I'm testing in at the moment: The radiator now is warm, as it has water with ~45° temperature in it. It will take another 30-60 minutes until the room temperature rises significantly. So between the start of the adjustment of VTherm and reaching the target temperature it'll take about 2 hours. Of course I could adjust my gas heater and tell it to heat the water to 70°C and to turn on up to 20 times per hour, but this is a waste of energy. Even the water pump for the radiators needs lots of energy, not even considering the gas. That's why it's only turning on a few minutes per hour. |
PS: no, I cannot control the valve directly. Homekit devices do not expose this. There will be a Matter upgrade for my Eve Thermo TRVs in mid-November, then the valve might be adjustable, I don't know yet. But Eve does a pretty good job at adjusting the valve. |
@jmcollin78 Being able to adjust the step size (the thermostat only accepts 21.0°C, 21.5°C, 22.0°C, 22.5°C, 23.0°C,…) and the cycle duration should help. I'm looking forward to the next beta. Edit: I think you should not use the word "threshold", I suggest using "step size" instead. Because threshold would implicate that only the first step is 0,5°C but after that the next steps can be 0,1°C again. |
The new beta is here: https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.beta3 NOTE : the log to find the regulation changes is: |
I've been using the "medium" mode in six rooms for the past hours. It's warm outside, so the heater doesn't turn on a lot, so the temp in the rooms doesn't change a lot. I've noticed a bug: The calculated offset (regulated_temp - target_temp) should not change when the preset changes. Once the algo finds a "good" offset that is added/subtracted from the target temperature to ensure a proper room heating, it shoulnt not be "reset" when a preset changes the target temperature. The above is an example for something going wrong: Around 17:00 the algo thinks that the offset can be -1,5° from the target temperature at the valve. But then at 18:00 the target temperature is raised by 1°C and the offset increases by 3°C, instead of staying at -1,5°. @jmcollin78 Maybe you have something in mind that's fine for electric heaters but not for valves? What I've been suggesting over the past week or so is a stable offset value that can be defined which will always be added/subtracted from the target value and which is then passed to the underlying. So if a room heats fine with an offset of 1°C, then that's what is added to the target temp for the next weeks (until the outdoor temperature changes radically). But what the algo currently tries to do is to outsmart the valves by adjusting the target temperature over minutes or hours – and resetting everything when the target temp is changed. I'd be most happy if there was an input field in calculation named "offset" where I could define "+1,5°C" which is then used for the next weeks, when I notice a room is warmer than intended. And I'd be even more happy if that offset could be a function of the outdoor temperature (lower offset at lower outdoor temperature). The current algo seems to have a different goal? |
Are you in beta3 ? +3 ° is the max allowed for Medium regulation so it is not totally anormal. I will do the calculation by hand to see if something weird happens. Moreover, I don't understand why it was heating at 16h45 with a regulated temp at 18,5° and target at 20°. There is something wrong at this place. EDIT : I post this before your changes. |
Yes, I'm in beta3.
I don't know when it will shade the area orange. How does it define "heating"? Is it orange when the valve opening is above 20% or so? I couldn't figure out the orange shading, so I currently am ignoring the color. |
It would like to have the log around 18:30 ? Did you restart HA ? Or the integration or change the configuration of the VTherm (which reset all parameters) ? |
I have a regulation running all the afternoon and I don't experience this. I'm with a reversible climate. It was too warm so I force the temperature to 22° at 11h00. I've got the +3° when I change the target. As you said, when the target change, I reset the accumulated error which no more valuable in my opinion because conditions changes. But may be I'm wrong and I should keep the error. Let's do the calculation by hand: So the offset is +2 + 0,12 + 1 -> 3,12° limited to 3°. So the calculation seems good. This shows that accumulated_error is NOT resetted else we should have +1,12 ° . Maybe the bug is here. EDIT: the accumulated error factor should be -2 in your case (and not +2)! So I think you are right, there is something weird.
I think you don't really need regulation. For you I will suggest a Light regulation (more stable with low variations). |
Yes, you should keep the offset/error. Two examples:
And unless the usage of the rooms change, it doesn't matter if the target temperature is set to 20°, 21° or 22°. The room no. 1 will always be warmer than intended, the room no. 2 will always be cooler. Only if the outdoor temperature changes radically, the offsets change. Imagine it has -10°C outdoors. Now the offset in the room number two will need to rise to +3°C to ensure that the room temperature is okay, even if the door is opened frequently. PS: I more or less have rooms as in the examples above. Which is why a regulation is very helpful to me. |
I will try to remove the reset indeed. I think you are right. |
Great. Also the offset should survive HA restarts. Something that might need a day or two to settle properly should not be reset unless the user wants to reset it manually. |
https://github.com/jmcollin78/versatile_thermostat/releases/tag/3.8.0.beta4 I remove the reset at each target temperature change and I lower all coefs. There were still too much.
This makes no sense. The offset is fully calculated at each cycle and change. This offset is not stronger because it has been calculated during 3 days. The eventual restored value will not be used and recalculated immediatly. |
I installed beta4 at 4:45 in the morning. The algo currently "overshoots" with its swings in both directions, as it doesn't consider that heating a room by 1°C will take 1-2 hours. How can I tune the variables to prevent that behaviour? I'm currently using "medium", 0,5°C step size and a 15min cycle. |
Maybe I should set the minimum cycle to 24 hours to prevent the issues of overshooting when the preset changes during the day? |
Recalculation needs a few cycles. So with a cycle of 15min this might mean 1-2 hours until it's recalculated. With a cycle of 24 hours (as mentioned above) it would mean 3-4 days lost with a single HA reboot. |
In your case, I would recommend the Light mode of the regulation algorithm and a period of 30 min because your heating is slow. You definitively don't need much regulation thanks to "the good jobs" of EVE valves. Note: I will release in few minutes. |
I will close this discussion, but you can continue if you want to post your experience / remarks / trouble here. |
@jmcollin78 Thanks, I will switch all entities to "light" mode and 30min cycles and give you an update in a few days. By the way, how does the regulation algorithm deal with open windows? Will it be paused for the time the window is open (e.g. 20 minutes) or will it steadily increase the regulated target temp? |
When the window is open, the VTherm is shut off. Then then temp will go down and the offset be at its maximum. When the window is closed, the VTherm turns on and send the maximum regulation to underlying this will boost the heating of the room. And progressivly the offset will recover the stable value. I guess this is expected behaviour and the big advantage to have an offset which is depending of the conditions. |
…78#148) * Algo implementation and tests --------- Co-authored-by: Jean-Marc Collin <jean-marc.collin-extern@renault.com>
It very much depends on the construction and outdoor temperature if this is helpful or not. Because one could also argue the other direction: When a room that was constantly at 20°C is filled with cold air for 30 minutes and it's air temperature drops to 17°C, this does not mean it needs to be heated at all. As all walls, the floor and the ceiling all still have 20°C and hold temperature much longer than air, the room might be back to 20°C within another 30 minutes even with no heating at all. In situations with bad construction that does not maintain temperature long and with very low temperature outdoor it's different. But think of a big church and how it can hold its temperature over months. It all depends on the mass of stone/concrete/… you're surrounded with. Also it seems you don't trust how TRVs regulate the valve and try to boost its regulation. This is a completely different use case than what I was describing in the past 2 weeks: |
Hello, Instead of using 3 different classes ( or even 4 in code ) why don't we have only one```RegulationParamXXX`` and let user input all parameters in setup ? ( Same one service can be use to update all those parameters ) and then maybe only put some basic parameters in the documentation ?
|
Because it makes 6 different parameters + 2 parameters (dtemp and period) to input which is very much complicated. |
Maybe it could be a new page in config when regulation is ticked no ? |
I thought about it but, really i want to keep it as simplier as possible. I'm pretty sure the parameters given will satisfied 99% of the needs. There is already 60 parameters now, and it is very important to keep that as simplier as possible for most of the users. I see some PID algorithm and other AI algorithms with lot a confusing parameters and many people having great difficulties to use it. That is not my philosophy. But what is possible, is to have an "expert mode" in the Switch type page, and then a new page or a config in configuration.yaml. So that expert people will be able to specify their parameters. In that expert mode, it should be possible to specify a static value as asked by @maia . But for now, because, I do a lot of work on the last month, I will make a pause and wait for user feedbacks on the current new self-regulation. Feel free to propose a PR in the mindset exposed above if you think you can do it and have time for this. I would be please to merge it. |
I add a Discussion section on the root page of Versatile Thermostat if you want to continue this discussion |
Following a discussion in #125 issue, we need a regulation for over climate mode. This regulation should:
So regulation can be done by VTherm using the target temperature value and adapting it constently.
Some PI (proportionnel-intégral) algorithm seems to be exactly what is needed for this.
The text was updated successfully, but these errors were encountered: