Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • kevinsmart
    Automated Home Ninja
    • Sep 2018
    • 257

    Originally posted by ally153 View Post
    The weather feature uses internet data, for me the weather data is actually fairly spot on with the actual outside temperature, but I appreciate that other user's mileage may vary. Due to time constraints we weren't able to implement using the OT sensor value. From experience we've found that different manufacturers have interpreted the specs and implemented OT differently and we wanted a robust solution that didn't have compatibility issues. Although the actual amount of code needed would probably be trivial the ground work to architect a robust solution takes longer.
    Why not just make reading from an OT sensor versus Internet configurable?

    It’s easy to see whether the displayed temperature is correct.

    As it stands Accuweather is inaccurate for me and my OT sensor is very close to my weather station reading (shared with Wunderground).

    Comment

    • ally153
      Automated Home Jr Member
      • Nov 2014
      • 30

      Originally posted by zxdavb View Post
      @ally153 Can the team confirm if these new features - specifically the eco/boost offset - can be configured via the Web API. An example use-case (via a home automation platform using, e.g. https://github.com/watchforstock/evohome-client): the further I get from home (via geofencing / presence detection), the more the eco is dropped from 0.5 to 3.0.
      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.

      Originally posted by DBMandrake View Post
      Mine has updated to the new version and I have some feedback - the new Eco/Boost function (loving it) still uses the Euro symbol of the old Eco function. (both in the quick action button and zone squares)
      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.

      Originally posted by bruce_miranda View Post
      Also does Evohome use the RealFeel for it's weather compensation or the actual temperature?
      The thermostat uses a Resideo specific veneer API for fetching weather data. This allows the company to switch weather providers transparently without impact to devices out in the field. RealFeel is a specific Accuweather feature which other services don't offer, so we use the universally available actual temperature.

      Originally posted by kevinsmart View Post
      Why not just make reading from an OT sensor versus Internet configurable?

      It’s easy to see whether the displayed temperature is correct.

      As it stands Accuweather is inaccurate for me and my OT sensor is very close to my weather station reading (shared with Wunderground).
      If we implemented something which goes wrong in certain (sometimes obscure) conditions, we wouldn't be thanked for that. Unfortunately it wouldn't matter if we provided an option to using some other data source - we offered the feature, so it's expected to work 100%, switching back to an 'inferior' set of data would be disappointing.

      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.

      Comment

      • DBMandrake
        Automated Home Legend
        • Sep 2014
        • 2361

        Originally posted by kevinsmart View Post
        Why not just make reading from an OT sensor versus Internet configurable?

        It’s easy to see whether the displayed temperature is correct.

        As it stands Accuweather is inaccurate for me and my OT sensor is very close to my weather station reading (shared with Wunderground).
        I'm still seeing lag and inaccuracy in the reported outside temperature, and it doesn't even agree with Accuweather.

        The Evotouch is reporting 14C, Accuweather is reporting 16C for my location, my own weather station is reporting 18.6C. Hmm...

        Comment

        • DerekWilliamsUK
          Automated Home Jr Member
          • Jan 2018
          • 32

          I am also seeing a noticeable time lag with the EVO displayed outside temperature for my location (Bracknell, UK).

          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.

          How often does my EVO poll for a weather update?
          Does it get this data direct from Accuweather (via the Honeywell API)?
          How does the process actually work?
          Where is this 'delay' coming from?

          Comment

          • G4RHL
            Automated Home Legend
            • Jan 2015
            • 1580

            Originally posted by DerekWilliamsUK View Post
            I am also seeing a noticeable time lag with the EVO displayed outside temperature for my location (Bracknell, UK).

            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.

            How often does my EVO poll for a weather update?
            Does it get this data direct from Accuweather (via the Honeywell API)?
            How does the process actually work?
            Where is this 'delay' coming from?
            I am not on the beta version but I note that mostly the outside temperature shown in the Evohome app is about 0.5C above what it actually is. An understandable margin of error. Sometimes it goes the other way but usually about a 0.5C difference.

            Comment

            • DerekWilliamsUK
              Automated Home Jr Member
              • Jan 2018
              • 32

              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; 23 August 2020, 02:06 PM.

              Comment

              • zxdavb
                Automated Home Guru
                • Jan 2018
                • 106

                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!

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  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.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    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; 23 August 2020, 12:04 PM.

                    Comment

                    • DBMandrake
                      Automated Home Legend
                      • Sep 2014
                      • 2361

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

                      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; 23 August 2020, 12:26 PM.

                      Comment

                      • DerekWilliamsUK
                        Automated Home Jr Member
                        • Jan 2018
                        • 32

                        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.

                        Comment

                        • G4RHL
                          Automated Home Legend
                          • Jan 2015
                          • 1580

                          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.

                          Comment

                          • DerekWilliamsUK
                            Automated Home Jr Member
                            • Jan 2018
                            • 32

                            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?

                            Comment

                            • paulockenden
                              Automated Home Legend
                              • Apr 2015
                              • 1719

                              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!

                              Comment

                              • petep
                                Automated Home Sr Member
                                • Jan 2018
                                • 57

                                Documentation?

                                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

                                Comment

                                Working...
                                X