Last edited by DerekWilliamsUK; 23rd August 2020 at 02:06 PM.
I found the lag on previous firmware versions (beta 1 and the stable versions prior to that) to be approximately 4-6 hours, most easily observed on clear days when the temperature rises rapidly in the morning and falls quickly at dusk.
Nothing seems to have changed in beta 2, although if the lag issues are server side I'm not surprised - I don't think there are any changes between the two beta's relating to outdoor temperature readings.
Fair enough. A very minor point that doesn't bother me but thought I'd mention it seemed a little odd.
However after using Eco/Boost a bit more, I've found a significant usability issue with it relating to manual overrides.
Imagine for a moment that Eco/Boost is active and set to +1C, and a zone is scheduled to 20C - the actual temperature will be 21C.
Now the user tries to set a manual override and goes into the touch interface and sets 22C. When they press OK they return to the home screen to be greeted with a set point of 23C, not the 22C they asked for...
They then go back into the manual override and set it to 22C and they end up with 23C again. Basically the controller is not giving them what they asked for, and I can see this leading to confusion and frustration for some users.
I understand why it's doing this (the Eco/Boost offset is being applied on top of the manual override set point) but I think this is the wrong UI choice. A manual override should always be absolute - if they set 22C it's because they want 22C for that specific zone, not some adjusted value subject to the Eco/Boost setting.
This current behaviour is even worse from an HR92 or a DTS92E than from the controller screen, where you can at least see what's happening.
If you adjust an HR92 to 22C it will initially go to 22C (since it does that locally) and still indicate 22C immediately after setting it however a few minutes later when the set point is synced from the controller back to the HR92 it will change to 23C - not what the user asked for, and keeping in mind that a user who is adjusting an HR92 may be unaware that the system is in Eco/Boost mode. Unless they were the person who enabled the Eco/Boost mode they're likely to think its a malfunction.
On a DTS92E the problem is even worse because as you press the + / - temperature buttons it sends out set point changes in real time for each button press and also polls the controller every few seconds for the current value, as a result it keeps refreshing to the Eco/Boost "adjusted" value, making it very difficult in my example above to actually reduce the temperature because for every few presses on the down button the temperature will jump up by 1C again.
Likewise the iPhone app initially shows the desired override value but will at some point later (much later) refresh to show the Eco/Boost adjusted value.
In my opinion I think it's pretty clear from a good UI perspective that manual override set points should not be affected by the Eco/Boost offset. If you want to override a zone to a specific temperature, that's what it should do, and that would also avoid the UI problems with the HR92/DTS92E/phone apps.
This could in theory be done in one of two ways - either apply the reverse of the Eco/Boost offset when setting an override so that the "base" temperature is offset but the current eco/boost "adjusted" temperature matches what the user asked for, or simply disable the Eco/Boost offset in a zone for the duration of a manual override applying.
The former doesn't seem to be necessary since every time you enter or leave Eco/Boost mode all manual overrides are cancelled anyway.
So the solution seems to be fairly straight forward - disable Eco/Boost offsets for any zone which currently has a manual override applied, for the duration of that override. Problem solved.
Last edited by DBMandrake; 23rd August 2020 at 12:04 PM.
I've been using the 19.33 build for a few days now so can comment on some of the below:
If you mean zone set points temporarily going to 30C during the optimisation period, that seems to be fixed for me - this was happening routinely on my kitchen zone, but strangely, not on any other zone. Haven't seen it since going to 19.33.
This is brilliant and works well with the one priviso of a bit of an unfortunate clash with manual overrides which I documented in my previous post - hopefully this can be fixed as the fix seems quite trivial.• New feature. The ECO function is now adjustable and is call Eco/boost. The range is +3 > -3C default is as the old Eco function at -3C
Seems to be fixed on my system. Thank goodness. That one was really driving me crazy...• Bug fix. The DHW priority bug where a manual override killed the DHW demand is we believe fixed.
Great to see this implemented as a preference setting, and defaulting to off after the update, and I can confirm the off setting is working as expected.• New feature. The DHW priority function is now optional. Upgrading systems already configured with DHW will have DHW priority disabled. This will retain the behaviour existing users will be used to. DHW priority can be setup in the UI as part of Sundial setup or retrospectively in the system parameters. We have evidence that DHW priority is a significant benefit to slow DHW systems.
I really missed the ability to heat hot water and radiators at the same time on my system which is designed to do this and has plenty of oomph to simultaneously heat the cylinder and all radiators.
For those peoples systems where hot water priority is preferable they now have the option to set it in software instead of performing a wiring hack with their relays. Thumbs up.
I can confirm that large manual overrides are negating the load scaling and allowing a 100% boiler demand as expected. My bathroom radiator thanks you. On 19.31 I have been basically unable to heat my bathroom radiator at all in the summer unless I turned up another (unwanted) zone to increase the demand as the load scaling was so aggressive even in "partial" mode. I had forgotten how hot that radiator can get!• Spec change. The advanced load scaling slow response to a ‘manual override in low demand condition in fully optimised systems’ has been addressed. It is now initially off allowing for a ‘normal’ injection of heat and comes back progressively as we near setpoint. This will overshoot as in a standard heating system, but I fully accept it was too aggressive in certain manual override conditions. I also have some nice evidence to support the benefit of load scaling and the effect of the partial disabling of it. Another Marmite feature I expect.
Load scaling seems to be working as before with manual overrides disabled however in this warm weather I can't really analyse the performance of the load scaling very well as there just isn't enough heat demand except a little bit in the mornings.
Load scaling is the most interesting feature to me of the beta releases so I will be watching it closely as the weather cools a bit and the heating actually has some work to do.
From your description it sounds like with a manual override active the load scaling is itself scaled progressively as the set point is neared rather than just switching on/off. Can you elaborate a little on this ?
I haven't checked this yet, however as I was the original reporter of the problem with load scaling preventing frost protection from working would you like me to repeat the same test to verify the fix ?• Spec change. Load scaling disabled in frost protection
Can you elaborate a little on the algorithm so I know what to look for during testing ? Is it just something simple like load scaling is disabled if the measured temperature is below 6C, or a bit more clever ?
Can you confirm whether frost protection should still work with the system in "Heating Off" mode, since the 19.31 beta firmware clamped heat demands from zones where the set point is more than 1.5C below the measured temperature to zero ? (I presume 19.33 still does this, I haven't checked yet)
Last edited by DBMandrake; 23rd August 2020 at 12:26 PM.
It's now about 1PM and EVO is now showing 18C which matches Accuweather on the web.
However, my weather station is now reporting 19C, as are both BBC Weather and Foreca. So for me at least Accuweather is not so accurate.
I guess a 1c difference is not a major issue, BUT I have have seen much bigger differences (+/-4C) between my weather station & EVO in the past, especially in the morning which will screw with the new Smart Cold Weather boost calculation. I have seen this both before and with the beta firmware.
Just thought I would double check mine. It is 08:56 my accurate outside temperature is 13C. Evohome says it is 12C. Using the Dark Sky app it says it is 13C. The Weather App on the iPhone says it is 13C. Evohome is the odd one out. That is usually the case. Sometimes it is 0.5C
I suppose if my boiler and system was linked to outside temperature I would have to have an offset of 1C set in the system to allow for the inaccuracy.
It's 10.30 AM and my Weather Station reports 17.2c
BBC Weather = 17C
Foreca.com = 17C
Accuweather.com =16C
But my Evo system is showing Outside Temp = 15C.
Clearly there is a reporting lag. So how often does the Evo system poll for a weather data update from Accuweather via the Honeywell API?
In a way it's going to be worse in the evenings when it's actually getting cold out there but Evohome thinks it's still early-afternoon temperatures.
It'll save gas, of course, but only because your house is cold!