OpenTherm control behaviour

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • HenGus
    Automated Home Legend
    • May 2014
    • 1001

    #91
    One of the main selling points of Opentherm is that it should take some of the bumps out of the road; i.e., less cycling of the boiler. As I have asked for before, it would be extremely helpful if someone from Honeywell could explain how they expect Evohome/Opentherm control to work. I am afraid terms like Honeywell Fuzzy Logic are meaningless to most home users (well at least to me).

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #92
      Originally posted by dty View Post
      The interesting thing here will be whether the OT bridge is just a relatively dumb protocol converter (i.e. radio <-> OT) and the brains of the protocol stuff is in the controller, or the brains is in the OT bridge. If *I* were designing it, I would go with the former which would allow changes to the protocol implementation to be done with a controller firmware upgrade. But if it's the latter, then it will only be "fixable" (assuming Honeywell deem it to be an issue on their side and worthy of fixing) by replacing OT bridges - and I doubt Honeywell will do that.
      The problem at hand only affects the translation between "heat demand" and requested boiler flow temperature.

      I think it was DanD, who recently added support for monitoring the communication from the controller to the OpenTherm bridge in Domoticz, that found that the Evotouch controller does not send a flow temperature to the OpenTherm bridge, but simply requests a percentage heat demand, (0 to 200 as an integer where 200 is 100%) exactly like it does with a BDR91. (also an integer from 0 to 200 representing a percentage demand)

      With a BDR91 the percentage demand gives you your TPI duty cycle - 30% (represented by the integer 60 sent in the protocol) means it would be on for 3 minutes in every 10 minute period, assuming the default 6 cycles per hour.

      The OpenTherm bridge appears to simply convert this percentage into a scaled flow temperature, where 100% is 90 degrees (I think) and 1% is a very low temperature. (10 degrees I think) Any heat demand above 0% triggers the flame on option in the protocol but if the requested temperature is really low (10 degrees) the boiler would not actually turn the flame on because the flow is unlikely to ever get that cold.

      Flow temperatures for in between heat demands are linearly interpolated - eg a demand of 50% would be half way between 10 and 90 degrees, or about 50 degrees. So the Evotouch doesn't deal directly in flow temperatures, however as long as the mapping between percentage heat demand and requested flow temperature in the OpenTherm bridge is known and fixed (which I believe it is) then the controller could effectively ask for a certain flow temperature (or set a maximum limit in degrees C) by knowing what percentage demand would be translated to that desired temperature by the fixed translation in the OpenTherm bridge.

      If that's the case (someone with both Domoticz and OpenTherm monitoring facilities would need to confirm that translation is fixed) then it should be possible with just a firmware update for the controller to have a maximum flow temperature setting in the system configuration which works by setting a maximum heat demand requested from the OpenTherm bridge.

      Furthermore, it would be possible if the outside temperature is known, to provide for weather compensation in the Evotouch software where that maximum could be varied automatically in relation to outdoor temperature and the configured weather compensation slope and offset. Since the device is internet connected and knows your home address it wouldn't even be necessary to have an outdoor sensor - an online weather report for your location would be accurate enough for the purposes of weather compensation.

      I would love to see customisable maximum flow temperature and the option for weather compensation in the controller firmware for those using the OpenTherm bridge. Another missed opportunity at the moment!
      Last edited by DBMandrake; 27 April 2017, 04:26 PM.

      Comment

      • bruce_miranda
        Automated Home Legend
        • Jul 2014
        • 2307

        #93
        Given the radio comms that we can see between the controller and the OT bridge, it appears that the brains are in the OT bridge, unfortunately. The lack of being able to introduce features to devices was evident with the previous Mk2 and RFG100, where the RFG100 would receive new updates but the controller couldn't. The OT bridge doesn't even have a USB port!

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          #94
          Originally posted by HenGus View Post
          One of the main selling points of Opentherm is that it should take some of the bumps out of the road; i.e., less cycling of the boiler. As I have asked for before, it would be extremely helpful if someone from Honeywell could explain how they expect Evohome/Opentherm control to work. I am afraid terms like Honeywell Fuzzy Logic are meaningless to most home users (well at least to me).
          If you see my description above, the only real difference is that a BDR91 translates the heat demand into an on/off duty cycle, and the OpenTherm bridge translates the heat demand into a specific flow temperature.

          The main advantage of course is that asking for a specific, continuously variable flow temperature gives a lot smoother and more precise control than trying to crudely control the average flow temperature by cycling the boiler on and off, where in the on state the boiler is going flat out trying to reach its high preset flow temperature. More efficient too, because it allows the boiler to modulate the flame down to reach a low kW output rather than full flame for a few minutes then off for a few minutes.

          There are other advantages as well, like the elimination of minimum on time - minimum on time can cause rooms to dip quite a bit under their set temperature before there is enough heat demand (10% for a one minute minimum on time) to fire the boiler at all - I notice that in warmer weather especially when only one room needs heating.

          Another example is that TPI is slow to react to small changes in heat demand - if you need to go from 20% to 40% heat demand you may have to wait as much as a full 10 minute cycle before the average flow temperature increases above what it was in the previous 10 minute cycle. With OpenTherm a new flow temperature can be requested and actioned immediately, with the boiler achieving the change very quickly. (Probably under a minute or two) This should result in faster system response times when you make small changes like bumping a room up half a degree. (which takes forever to get a reaction with a BDR91, if system demand is currently very low and boiler duty cycle is low)

          As for how it is programmed to work - if any zone is at least 1.5 degrees below its set point there will be a maximum heat demand, which will translate to continuously on for a BDR91 and maximum allowed flow temperature with OpenTherm. If all zones are within 1.5 degrees of their set points (and/or some are over their set points) then the flow temperature should be less.

          In theory under constant conditions (the same scheduled temperatures for a while) it should stabilise such that the flow temperature is the minimum temperature that can sustain the room with the highest heat requirements. With light demands (such as one bedroom radiator at 17 at night) the system will try to open the radiator valve wide but throttle the flow temperature way down, in preference to a higher flow temperature and a mostly closed valve, which would be inefficient as most of the flow would get shunted through the ABV.
          Last edited by DBMandrake; 27 April 2017, 04:25 PM.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #95
            Originally posted by bruce_miranda View Post
            Given the radio comms that we can see between the controller and the OT bridge, it appears that the brains are in the OT bridge, unfortunately. The lack of being able to introduce features to devices was evident with the previous Mk2 and RFG100, where the RFG100 would receive new updates but the controller couldn't. The OT bridge doesn't even have a USB port!
            What missing features does it have apart from being able to set a maximum flow temperature from the controller ? I can't see any reason that can't be implemented as a controller firmware update, as described above.

            Comment

            • dty
              Automated Home Ninja
              • Aug 2016
              • 489

              #96
              Originally posted by DBMandrake View Post
              As for how it is programmed to work - if any zone is at least 1.5 degrees below its set point there will be a maximum heat demand, which will translate to continuously on for a BDR91 and maximum allowed flow temperature with OpenTherm. If all zones are within 1.5 degrees of their set points (and/or some are over their set points) then the flow temperature should be less.
              I was going to write a separate post about this, and probably still will... but since you brought it up...

              I have a room which had been allowed to get cold. Today, I set it back to its normal temperature. It needed to recover about 5C or so. The boiler only ran with a 25% duty cycle according to my Domoticz data. It was on for 5 minutes, off for 15, throughout the day.

              That doesn't seem right to me.

              Comment

              • HenGus
                Automated Home Legend
                • May 2014
                • 1001

                #97
                Thanks @ DBMandrake for such a complete and helpful explanation. Your penultimate paragraph helps explain what I am seeing. With 12 zones, it seems that there is always one that may be outwith the 1.5C set temperature - particularly, when zone target temperatures are changing. It follows that it can take some time for the return flow temperature to drop below 60C. I can well see why a very high boiler flow temperature could result in boiler cycling as described in an earlier post. As far as I can tell, this hasn't been an issue for me with about 5 zones and 12 radiators in use (that is, zones with target temperatures higher than ambient).

                It follows that my installer could well be right when he suggested that a big differential between the set temperatures across the zones might lead to Opentherm system/boiler inefficiencies. It is clear that I will have to give a lot more thought to my zoning/set temperatures for the coming Winter.

                Every Evohome day is a school day.

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  #98
                  Originally posted by dty View Post
                  I was going to write a separate post about this, and probably still will... but since you brought it up...

                  I have a room which had been allowed to get cold. Today, I set it back to its normal temperature. It needed to recover about 5C or so. The boiler only ran with a 25% duty cycle according to my Domoticz data. It was on for 5 minutes, off for 15, throughout the day.

                  That doesn't seem right to me.
                  No that's not working right. It should run at 100% with a 5 degree shortfall. How many devices are in the zone ? Just one HR92 ?

                  If so I'd give the HR92 a reboot. There have been rare reports on here of HR92's not sending/updating their heat demand to the controller even though they adjust the radiator valve correctly. I've had it happen to me once in my bathroom - turning the HR92 up a few degrees opened the valve and reported the set point change to the controller but didn't bring the boiler relay on.

                  Tried turning it up and down a few times, no change. Rebooted the HR92 and it was back to normal.

                  Comment

                  • dty
                    Automated Home Ninja
                    • Aug 2016
                    • 489

                    #99
                    Originally posted by DBMandrake View Post
                    No that's not working right. It should run at 100% with a 5 degree shortfall. How many devices are in the zone ? Just one HR92 ?

                    If so I'd give the HR92 a reboot. There have been rare reports on here of HR92's not sending/updating their heat demand to the controller even though they adjust the radiator valve correctly. I've had it happen to me once in my bathroom - turning the HR92 up a few degrees opened the valve and reported the set point change to the controller but didn't bring the boiler relay on.

                    Tried turning it up and down a few times, no change. Rebooted the HR92 and it was back to normal.
                    Two HR92s and a Y87RF. When I said "allowed to get cold", what I meant was "something else isn't right but I don't think it's relevant to what I'm about to say"... but maybe it is.

                    When I discovered the coldness today, both HR92s were showing 101 (yes, 101) on parameter 10 (and Domoticz was showing 202, as expected). Removing the HR92s showed that the valves were pretty much fully open. But no heat was getting to the radiators. I increased my pump speed and that seemed to fix it. It's a very large house with very meandering pipework, so it's possible there wasn't enough pump head.

                    But... that doesn't explain why the room wouldn't warm up during the night when very little else was calling for heat. So maybe this is the bug you've described and that I've seen before. The HR92 appeared to be working correctly - the valve was open - but it had also correctly sent the demand for heat (otherwise I wouldn't be able to see it in Domoticz). That would seem to suggest a controller bug to me? Interestingly, the only other time I've seen this is in the same room/zone. The controller showed no comms errors, so it wasn't like Domoticz had seen the message but the controller hadn't, either.

                    Comment

                    • kimber.kimber
                      Automated Home Sr Member
                      • Jan 2017
                      • 89

                      Wow that's a lot of discussion today.

                      It would be interesting to understand whether running with OpenTherm and uncontrolled maximum temps is more efficient that running with a BDR91.

                      Also, I'm interested to find out a little more from Ideal about the flame cycling. I was expecting it to turn down, rather than on off.

                      I've also picked up a Y87RF2024 today for my lounge for £50, so now have a BDR91 in case I want to make the switch.

                      Comment

                      • paulockenden
                        Automated Home Legend
                        • Apr 2015
                        • 1719

                        For owners of Viesmann and Ideal boilers it SHOULD be possible to build a box that sits between the OT bridge and boiler and which sets a safe upper limit on the boiler flow temp.

                        There are OT monitors and OT controllers - someone just needs to combine the two.

                        That is, if Honeywell won't/can't do it. I think we're past the stage now of saying "The boiler manufacturers are wrong" - yes they are, but more than one of them is doing it so a fix needs to be applied elsewhere.

                        Comment

                        • bruce_miranda
                          Automated Home Legend
                          • Jul 2014
                          • 2307


                          This one is both a listener and alterer. Should do the job nicely.

                          Comment

                          • DBMandrake
                            Automated Home Legend
                            • Sep 2014
                            • 2361

                            Originally posted by paulockenden View Post
                            For owners of Viesmann and Ideal boilers it SHOULD be possible to build a box that sits between the OT bridge and boiler and which sets a safe upper limit on the boiler flow temp.

                            There are OT monitors and OT controllers - someone just needs to combine the two.
                            The question is, do you clip the requested temperature at the set maximum, or scale it, and which method do boilers which DO support a manual maximum setting currently use.

                            I suspect boilers that let you set a maximum flow temperature on the dial when using OpenTherm simply use that as a limit. In other words if you set it to 65 degrees, any flow temperature request up to 65 degrees would be honoured, and any temperature beyond 65 would be clipped at 65.

                            That obviously would work, but I'm not sure that it's optimal - because now any increase in heat demand requested by the controller from about 70% to 100% won't make any difference, so only the bottom 70% would do something. This might or might not confuse the learning algorithms in the Evohome when it is trying to learn what heat demand is required in a given circumstance, and there is an abrupt knee in the transfer function.

                            Another way you could implement a flow temperature maximum limit would be to scale the temperature. If we assume the full requested range is 10 to 90 degrees, (I think I read somewhere that's what it is) and you set the limit to 65, you would scale it so that when 90 is asked for 65 is provided, and when 70 is asked for 50 is provided etc. The advantage of this is that the full heat demand percentage range is usable and has an effect without sudden clipping of the value, the maximum temperature is simply scaled down.

                            And if the reason for adjusting the flow temperature was to account for changes in heat losses of the house (manual weather compensation - which I think most of us probably do to some degree) then it would require the minimum amount of relearning of the Evohome.

                            Of course if anyone was designing an OpenTherm intermediary like this, both algorithms could be made available for testing to see which works better in practice, or whether the Evohome can adapt equally well to either method...

                            Another interesting thought is that if someone is going to the trouble to design such a device, there is no reason why they couldn't go the extra step and incorporate optional weather compensation - either with an outdoor sensor, or if the device is a bit more sophisticated, an IP connection to the internet that can retrieve weather report data. (Easily done in python on a Pi)
                            Last edited by DBMandrake; 28 April 2017, 09:54 AM.

                            Comment

                            • dty
                              Automated Home Ninja
                              • Aug 2016
                              • 489

                              Originally posted by DBMandrake View Post
                              The question is, do you clip the requested temperature at the set maximum, or scale it, and which method do boilers which DO support a manual maximum setting currently use.
                              Scaling would be the least confusing to the Evohome algorithms, I suspect. It would expect a different result when it asked for 90% load vs 100% load which it wouldn't get with clipping.

                              Comment

                              • DBMandrake
                                Automated Home Legend
                                • Sep 2014
                                • 2361

                                Originally posted by dty View Post
                                Scaling would be the least confusing to the Evohome algorithms, I suspect. It would expect a different result when it asked for 90% load vs 100% load which it wouldn't get with clipping.
                                That's my feeling too, although it's almost certain that boilers that do allow you to set a maximum flow temperature currently implement the limit simply using clipping... but if we're going to build an intermediate interface we can do better than that.

                                Comment

                                Working...
                                X