optimisation issue

[thios]

Hi,
I tried to activate the optimisation function of my evohome with optimised start a month ago and since then, I see no change on my system.
I configure some hour for a room and at the hour I configure, the controller show "opt" but still don't heat. I have to wait 20 minutes for the system to start heating.
I thought that the hour we configure was the hour at which we want the temperature to be the configured one.
2 solutions:
- I didn't configure it correctly
- There is a bug.

Any idea of what's happening?
Thanks

Mat

[DanD]

Hi,

If the controller is showing 'Opt' on a zone then I believe that this indicates that it has automatically altered the setpoint on the zone, bringing forward the time at which it increases the setpoint to help ensure that the zone reaches the setpoint temperature at the time you originally set. It will still take 20 mins or more for the radiator to reach it's normal temperature and the room temperature to increase. However, you should notice that the setpoint change occurs earlier that the time you set for the change, if the room requires additional time to reach temperature. On the newer Wifi controller the symbol appears as a wiggly arrow.

Dan

[thios]

more explaination: I have configured 15°C for cold time (out of home) and 19°C for hot time (in house).
The hot time is configured to 18:30.
When I come home around this time, before this hour, the controller is still in cold temp, after the hot time, it's still in cold temperature but with "opt" and it come to hot temperature after 20 minutes.
Always the same time until I configure it.
Mat

[DanD]

Hi Mat,

Can you check your optimisation settings? Here's the page from the FAQ doc for your Evohome controller (I think you have the non-wifi colour version). Press and hold the settings button to get to the first menu. Make sure that 'Optimum Start' is selected.

Optimisation.JPG

[paulockenden]

Optimised start times definitely do vary. I have mine set to an hour, and most times the system uses that full hour (and so it up to temp WELL before the start time as my house heats quickly). But if the room temp is closer to the next setpoint then optimisation doesn't kick in for the full hour - it definitely varies.

But it always seems to take a pessimistic view, and over-does things. I guess that's the only way it can guarantee to be up to heat, at the time you specify.

Shame there isn't an 'expert' mode, that allows people to tinker with the various parameters involved.

[zcapr17]

more explaination: I have configured 15°C for cold time (out of home) and 19°C for hot time (in house).
The hot time is configured to 18:30.
When I come home around this time, before this hour, the controller is still in cold temp, after the hot time, it's still in cold temperature but with "opt" and it come to hot temperature after 20 minutes.
Always the same time until I configure it.
Mat

From this description it sounds like you have "Delayed Start" configured instead of "Optimum Start" (which will bring the setpoint forward).

To backup what Paul's written, here's a chart of my Kitchen thermostat showing periods of "Optimum Start" and "Optimum Stop" in operation...

Green shading is periods of optimisation, orange is periods of heating. On this particular day, Evohome raised the setpoint 45 mins early in the morning, and managed to reach the setpoint 15 mins early. In the evening, Evohome dropped the setpoint a whole hour early. I typically see periods of optimisation anywhere from 5mins to an hour.

[DBMandrake]

From this description it sounds like you have "Delayed Start" configured instead of "Optimum Start" (which will bring the setpoint forward).

I think you've hit the nail on the head there... I had forgotten that the Delayed Start option even existed when I was trying to think of explanations for the problem described.

Personally I don't understand the purpose of Delayed Start, so I didn't give it a further thought after reading about it during initial setup...

Optimial start seems to be working reasonably well for me at the moment - I have maximum startup time set to 2 hours and it rarely uses the full amount, and typically zones are all up to temperature about 15-30 minutes before scheduled times unless I have pulled the carpet out from under its feet by dropping the flow temperature suddenly one day or leaving a towel over a radiator that didn't previously have one.

(Both of which obviously slow room heat up in a way that the Evohome could not predict ahead of time)

I did have some problems for a while where one zone was heating up way too early and didn't seem to adapt correctly, but it appears that you can reset the optimisation learning of a zone by re-binding a different temperature sensor. For example in a zone where the HR92 was the sensor I would bind the evotouch internal sensor as the new temperature sensor for the zone (assuming it was not already being used) and then some time later bind the HR92 as sensor again without changing anything else.

I can't be certain but this did seem reset the learning strategy as it started to adapt again over a day or two.

[thios]

I think you're right.
I have a french version and the translation is not the good one.
If I refer to the FAQ Dand include, the "delayed start" has been translated in french to something like "optimisation at start" and "optimum start" as "maximum duration of optimisation" that is not very understandable.
I will start this one, I hope the position in the interface is the same...
Honeywell need a better translater, or a better documentation (never find one in french or in english that explain this functionnality).

[bruce_miranda]

Is there a way to reset the previous optimisation data that may be stored and force the controller to relearn from scratch?

[paulockenden]

Yeah - just set the temp sensor for the zone to be the Evohome controller, wait ten minutes, then set it back to the proper temp sensor. That should kick off a full learning phase for that zone, including optimisation.

I think!

P.

[DBMandrake]

Shouldn't be necessary in theory. I suspect that switching optimisation modes like that will start the re-learn process anyway.

By the way I checked all my zone graphs today for morning start up times and optimisation is working really well here at the moment. Maximum pre-start time is set to 2 hours. The following zones they are scheduled to 5 deg over night. For my Saturday schedule (which I'm running every day as I'm home for a couple of weeks) I see:

Bathroom: Scheduled for 20 deg at 7:30am - came on at 6:35am starting at 15 deg and reached 20 deg at 7:15am. (15 mins early)
Hall: Scheduled for 20 deg at 7:30am - came on at 6:45am starting at 18.5 deg and reached 20 deg at 7:05am. (25 mins early)
Kitchen: Scheduled for 20 deg at 7:30am - came on at 6:35am starting at 15 deg and reached 20 deg at 7:20am (10 mins early)
Living Room: Scheduled for 20 deg at 7:30am - came on at 6:35am starting at 16 deg and reached 20 deg at 7:20am (10 mins early)

