Page 42 of 59 FirstFirst ... 32373839404142434445464752 ... LastLast
Results 411 to 420 of 587

Thread: Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

  1. #411
    Automated Home Jr Member DerekWilliamsUK's Avatar
    Join Date
    Jan 2018
    Posts
    20

    Default

    Quote Originally Posted by DerekWilliamsUK View Post
    At 08:30 this morning my own outside weather station was reporting 16C, as were BBC Weather, Foreca (used by the Microsoft Windows 10 weather app) and Accuweather. So thay ALL AGREED. However my EVO was reporting an outside temperature of only 14C.
    It's now about an hour later (09.25) and EVO is still showing 14C.
    My weather station is now reporting 17C, with BBC Weather and Foreca also reporting 17C. Accuweather is still reporting 16C.
    I will try and keep an eye on this throughout this morning.
    Last edited by DerekWilliamsUK; 23rd August 2020 at 03:06 PM.

  2. #412
    Automated Home Jr Member
    Join Date
    Jan 2018
    Posts
    40

    Default

    Quote Originally Posted by ally153 View Post
    Due to resource and time constraints, all changes to the firmware are local changes only. To bring further integration to the cloud would have required resource and engagement in Wi-Fi, Cloud API and TCC app resource and time, which wasn't feasible at this time for the project.

    <snip>

    Again it all comes down to time, we delivered all that we could with the time we had. Adding anything extra would have slippages in committed dates.
    This makes perfect sense (I would've guessed this, but was just checking), thanks.

    I'm very pleased with the love evohome is getting - keep it up!

  3. #413
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,132

    Default

    Quote Originally Posted by DerekWilliamsUK View Post
    It's now about an hour later (09.25) and EVO is still showing 14C.
    My weather station is now reporting 17C, with BBC Weather and Foreca also reporting 17C. Accuweather has updated, but only to 16C.
    I will try and keep an eye on this throughout this morning.
    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.

  4. #414
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,132

    Default

    Quote Originally Posted by ally153 View Post
    We deliberated this with the UX team, but it was decided to keep the symbol the same. To change the symbol we would have needed to coordinate resource and releases with the app team. Believe it or not, but there are many people who treat 'Boost' as an economy feature - they prefer having a lower setpoint in general and only occasionally 'boost' their temperature when they are feeling particularly cold. We've had that feedback a lot from people who use DT92E as they re-assign their Eco button from a low setpoint to a higher setpoint.
    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 01:04 PM.

  5. #415
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,132

    Default

    I've been using the 19.33 build for a few days now so can comment on some of the below:

    Quote Originally Posted by ally153 View Post
    From your feedback, the key (non heatpump) things we have changed are:
    • Bug fix. Optimisation setpoint issue resolved.
    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.
    • 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
    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.
    • Bug fix. The DHW priority bug where a manual override killed the DHW demand is we believe fixed.
    Seems to be fixed on my system. Thank goodness. That one was really driving me crazy...
    • 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.
    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.

    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.
    • 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.
    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!

    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 ?
    • Spec change. Load scaling disabled in frost protection
    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 ?

    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 01:26 PM.

  6. #416
    Automated Home Jr Member DerekWilliamsUK's Avatar
    Join Date
    Jan 2018
    Posts
    20

    Default

    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.

  7. #417
    Automated Home Legend
    Join Date
    Jan 2015
    Location
    NE UK
    Posts
    1,157

    Default

    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.

  8. #418
    Automated Home Jr Member DerekWilliamsUK's Avatar
    Join Date
    Jan 2018
    Posts
    20

    Default

    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?

  9. #419
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,688

    Default

    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!

  10. #420
    Automated Home Jr Member
    Join Date
    Jan 2018
    Posts
    30

    Default Documentation?

    Quote Originally Posted by ally153 View Post
    Hi all,
    I’m one of the firmware engineers at Resideo (or software elves as AtM would call us) working on the latest updates for the Evotouch platform.

    Sorry for the long delay getting back to all that have been involved in the current beta tests! AtM has been “hellishly busy” and has stopped receiving mail notifications from the forum for some reason. He has asked me to step forward and provide support for the remainder of the beta test.

    We have continued with the development of new features, adding heatpump control and the cooling functionality. There is now a new relay box firmware, it is still a BDR91 and it is backwards compatible, but it can now handle heatpump control and a heat/cool change over function as a new device type within Evo (there are now six possible BDR91 functions in Evo). We have also been listening closely to all the feedback you have given us so far and have implemented some functions to address your comments.

    We would like you views on those improvements if you are willing and would like to push a bug fixed version with the new functionality to all that have previously signed up to the beta test. If you don’t want to be included, please let me know by the beginning of next week.

    From your feedback, the key (non heatpump) things we have changed are:
    • Bug fix. Optimisation setpoint issue resolved.
    • Summer shutdown is now fully integrated into UI, the icon now shows in the zone and the setpoint bar indicates an off state. There are no changes in the control algorithm, this seems to be working well even if people didn’t appreciate or understand it. There will be a small video to explain the operation put on the support pages, but it will probably remain a Marmite function.
    • New feature. The Winter boost now has an offset adjustment, instead of a fixed -10°C offset from current setpoint, the user can now adjust the offset between -30°C to -5°C of setpoint.
    • 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
    • Bug fix. The DHW priority bug where a manual override killed the DHW demand is we believe fixed.
    • 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.
    • 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.
    • Spec change. Load scaling disabled in frost protection
    • Bug fix. Removed the password protection override via the smart features button

    As before, feel free to DM me directly or provide feedback in this post.
    Ally,

    I've lost track of what is actually in the new Beta and the controls we have available.
    Is there a document describing the latest UI and what the new functions (are supposed to) do?

    Thanks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •