What would you like to see in evohome? (have your say)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • paulockenden
    Automated Home Legend
    • Apr 2015
    • 1719

    Originally posted by DBMandrake View Post
    The only way it could be applied on a per zone basis would be to inform the HR92's of the outside temperature, and then what would they do with this information ?
    At the moment they build a very simple relationship of how much boiler output is needed to raise a room by a given amount. I'm not even sure it builds an internal graph - it's probably just a single parameter - very simple. That's why pissing with the flow temp is going to break things big time. Have you ever tried adjusting your boiler flow rate then monitoring the zone temp graphs for the next week or so? It isn't pretty.

    I'm suggesting that the HR93 (or whatever) could be given the ability to auto-generate proper compensation curves. So in the way that Evohome moves overall heating control from system to zone level, the same principle could be applied to weather compensation.

    P.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      Originally posted by paulockenden View Post
      At the moment they build a very simple relationship of how much boiler output is needed to raise a room by a given amount. I'm not even sure it builds an internal graph - it's probably just a single parameter - very simple.
      They're a lot smarter than that...

      As far as I can tell (I can only observe and analyse the behaviour, not look at the code...) each HR92 is a full PID (proportional/integral/differential) controller, with automatic self tuning of at the very least the differential term. (which controls overshoot tendency)

      By adjusting the differential term it can compensate for overshoot induced by thermal lag of the radiator etc - when it learns not to overshoot it is increasing the differential term so that it starts closing the valve sooner, before the target is reached when the temperature is rising quickly, allow it to "coast" to the target instead of overshooting it.

      The important thing to keep in mind is that this compensation has a limited range of effectiveness and there will be limits on how much it will tune this parameter - if the temperature rises too quickly and continues to rise too far after the radiator is closed (as it will when the flow temperature is too high) then it will be unable to compensate so there will be an overshoot.

      The integral term controls how quickly it adjusts for a change in offset error - offset error being that a different valve position is required to get the same measured room temperature when the heat loss of the room changes. I can't tell whether the integral term is self tuned or not - it may well be fixed.

      The proportional term mainly controls how far the valve will turn immediately in response to a change in set point. This may also be fixed and not self tuned - although it seems to differ between stroke 0 and stroke 1.

      I'm not sure how familiar you are with PID controllers but if you've not looked into them before you'll probably find it interesting reading and it will help to explain how the HR92's behave.

      (Pretty heavy on the maths, but this is quite good: https://www.allaboutcircuits.com/tec...using-matlabs/ )
      That's why pissing with the flow temp is going to break things big time. Have you ever tried adjusting your boiler flow rate then monitoring the zone temp graphs for the next week or so? It isn't pretty.
      I think I explained that adequately in my previous post - you're introducing a large step change which will of course cause a temporary instability until the system settles down. (Look up step response of a PID controller)

      If the flow temperature adjustments are small, smooth and inversely proportional to the actual heat loss of the building it won't cause a temporary instability, it just becomes a system wide "feed forward" loop outside of the individual feedback loops of the individual zones.
      I'm suggesting that the HR93 (or whatever) could be given the ability to auto-generate proper compensation curves. So in the way that Evohome moves overall heating control from system to zone level, the same principle could be applied to weather compensation.
      And my argument is that it's not that the HR92's can't learn properly - as self tuning PID controllers they are perfectly well equipped to learn the changes that result from outside temperature changes, the issues is on the control side not the input side - the valve that they operate and the thermal mass of a radiator conspire to make it impossible for the HR92 to smoothly and accurately control the heat into the room with excessive flow temperature regardless of what information they have available at the input side or clever algorithm they might employ. The system becomes inherently unstable, and that's why you see large overshoots and/or ongoing oscillation.
      Last edited by DBMandrake; 30 June 2017, 07:21 PM.

      Comment

      • paulockenden
        Automated Home Legend
        • Apr 2015
        • 1719

        But for weather comp to work properly it wouldn't be small changes would it? We live in the UK. It can be low twenties one day, ten degrees the next!

        If you're only going to make tweaks so small that the TPI control in the HR92 will cope then I wonder whether it's worth bothering at all? After all, at that micro level TPI will itself adjust for external conditions, as the Honeywell dudes have told us so many times.

        I'm envisioning something more radical. And like I said, you'll bu&&er things up big time if you make radical changes to the boiler output / flow temp.

        I think we're trying to achieve different things!

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          Originally posted by paulockenden View Post
          But for weather comp to work properly it wouldn't be small changes would it? We live in the UK. It can be low twenties one day, ten degrees the next!
          You don't just change the flow temperature one degree for every degree of outside temperature change though.

          That's where the slope adjustment comes in. See page 4 here for an example:



          The slope required basically depends on how well insulated your house is, in a well insulated house the slope will be pretty flat so it will take several degrees of outside temperature change to change the flow temperature by 1 degree. Or if you have a badly insulated house you'd need a higher slope that affects the flow temperature more.

          So in the well insulated example outside temperature going from 20 degrees to 5 degrees might only affect the flow temperature by 5 degrees for example. By adjusting the slope and offset you can emulate the change that you would have manually made previously.
          If you're only going to make tweaks so small that the TPI control in the HR92 will cope then I wonder whether it's worth bothering at all? After all, at that micro level TPI will itself adjust for external conditions, as the Honeywell dudes have told us so many times.
          Small changes is probably the wrong way for me to describe it. What I'm trying to say is that the changes are smooth, continuously variable, and directly proportional to the conditions rather than being a step change made manually and semi-arbitrarily by a person who has decided after a few weeks that it's finally too cold for their summer flow temperature to do the job or vica versa.

          The step response of most feedback systems is not nearly as stable as the response to a smoothly varying input signal, so you're unlikely to see the temporary overshoots after a manual change of flow temperature that you're talking about.

          Anyway I've probably said all I can on the matter - I'm not holding my breath for Honeywell to implement weather compensation as it seems to go against their mantra with the Evohome system ("it doesn't need it" - but if it doesn't need it why do we still need to adjust our flow temperature between summer and winter for optimal performance...) but if I ever get a boiler with OpenTherm support I'll either be choosing one that does support weather compensation and opentherm working properly together (could be tricky based on the discussion in other threads!!) or implementing my own man-in-the-middle OpenTherm decoder and encoder where I can apply my own maximum flow temperature and weather compensation in some custom coding of my own.

          Comment

          • blowlamp
            Automated Home Sr Member
            • Apr 2017
            • 98

            Originally posted by DBMandrake View Post
            You don't just change the flow temperature one degree for every degree of outside temperature change though.

            That's where the slope adjustment comes in. See page 4 here for an example:



            The slope required basically depends on how well insulated your house is, in a well insulated house the slope will be pretty flat so it will take several degrees of outside temperature change to change the flow temperature by 1 degree. Or if you have a badly insulated house you'd need a higher slope that affects the flow temperature more.

            So in the well insulated example outside temperature going from 20 degrees to 5 degrees might only affect the flow temperature by 5 degrees for example. By adjusting the slope and offset you can emulate the change that you would have manually made previously.

            Small changes is probably the wrong way for me to describe it. What I'm trying to say is that the changes are smooth, continuously variable, and directly proportional to the conditions rather than being a step change made manually and semi-arbitrarily by a person who has decided after a few weeks that it's finally too cold for their summer flow temperature to do the job or vica versa.

            The step response of most feedback systems is not nearly as stable as the response to a smoothly varying input signal, so you're unlikely to see the temporary overshoots after a manual change of flow temperature that you're talking about.

            Anyway I've probably said all I can on the matter - I'm not holding my breath for Honeywell to implement weather compensation as it seems to go against their mantra with the Evohome system ("it doesn't need it" - but if it doesn't need it why do we still need to adjust our flow temperature between summer and winter for optimal performance...) but if I ever get a boiler with OpenTherm support I'll either be choosing one that does support weather compensation and opentherm working properly together (could be tricky based on the discussion in other threads!!) or implementing my own man-in-the-middle OpenTherm decoder and encoder where I can apply my own maximum flow temperature and weather compensation in some custom coding of my own.


            It's not tricky at all, our Intergas boiler uses OpenTherm and weather compensation together just fine - all controlled via a competitor's (Remeha) thermostat.

            Pegler I-Temp TRV's regulate the radiators to our satisfaction despite having no feedback to the boiler, so obviously this means that individual zones can't activate the boiler either. However, room temperatures are still well controlled through the varying seasons, which makes me think that weather compensation would work if incorporated into Evohome and might prove a benefit in reducing some of the excessively high flow temperatures users report under OpenTherm, although I do still believe Honeywell's Evohome implementation of OpenTherm is below par.


            Martin.

            Comment

            • dty
              Automated Home Ninja
              • Aug 2016
              • 489

              * A range extender for larger properties
              * An API on the controller for monitoring/home automation
              * More than 12 zones (I might have already mentioned that)
              * Separation of schedules and zones (so I can make a "downstairs" schedule and apply it to 5 zones)
              * Saved schedules so I can easily swap a summer and winter schedule, for example

              Comment

              • gordonb3
                Automated Home Ninja
                • Dec 2016
                • 273

                Range extender would be welcome indeed. Not so much because my home is big but there is a lot of metal in the floors and I tend to lose communication from time to time with units that are two stories up.

                Schedule save/restore is actually quite easy. I have an example of it in my c++ evohomeclient project.

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  The question is whether a "range extender" is even possible with the current over the air protocol design. I'd suggest that if it were, there would already be one available...

                  Some sort of store and forward approach is the only thing that would work, but receiving devices may be confused by the duplicate messages, and more than one "range extender" wouldn't be possible without a way for them to identify each other so they don't repeat each others repeats endlessly...

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    Well, it's radio so it's bound to have echo's at some point and hopefully some mechanism to filter messages that should not be there. My guess would be that normal usage without a repeater may see duplicate messages anyway if somehow an ACK gets lost in the lower level protocol.

                    Comment

                    • DBMandrake
                      Automated Home Legend
                      • Sep 2014
                      • 2361

                      Originally posted by gordonb3 View Post
                      Well, it's radio so it's bound to have echo's at some point and hopefully some mechanism to filter messages that should not be there. My guess would be that normal usage without a repeater may see duplicate messages anyway if somehow an ACK gets lost in the lower level protocol.
                      There's a major difference between an "echo" caused by multi-path propagation and a re-transmission by a repeater. Reflections would arrive within microseconds and overlap the original signal in time, re-transmissions would be sent milliseconds or tens of milliseconds later after the original signal finished. Many orders of magnitude difference in delay.

                      If all the communications are idempotent and don't expect acknowledgements then re-transmissions a fraction of a second later would probably not do any harm, and whilst we know that many of the communications fall into this category (such as temperature sensors sending temperature measurements) not all may - there may be some commands that expect immediate responses such as the binding process, that would be confused by receiving a second reply.

                      Also if the protocol itself doesn't have knowledge of repeaters (such as a "repeated by xxx" field) then trying to add more than one repeater would cause a loop with each repeater repeating what the other repeater sent.

                      Yet another issue - how would your repeater know which devices belonged to your Evohome system and not your neighbours ? Do you want a neighbours repeater intercepting and re-transmitting your system's packets ? What if you and your neighbour both had a repeater within range of each other - now you have a loop.

                      My opinion from what I've seen of the protocol is that passive or "dumb" repeating of message packets would work after a fashion but cause issues with some aspects of the system such as the binding process. The only way to do it properly within the constraints of the current protocol might be to make the repeater a gateway where devices on one side of the gateway must use the gateway to communicate with devices on the other side of it. EG devices must bind to the repeater.
                      Last edited by DBMandrake; 11 July 2017, 01:59 PM.

                      Comment

                      • paulockenden
                        Automated Home Legend
                        • Apr 2015
                        • 1719

                        DanD was working on repeater functionality.

                        With his system you bound the repeated devices to the repeater. And then bound the repeater to Evohome.

                        Not sure how far he got....

                        P.

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          Originally posted by paulockenden View Post
                          DanD was working on repeater functionality.

                          With his system you bound the repeated devices to the repeater. And then bound the repeater to Evohome.
                          I think interposing it as a man in the middle like that instead of a dumb repeater is the only way to do it properly. It could make the binding process quite complicated though, and the smart repeater would have to have specific knowledge of each device type to know how to bind it and what kind of device it is.

                          Comment

                          • paulockenden
                            Automated Home Legend
                            • Apr 2015
                            • 1719

                            Yup. So more like an intelligent proxy than a dumb repeater.

                            Such a shame that meshing wasn't built in from the start (only for the mains powered devices, obviously. The same way Zigbee and ZWave devices do it). That way you could just fire up a BDR91 or whatever (with nothing attached) to fill any voids in the network.

                            P.

                            Comment

                            • dty
                              Automated Home Ninja
                              • Aug 2016
                              • 489

                              Originally posted by paulockenden View Post
                              Yup. So more like an intelligent proxy than a dumb repeater.

                              Such a shame that meshing wasn't built in from the start (only for the mains powered devices, obviously. The same way Zigbee and ZWave devices do it). That way you could just fire up a BDR91 or whatever (with nothing attached) to fill any voids in the network.

                              P.
                              Or, better yet, just build it on top of one of those networks, then we could just leverage existing repeaters, expertise, etc.

                              Comment

                              • Kevin
                                Moderator
                                • Jan 2004
                                • 558

                                I cover my property with two controllers, because of both range and #zones. I am (now) generally happy with this but I would like the ability to choose which zones are displayed on which controller. This would require the controllers to communicate with each other over Ethernet. In some cases I would like the same zone displayed on both controllers.

                                Having more displayable zones I'm not sure about, maybe it will work or possibly just be confusing.

                                As my controllers are upstairs/downstairs one end/the other it is very physically inconvenient to have to use both. Also which zones are on which is not intuitive as it isn't a logical upstairs/downstairs separation. Obviously the app interface partially solves this but direct controller/controller awareness would be much more user friendly and aspects of system wide control better.
                                Last edited by Kevin; 12 July 2017, 12:58 AM.

                                Comment

                                Working...
                                X