Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

[DBMandrake]

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.

As far as I can see the code doesn't need to know whether there was a manual override set before before Eco mode was enabled (and therefore be trying to restore anything later) because cancelling Eco mode already cancels all manual set point overrides and goes back to the scheduled temperature (follow schedule mode) anyway - just like every other quick action change. So there's nothing special for it to do.

So any manual override made during Eco/Boost can just be set as is to the desired temperature, then when Eco/Boost mode is cancelled or timed out, the set point override is cancelled anyway. And if the set point override expires first before Eco/Boost is cancelled it just reverts to follow schedule with Eco/Boost override applied to the scheduled temperature - as it does now.

The way it tries to add the Eco/Boost offset on top of manual overrides is quite a significant problem IMHO, there's going to be a few very puzzled people when they try to apply manual overrides with Eco/Boost set and find that it is "fighting" them. It makes getting the desired manual override a bit of a chore even when you do understand what's going on.

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.

Perfect - that's pretty much exactly how I hoped it would work so excellent job there.

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.

Attachment 1587

Agreed. I saw similar improvements in my graphs this spring with 19.31. Load scaling is great for warmer weather with light demands (I no longer have to manually turn down my flow temperature in summer) and also schedules where the house may be in equilibrium for a few hours and then a zone like a bedroom is scheduled to come on - with no load scaling that bedroom would bring the boiler demand instantly to 100% and remain there for perhaps half an hour until the zone started to approach the set point, this would inevitably cause uncomfortable overshoots in other rooms like the Living room that were previously in a nice equilibrium state as those rooms were not expecting a sudden step change in flow temperature. I noticed this a lot last winter.

Load scaling V1 (in 19.31) solved this problem nicely and pretty much did away with schedule related overshoots in most of my rooms this spring, (some rooms like the bathroom are irredeemable due to towels over the sensor etc) but then introduced the issue that I couldn't get any heat in summer from normally low demand zones like the bathroom unless it could piggyback on the demand from other zones. I could literally turn it up 5C above the current temperature and wait for an hour and nothing would happen because the 100% demand was being scaled down to something like 5%. (Even on partial mode!)

I think the new behaviour in 19.33 is a good compromise and will allow me to leave load scaling enabled, also I would recommend others give load scaling a try.

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.

Ok that sounds good. My test was quite simple - attach an HR92 to a spare valve body and put it in the freezer long enough to get the sensor below 5C and monitor the heat demand generated. This previously failed with load scaling enabled, (the load was scaled down to below 11% thus didn't meet the minimum on-time required to fire the boiler) but worked with load scaling off. If I get a chance I'll repeat the same test with load scaling left on.

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.

It's great to see some feedback being taken on board - 19.33 feels really solid to me (manual override in eco/boost mode aside) and many of the new features since the last stable release are genuinely useful, like load scaling, the option to enable/disable hot water priority etc.

After a long time with fairly minimal updates (I've had my system for 5 years) it does feel like the software is moving forward a bit.

[DBMandrake]

One thing I forgot that perhaps bears mentioning again is that 19.31 still had the issue (present for the 5 years I've had mine across all software versions) with not charging the controller batteries properly if the device is always on the stand. I'm not sure if this issue is on your radar or not ?

I keep mine permanently on the wall mount and very rarely if ever lift it off unless I'm doing some testing. So it can easily go for a month or two or more without being removed from mains power. What seems to happen is once the batteries are "charged", if the device is never removed from the stand the batteries are never topped up again.

NiMH batteries do have a significant self discharge rate and this means after it has been sitting on the wall stand for about 3-4 months the batteries are essentially nearly completely discharged. I fitted brand new NiMH batteries back at the start of the 19.31 beta period as the originals were getting on 4 1/2 years old by then, and ensured that the controller did a full initial charge - which took it something like 6-10 hours.

When I updated to 19.33 recently I took it off the stand for the first time in months to do some testing and the battery indicator was immediately low and within 5 minutes I had the big red please return the device to the stand warning covering the entire screen.

So after a full charge and about 4 months sitting continuously powered on the stand it only had about 5 minutes runtime until the low battery warning instead of the approx 3-4 hours I would normally get on battery. The batteries themselves are fine and only about 6 months old, and I used to see the same behaviour with the original batteries.

It seems the charging algorithm needs a tweak to periodically give the battery a bit of a top up charge or at least test it when it remains on the wall for a long time and is not running from batteries.

I know a lot of other forum members have reported this same quirk, so definitely not just my unit.

[bruce_miranda]

So is all weather compensation abandoned if the Internet weather feed cannot be retrieved.

[CT1]

Bruce Hopefully weather compensation would be abandoned if there is no feed, as the alternative would be to compensate for the last received data which could be significantly out of date if you lost internet connection for a prolonged period.

I wholeheartedly agree with DBM that it is well past time that the battery management issue for the controller was addressed.

[bruce_miranda]

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.

You had one (in fact I did too!) and it worked on the V2 controllers. It was just stupidly expensive. Bring that back at a decent price, I am sure the functionality is already in your code base. Like so many other things (cough..)

[CT1]

You had one (in fact I did too!) and it worked on the V2 controllers. It was just stupidly expensive. Bring that back at a decent price, I am sure the functionality is already in your code base. Like so many other things (cough..)

An external sensor could help some people, but not every house would have a suitable location for a sensor that was out of the sun and out of the wind, eg terraced house could struggle. Also it would not deal with the problem of some rooms having high solar gain while others have none.

[DBMandrake]

So is all weather compensation abandoned if the Internet weather feed cannot be retrieved.

If you disconnect the WiFi connection you'll see that all smart features that rely on an outside temperature reading either disable themselves or magically vanish from the UI altogether. (The disappearing act in the UI caught me by surprise the first time)

Whether they gracefully fall back if the device still has a WiFi connection but just has difficulty reaching the servers for a period of time or keep using stale data is another question. I'm sure if you wanted to you could try firewalling the Evotouch's internet connection to see what happened.

[bruce_miranda]

An external sensor could help some people, but not every house would have a suitable location for a sensor that was out of the sun and out of the wind, eg terraced house could struggle. Also it would not deal with the problem of some rooms having high solar gain while others have none.

Your choices are : An internet weather feed for your entire city/town. A local sensor on your house that might not have a great location.

[bruce_miranda]

If you disconnect the WiFi connection you'll see that all smart features that rely on an outside temperature reading either disable themselves or magically vanish from the UI altogether. (The disappearing act in the UI caught me by surprise the first time)

Whether they gracefully fall back if the device still has a WiFi connection but just has difficulty reaching the servers for a period of time or keep using stale data is another question. I'm sure if you wanted to you could try firewalling the Evotouch's internet connection to see what happened.

So lets say Cold Boost was in play and the Wifi drops. Does the set point drop as though Cold Boost was disabled. Or will the Cold Boost set point still remain. I understand that weather compensation functions might not start if there is no WiFi. My question was, having started, what happens if the WiFi drops.

[CT1]

Your choices are : An internet weather feed for your entire city/town. A local sensor on your house that might not have a great location.

I am fortunate to have a good location for my existing outside temperature monitor, but I doubt that temperatue compensation could cope with the significant solar gain that I get in some rooms, even in the depths of winter. I will be very interested to see how you pioneers get on, but until then this feature will stay disabled.