Reply With QuoteI haven't had the update yet, any chance please?
Any remote weather service is bound to have some delay and cannot reflect local micro climates. Local temperature sensors would also need very careful positioning to ensure that they measure air temperature without being heated by direct or indirect solar heating. Different rooms are also subject to different levels of solar gain and wind chill etc. Lastly the individuals level of physical activity has an impact on perceived warmth.
My carefully located exterior sensor is often 1 to 3 degrees different to the values shown on EvoHome. There may be a value in adjusting boilers to reflect large changes in outside temperature, but I will continue to rely on room thermostats and manual offsets using the great new version of the Eco function using my own fuzzy illogic.
I haven't had the update yet, any chance please?
That's what I found back when I first tried this feature on the first beta.Originally Posted by paulockenden
Good idea, but the lag in reported outdoor temperature was so great in the clear evenings where the temperature was dropping rapidly that we would get cold waiting for the cold weather boost to kick in while the Evohome was still cheerfully reporting a temperature from many hours ago of several degrees higher.
Any internet reported temperature will have some lag but if the lag can't be reduced quite a bit on what it is now (down to under an hour) then I just can't see this feature being useful in practice. 4-6 hours lag just isn't useful, that's the difference between the middle of the afternoon and late at night!
Am I the only one who finds I get used to warmer temperatures in the summer and start to feel chilly in Autumn evenings at temperatures that would have felt warm in the winter? Similarly by November/December I am used to the cooler climate and find I don’t need the heating so high. Add to this I tend to ware warmer clothing in the winter and it would probably make a nonsense of weather compensation.
A clever idea that may not be so good in practice? It will be interesting to see what people think by the end of a complete Autumn-Winter-Spring cycle.
Sadly I also agree as I found the reverse happened in spring with the new feature when Evohome was still showing a low temperature outside when in fact the sun was shining brightly and the house warming up from solar radiation and yet the heating was blissfully "unaware" and was still being boosted. Unless the temperature (even if not 100% accurate to the local conditions) can reflect the "real" time temperature trend, the feature will be compromised to such a degree that will make it less than useful
Yes I'm finding the same. 21.5C (remote DTS92E) was comfy last winter but I'm now sometimes feeling cold in the evenings with the room reporting 21.5 or even 22C with the radiators off and having to turn it up slightly. (Hence being happy about the new adjustable Eco/Boost)
I don't think it's acclimatisation to the seasons though - I think it's the lack of direct infrared radiation from the radiators. 21.5C air temperature in winter while the radiators are hot and radiating IR directly at your body feels warmer than 21.5C air temperature with all the radiators in the room off.
Similar to having a comfortable temperature in your car driving in the sun on an autumn day but then driving into shadow and feeling cold despite the air temperature being the same as it was a moment ago.
I'm not sure what the solution for this is - perhaps having the temperature sensor a bit closer to the radiator (but not AT the radiator) so that it has some influence from the direct heat from the radiator (as a bias) would work, and make the sensor perceive something closer to what we do.
Because what we feel is a combination of the ambient air temperature and the heat directly radiated from the radiator.
Using an HR92 as the sensor instead of a remote sensor has the opposite problem - in the warmer weather the radiator will still come on when it is not wanted and it won't feel hot enough in winter. Some happy medium should be possible by choosing a medium proximity between the sensor and the radiators so they have some direct influence but not too much.
Last edited by DBMandrake; 25th August 2020 at 04:42 PM.
Having a well insulated house, I find solar gain is as important as outside temperature in perceived comfort. To complicate the issue still further, humidity also plays a role. I think only user experience will show if this feature is useful, although I doubt that it will be one size fits all, as we all have different homes and opinions on what is the ideal comfortable temperature at any given time.
There will be no further changes to this release, so time will tell.
jhjgjHi all, I've had a long weekend, so just catching up in posts! Great feedback everone – keep it coming! 😊
The from speaking to a team member in the Wi-Fi team, the weather API should be getting polled far more frequently than what people are seeing on here. I'll contact people directly to ask for MAC addresses if that's ok so we can take a look at why we're seeing the long delays.
Unfortunately how the code is arranged, there is a system wide flag for Eco and a variable for the setpoint of each zone. This means the code has no knowledge of the setpoint before Eco was applied or what it should be after Eco is cancelled or times out. I'll have a look into this but any fix would be time/resource dependent.
If the difference between setpoint and ambient is 1.5C or more we now completely ignore scaling. Between 1.5C & 0.5C we start backing off the demand to the point we're fully scaling again by 0.5C. Where I think load scaling works well is when running in the background with your schedule gradually and efficiently controlling room temperature - it's a bit like the difference of gradually increasing speed on a motorway v.s. being heavy footed on the accelerator.
Below is an example from my home showing load scaling being applied to a scheduled setpoint change, then later me manually overriding the setpoint. You can see the difference in behaviour in the zone's demand and also see how the temperature settles around setpoint with scaling on vs the overshoot with the heavy-footed override behaviour.
graph.jpg
Please bear in mind that load scaling is a learning algorithm. It will learn how to control your environment correctly overtime. If a room sensor is manipulated in a way that doesn't match how the environment reacts, the results will look strange. We also implemented failsafe measures which looks for abnormalities in the heat up ramp based on historical learning. If we detect a room is taking abnormally long to heat up the failsafe will kick in and ask for more from the boiler.
Temperatures under 5C are treated as a frost protection fail safe condition. We decided that it made sense to simplify the control logic and rely purely on our traditional adaptive fuzzy in these conditions. We felt that this would also avoid confusion or doubt that Evo could handle these situations correctly. When the room ambient increases above 5C, load scaling will kick in again, but as previously mentioned, there are built-in failsafes, should the system struggle with load scaling enabled.
As frost protection is effectively a setpoint of 5C, while maintaining 5C, load scaling might apply (if the room temperature is slightly above 5C) but won’t apply when getting up to 5C.
I’m interested in how people will use the new weather features and what deficiencies they see in it. The feedback will help shape how these features work in the future.
Just one question. What happens when Evohome cannot connect to WiFi? One of THE best features of Evohome is the independence from the Internet. We are now blurring those lines. I still believe a local sensor should have been pursued, like it was on the V2 controllers. So is all I flight weather compensation completely abandoned if there is no Outside temperature available. I wouldn't like anything to be left in a state of limbo.
Currently Evo uses internet weather data and therefore the smart weather features are reliant on them. I don't disagree on your desire to de-couple our solution from the internet, but the feature had to be implemented with the timescales and resources available. To produce a new local RAMSES sensor takes a significant investment, which wasn't feasible at this time. This does not rule out the possibility of a future product or further improvements to Evo to support OT sensors in the future.
Posting Permissions