Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • CT1
    Automated Home Guru
    • Apr 2016
    • 189

    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.

    Comment

    • Scubajoe
      Automated Home Sr Member
      • Nov 2018
      • 50

      I haven't had the update yet, any chance please?

      Comment

      • DBMandrake
        Automated Home Legend
        • Sep 2014
        • 2361

        Originally posted by paulockenden View Post
        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!
        That's what I found back when I first tried this feature on the first beta.

        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!

        Comment

        • CT1
          Automated Home Guru
          • Apr 2016
          • 189

          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.

          Comment

          • SteveP
            Automated Home Guru
            • Dec 2012
            • 190

            Originally posted by DBMandrake View Post
            That's what I found back when I first tried this feature on the first beta.

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

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              Originally posted by CT1 View Post
              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.
              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; 25 August 2020, 04:42 PM.

              Comment

              • CT1
                Automated Home Guru
                • Apr 2016
                • 189

                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.

                Comment

                • ally153
                  Automated Home Jr Member
                  • Nov 2014
                  • 30

                  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.

                  Originally posted by DBMandrake View Post
                  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.
                  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.

                  Originally posted by DBMandrake View Post
                  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 ?
                  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

                  Originally posted by DBMandrake View Post
                  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 ?
                  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.

                  Originally posted by DBMandrake View Post
                  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)
                  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.

                  Originally posted by CT1 View Post
                  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.
                  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.

                  Comment

                  • bruce_miranda
                    Automated Home Legend
                    • Jul 2014
                    • 2307

                    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.

                    Comment

                    • ally153
                      Automated Home Jr Member
                      • Nov 2014
                      • 30

                      Originally posted by bruce_miranda View Post
                      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.

                      Comment

                      • DBMandrake
                        Automated Home Legend
                        • Sep 2014
                        • 2361

                        Originally posted by ally153 View Post
                        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.

                        [ATTACH=CONFIG]1587[/ATTACH]
                        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.
                        Last edited by DBMandrake; 26 August 2020, 11:16 AM.

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          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.
                          Last edited by DBMandrake; 26 August 2020, 11:29 AM.

                          Comment

                          • bruce_miranda
                            Automated Home Legend
                            • Jul 2014
                            • 2307

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

                            Comment

                            • CT1
                              Automated Home Guru
                              • Apr 2016
                              • 189

                              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.
                              Last edited by CT1; 26 August 2020, 03:05 PM.

                              Comment

                              • bruce_miranda
                                Automated Home Legend
                                • Jul 2014
                                • 2307

                                Originally posted by ally153 View Post
                                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..)

                                Comment

                                Working...
                                X