With a two hour maximum pre-start setting they could have potentially come on as early as 5:30am if things were not working properly. The only one that has a bit too much lead time is the Hall - however I have been changing the temperature sensor between the HR92 and the Evotouch every day or two for testing purposes in the Hall, so I suspect it is not getting a chance to fully adapt to the different temperature measurement location as it would if I left it alone.

Quite why I was seeing target temperatures being reached over an hour too early a while ago (living room mainly) with no attempt to correct the error and why it is working correctly now I don't know.

[xylophone]

Hi there - on a subtlety of the points raised here- if I have 2 rooms in a zone with different thermal characteristics, do the stats learn optimisation independently or is it just at zone level? Many thanks.

[DBMandrake]

Hi there - on a subtlety of the points raised here- if I have 2 rooms in a zone with different thermal characteristics, do the stats learn optimisation independently or is it just at zone level? Many thanks.

That is an interesting question that I hadn't thought about before...

There are two parts to the "self learning" that the system does for rooms - one is learning the thermal characteristics of the room to be able to control the set point accurately without excessive overshoot. In other words, the HR92 has to figure out how far to open the valve and how early to start closing it before the set point is reached to maintain a steady set point in a room which may have a vastly different size radiator, insulation characteristics and so on to a another room. In techno speak the HR92 is a "PID controller" with self-learning/tuning heuristics, so over time (it takes a few days from a new install I find) it adapts to the response time of your room/radiator etc.

Before this learning is complete you might find for example that when you increase the set point from 10 degrees to 20 (with a room temperature of 15) that initially it may overshoot the set point by a couple of degrees because it doesn't know the response time of the radiator and room. In the future it will start to preemptively close the valve further and sooner before the target is reached and after a while it will reach the target quickly without too much (or any) overshoot.

This part of the learning process is done in every individual HR92 and cannot be turned off so for this aspect - yes the system will adjust to the different thermal characteristics of each room even in a multi-room zone consisting of HR92's in different physical rooms.

The other part of the self learning process called "optimisation" is where the system will try to predict how much earlier than the set point you specify that the zone should come on to reach the target. This can be turned on or off. So for example if your set point changes from 5 degrees to 20 at 6am and the current room temperature is 15 degrees, with optimisation disabled it will simply wait until 6am then change the set point to 20 and the radiator will start to heat - with the room actually reaching 20 quite some time later.

With optimisation enabled the system will monitor the current room temperature of zones and learn over time how quickly each room heats up, so when it sees the room has to be at 20 degrees at 6am it will change the set point on the HR92 to 20 earlier than 6am with the intention of the room reaching 20 degrees shortly before 6am.

This is handled centrally by the controller - which is in charge of scheduled set point changes, and it works by it sending out the set point change earlier than the schedule says and over time learning how much earlier it needs to be for a given room for a given initial temperature differential. (Obviously if the room starts colder it will take longer)

Here's where it gets interesting. In a multi-room zone the controller only "samples" the measured temperature of the "primary" HR92 in the zone - which is whichever one you bind first in the zone. This is the temperature it shows on the controller, so in a multi-room zone the only way to know what current room temperature of the secondary room(s) in a multi-room zone are is to look at the HR92 itself.

My assumption - and I have not tested this to verify it, as I don't have any multi-room zones, is that because the controller only monitors the measured temperature of the room the primary HR92 resides in, this is the one that will be used when calculating the optimal start lead time, and that assumption is partly based on the fact that it can't send different set points to the different HR92's in the same multi-room zone. Part of what defines a multi-room zone is that they share the same set points. (Unless manually overridden at an HR92)

So in other words if you had a multi-room zone consisting of two rooms one with a long warm up time and one with a short warm up time, you'd probably need to have the primary HR92 be the one with the long warm up time, otherwise optimal start would not come on early enough to get the slow room up to temperature. And even if you did that optimal start would never be perfect for the secondary room(s) because it also depends on the starting temperature of those rooms - which could vary depending on whether doors/windows were left open, when they were last turned up manually etc.

[bruce_miranda]

All I would say is that it is possible for the controller to perform optimisation per HR92 as opposed to per zone. Every HR92 does tell the controller it's own temperature reading whether it is the displayed one or not. Now whether the controller is intelligent enough to break down a zone into its individual components is an entirely different question.
This issue should be no different to a large room that has multiple HR92s within a single room.

[DBMandrake]

All I would say is that it is possible for the controller to perform optimisation per HR92 as opposed to per zone. Every HR92 does tell the controller it's own temperature reading whether it is the displayed one or not. Now whether the controller is intelligent enough to break down a zone into its individual components is an entirely different question.
This issue should be no different to a large room that has multiple HR92s within a single room.

I don't believe that is true actually - only one sensor can be bound to a zone, just because the additional HR92's in a multi-room zone broadcast their temperature measurements (which we know they do, as domoticz can capture it) doesn't mean the controller pays any attention to those additional sensors in a multi-room zone - my belief is it ignores them, mainly because the binding process doesn't provide any way to inform the controller of those temperature sensors. (Remember when you bind additional HR92's it only binds the actuator side of them - every HR92 is treated as two devices, a sensor and an actuator)

Also I've seen no evidence that the controller has any way to send out different set points to different individual HR92's bound to the same zone - I don't think the protocol allows for that.

Ultimately, someone with optimal start enabled and a multi-room zone will just have to test it empirically to see what it does, but my money is strongly on it only using the primary HR92's measurement to calculate the optimal start time - which will then apply an early set point change simultaneously to all rooms in a multi-room zone.

Anyone bored enough to conduct a test ?