Boilers, BDRs and TPI

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • dty
    Automated Home Ninja
    • Aug 2016
    • 489

    Boilers, BDRs and TPI

    Something is awry with either my setup, or the accepted wisdom of how this stuff works. (Or maybe we just haven't reverse-engineered the protocol quite well enough yet and captured that knowledge correctly in Domoticz...)

    General wisdom is that when Evohome is controlling the boiler via a BDR and TPI, it tells the BRD what heat load it wants (say, 73%) and then the BDR is responsible for cycling the boiler on and off within the various cycling parameters set to meet that heat load.

    However, when I look at the boiler switch device in Domoticz, I see the following:

    boiler.jpg

    Since this is in Domoticz and I'm using an HGI80, this data must be coming from radio messages.

    You can see that at 00:02 the line steps down to 35% where it stays until 00:10 when it steps down to 0% until 00:22. I have 3 cycles an hour, so I'm guessing that 00:02 to 00:22 is one cycle. During which, the boiler appears to be on for 8 minutes, or 40% of the time. This seems like it's reasonably close to 35% (although 7 minutes would be closer!)

    However, at 00:56, the line steps up to 45%, where it stays until 01:11. That's 15 minutes out of a 20 minute cycle, or 75%. Nowhere close to 45%.

    So it seems as though the controller is managing the duty cycle itself by turning the boiler on and off (if the radio messages have been interpreted correctly), but that that duty cycle doesn't necessarily seem to represent the heat demand contained within the control messages.

    Thoughts?
  • DanD
    Automated Home Ninja
    • Feb 2016
    • 250

    #2
    Here's some info from my system which might help to understand the relationship between the heat demand values and actual boiler switching. I've just updated the Domoticz Evohome code so that each BDR91 can also be monitored.

    Boiler device heat demand data:
    Boiler Demand.jpg

    Boiler BDR91 device data:
    Boiler BDR91.jpg

    Heat Demand seems to be split into 20min intervals and BDR91 switching seems to be split into 10min intervals. My controller settings are Cycle Rate: 6/h Min On Time: 1min.

    Time Period 23:30 - 01:00:
    Boiler Demand: 15min 47%, 5min 0% (35.25% / h)
    Boiler BDR91: 1min 15sec On, 8min 45sec Off (12.5% / h)

    Time Period 05:30 - 06:30:
    Boiler Demand:15min 67%, 5min 0% (50.25% / h)
    Boiler BDR91: 2min 45sec On, 7min 15sec Off (27.5% / h)

    Time Period 06:30 - 08:00:
    Boiler Demand:14min 24sec 100%, 5min 36sec 0% (72% / h)
    Boiler BDR91: Permanently On

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #3
      Originally posted by dty View Post
      However, at 00:56, the line steps up to 45%, where it stays until 01:11. That's 15 minutes out of a 20 minute cycle, or 75%. Nowhere close to 45%.

      So it seems as though the controller is managing the duty cycle itself by turning the boiler on and off (if the radio messages have been interpreted correctly), but that that duty cycle doesn't necessarily seem to represent the heat demand contained within the control messages.
      I think there may be a few confounding factors here confusing the issue.

      In my testing the controller doesn't manage the on off switching manually - at least not of the boiler or heating relays. (It does for the hot water relay) If you pull the batteries out of the controller when the heating BDR91 is currently cycling with a 30% duty cycle it will continue to autonomously follow the same pattern for about 45 minutes, even though the heat demands from the controller ceased suddenly and unexpectedly. (I've tried this test) So I think this confirms the controller sends a percentage and doesn't directly command every on and off explicitly.

      Another thing that makes me fairly sure of this is that on a three relay system it tries keep the boiler relay and heating relay synchronised so that they switch on and off together, however they never switch at exactly the same time, they are usually a few seconds out, and sometimes the two relays can get as much as a minute out of sync. (more on that in a minute)

      Other factors to consider are where does the TPI cycle begin ? Does it begin with the relay switching on, (the on period is the first part of the cycle) or the relay switching off ? (the off period is the first part of the cycle) If the duty cycle is constant it doesn't matter, however if the duty cycle is constantly varying, and more often than the length of the cycle itself (which it typically is, in response to HR92's adjusting themselves) then whether the TPI cycle is considered to start from the on or off point matters when you try to analyse what is going on.

      For example say the cycle begins when the relay switches on and you have a 30% duty cycle. You time from the moment it switches on until it goes off then comes back on again and it should be 10 minutes. (On default settings) But what happens if part way through that 10 minute period you change the duty cycle to 50% ? If it happens before the 30% point of the cycle then the relay just stays on longer. If it happens between 30 and 50% then the relay comes back on again even though it just went off a minute or so earlier, and then goes back off again at 50%. If it happens after 50% then the relay stays off until the next cycle.

      Either way its 10 minutes until the relay turns on again. However I'm pretty sure (I don't remember 100%) that last time I tried to time the interval between the off->on transition to the next off->on transition it was not a constant 10 minute but varied widely with changes in heat demand. This suggests that the OFF period is the beginning of the cycle and not the ON period. A higher duty cycle means that the relay comes on earlier in the cycle not that it comes on at the beginning and stays on for longer.

      Because this is opposite to the way you might be thinking it works (your idea of where the TPI cycles start and end might be wrong) this could explain some of what you see.

      Additionally your 20 minute cycle time is really long, and the heat demand could change multiple times in that period - HR92's send heat demand updates as frequently as every 4 minutes with changes in room temperature or more often if a schedule or person adjusts the set point. Is there any particular reason you're using 20 minutes ? (oil fired boiler ?) I've tried 20 minutes on my system and found that TPI just did not work very well with such a long cycle time, the system was too slow to respond and I saw more problems with under and overshoots. Unless your boiler requires it I'd suggest you go back to 10 minute cycles.

      Another thing to be aware of is there is a synchronise command that the controller sends to the relays periodically which re-synchronises the start of the TPI cycle for the relay. I'm assuming the reason for this is so that when you use a three relay config the system wants the boiler and heating relays synchronised in their switching - its no use opening the heating zone valve while the boiler isn't firing or firing the boiler when the heating zone valve isn't open!

      If the relays were left to their own devices and only ever given a duty cycle they would drift out of timing with each other fairly quickly. I believe the synchronise message is sent every 20 minutes. I've seen situations where the two relays do drift out of sync with each other on my system, up to 30 seconds or so but then come right after the next 20 minute synchronisation.

      By the way your graph doesn't make sense to me - it indicates the heat demand dropping to 0 frequently, I very much doubt that is true, I think you'll find that's a mistake in the way Domoticz is reporting or graphing the heat demand, maybe Dan will be able to explain what is happening there.

      Originally posted by DanD View Post
      Here's some info from my system which might help to understand the relationship between the heat demand values and actual boiler switching. I've just updated the Domoticz Evohome code so that each BDR91 can also be monitored.

      Boiler device heat demand data:
      [ATTACH=CONFIG]1024[/ATTACH]

      Boiler BDR91 device data:
      [ATTACH=CONFIG]1025[/ATTACH]

      Heat Demand seems to be split into 20min intervals and BDR91 switching seems to be split into 10min intervals. My controller settings are Cycle Rate: 6/h Min On Time: 1min.
      Not sure what you mean by heat demand being split into 20 minute intervals - heat demand can change at any time due to an adjustment of a set point, and HR92's will make valve adjustments (and thus send new heat demands) as often as every 4 minutes.

      What you might be seeing there is something Paul has noted before - that the current heat demand is repeated every 20 minutes if there has been no change in the heat demand in the last 20 minutes. That may be tied in with the synchronise message that synchronises the start time of the TPI intervals periodically so that multiple relays don't drift out of timing with each other.

      I don't understand why your graphs show heat demand dropping to 0% periodically - is Domoticz definitely receiving a transmission that says a 0% heat demand, or is it misinterpreting something ? Does domoticz log the exact time the message came in on the graphs or does it get rounded to the nearest 5 minute interval ?
      Last edited by DBMandrake; 28 April 2017, 01:53 PM.

      Comment

      • DanD
        Automated Home Ninja
        • Feb 2016
        • 250

        #4
        @DBMandrake,

        Thanks for your comments. I definitely agree with your concerns about the 0s in the Boiler demand plots and these do seem strange. The boiler heat demand values presented by Domoticz are a combination of 2 different messages (0x0008 and 0x3150) sent from the controller. The BDR91 values that I've shown in the plot above are sent directly from the BDR91 via a single command 0x3EF0. It's definitely possible that combining the controller heat demand values from the 2 different messages is incorrect. I've done a quick review of the data behind the 2 plots that I posted and it does appear that the 0s always come from the 0x0008 message and the more plausible values come solely from the 0x3150 message. I'll do some more testing on this and modify the code to see whether it makes more sense to remove the 0x0008 messages from the heat demand data. I'm sure there's a sensible reason why the original author of the code decided to combine these 2 values, but various parts of the code were clearly labelled as work in progress with FIXMEs when I picked it up last year and it's only as we start to dig deeper and deeper into the workings of the Evohome system that we'll resolve some of these issues.

        Thanks,

        Dan

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          #5
          Hi Dan,

          Combining those two message would seem to account for the value jumping back and forth to zero. As you're posting in this thread on the Domotica forum I'm assuming you've seen the document linked here ?



          It specifically lists message 0x3150 as the heat demand, however about 0x0008 all it says is "Sent from CM67z, purpose unknown."

          Also mentioned in this post:



          Does the value from 0x0008 always seem to be zero ? How often is it transmitted ? Every 20 minute by any chance ?

          Interesting that this post (by the original Domoticz Evohome author ?) seems to say that 0x3150 is sent as a heat demand from HR92's to controller but 0x0008 is used from controller to relay ? I'm not sure that's correct ? Has anyone ever tried binding an HR92 directly to a BDR91 to see if it works and what message sends the heat demand ? Or what about when a DTS92 is bound directly to a BDR91 ?

          The synchronisation command I was thinking of is apparently 0x3B00 as mentioned in this post:



          Again in that message he talks about 0x0008 as the heat demand not 0x3150...weird!

          I've read through that entire thread ages ago so interesting to read it again now to refresh my memory. Given what you know about the code and protocol now after the work you've done, does it appear there is still some confusion over those two messages and what 0x0008 really does ?

          As the document I linked talks about the message coming from a CM67z wall stat not a radiator valve, I wonder if 0x0008 is a heat demand generated by a wall thermostat (in the case where there is no radiator valve, such as a CM67z bound directly to a BDR91) and 0x3150 is a heat demand from a radiator valve ?

          If you think about it, in an Evohome system its the radiator valves NOT any wall thermostats you have that generate the heat demands, and a wall thermostat like a DTS92 bound to the controller only sends a measured temperature to the controller to be relayed to an HR92, and its the HR92(s) that generate the heat demands.... but if you had a DTS92 wall thermostat bound directly to a BDR91 with no Evohome or radiator valves at all, the wall thermostat MUST then have to generate the heat demand and send it to the BDR91 or the system wouldn't work.

          So perhaps there are two modes of operation, one using 0x3150 and one using 0x0008 ? It's interesting too that the DTS92 seems to be able to work in more than one mode - if you bind it directly to a BDR91 it can display a flame when the boiler is firing, suggesting that it has direct control over the heat demand (which it must) however when you bind it to an Evohome all it does is provides a temperature reading to the Evotouch for the zone, and set point changes if the user presses the button, but doesn't generate a heat demand and can't show a flame for boiler activity. It seems to operate in a reduced functionality mode and many of the configuration options aren't available when bound to an Evohome.

          If you have a DTS92 it might be worth unbinding it and your BDR91 and binding them directly to each other to see what message seems to convey the heat demand in this standalone sans-Evotouch configuration! Maybe that would provide some clues.

          Edit: I don't know how feasible it is but perhaps just graph the value from the two different messages on separate graphs or as an overlay on the same graph, until it is worked out exactly what 0x0008 is and when it might be used ? Otherwise if it is just removed, then maybe in some other configuration (DTS92+BDR91 for example) it will then no longer graph heat demand.
          Last edited by DBMandrake; 28 April 2017, 03:26 PM.

          Comment

          • DanD
            Automated Home Ninja
            • Feb 2016
            • 250

            #6
            Thanks DBMandrake,

            Here's some further information on the heat demand messages from 3 different systems.

            First system, my live system which has a boiler relay set-up plus DHW using the colour wifi Evohome controller.

            Based on observations from this system, it looks like the 0x0008 boiler heat demand message relates to the DHW demand as it perfectly matches the DHW BDR91 switching. The 0x3150 boiler heat demand message matches the remaining heat demand requested by the CH.

            Boiler BDR91 switching data:
            Boiler BDR91- 2.jpg

            Boiler heat demand (0x3150):
            Boiler Demand (0x3150).jpg

            Boiler heat demand (0x0008):
            Boiler Demand (0x0008).jpg

            I've not bothered with a screen capture for the DHW BDR91 as it's identical to the one above.

            Test system 1: Evohome colour controller without wifi, CH only set-up and test system 2: Evohome monochrome controller, CH only set-up. The 0x0008 heat demand message appears every 20min, but is always 0. The 0x3150 boiler heat demand message matches the heat demand requested by the CH.

            I also have a CMZone test system and I'll set this up and capture the heat demand data. I've also got a spare relay, one of the older HC60NG devices which I'll wire up so that I can add DHW valve to my test systems. It's not ideal as it doesn't send out messages confirming it's state like the BDR91, but it should still help.

            Unfortunately I don't have one of the DTS92s, but I do have access to the data captured from a number of other Evohome installations. I'll take a look at these and I'm sure that some had the type of zone set-up you described.

            It's looking like it would make more sense to create separate devices in Domoticz for capturing the information from these two commands.


            Dan

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              #7
              Originally posted by DanD View Post
              Thanks DBMandrake,

              Here's some further information on the heat demand messages from 3 different systems.

              First system, my live system which has a boiler relay set-up plus DHW using the colour wifi Evohome controller.

              Based on observations from this system, it looks like the 0x0008 boiler heat demand message relates to the DHW demand as it perfectly matches the DHW BDR91 switching. The 0x3150 boiler heat demand message matches the remaining heat demand requested by the CH.

              Boiler BDR91 switching data:
              [ATTACH=CONFIG]1033[/ATTACH]

              Boiler heat demand (0x3150):
              [ATTACH=CONFIG]1034[/ATTACH]

              Boiler heat demand (0x0008):
              [ATTACH=CONFIG]1035[/ATTACH]

              I've not bothered with a screen capture for the DHW BDR91 as it's identical to the one above.
              Hi Dan,

              That's looking promising! Although I'm perhaps a wee bit confused. Was your testing with a 3x BDR91 system ? EG Boiler control relay, CH relay and HW relay ? (Which is the system I have)

              When you refer to 0x0008 boiler heat demand and 0x3150 boiler heat demand, are you saying that BOTH these separate messages are directed at the same bound boiler control relay ? If so, does that mean that the boiler control relay is combining these two different demands from two different messages itself to produce one final TPI duty cycle, rather than the controller combining heating and hot water demands before sending it to the boiler relay ?

              So in other words if the 0x0008 demand is zero, (no hot water demand) the relay is using a duty cycle controlled by 0x3150 (heating) however if 0x0008 is 200, (hot water demand) the CH demand is ignored and the relay just stays on 100% of the time ?

              In that case maybe the best way to deal with this is rather than updating a single value from both these messages as they come in, (which we now know is wrong and results in the value alternating) internally log/keep track of the most recent value received from each message independently, but when it comes to displaying/graphing a heat demand, essentially do a max(0x0008,0x3150) so that the highest of the two demand figures is displayed and graphed. This would then be consistent with the behaviour of the relay because a hot water demand will indeed bring the boiler relay on 100% even if the heating demand is small or non existent, so it would be correct for the boiler relay graph to show this 100% demand on the same graph.

              So what gets sent to the CH relay and the HW relay ? Does the HW relay always receive 0 from 0x3150 and receive 0 or 200 from 0x0008 depending on hot water demand ?

              And does the CH relay always receive 0 from 0x0008 and receive between 0 and 200 from 0x3150 ?

              Is this the same in a two relay S-Plan system without a boiler control relay ? (I assume so)

              Comment

              • DanD
                Automated Home Ninja
                • Feb 2016
                • 250

                #8
                Hi DBMandrake,

                My system set-up is a 2 relay S plan, with 1 relay controlling the DHW valve and the other controlling boiler firing via the 'boiler relay' option (and the CH valve is simply latched open).

                When I refer to the boiler heat demand messages 0x0008 and 0x3150. I'm referring to 'informational' heat demand messages sent from the controller to itself and the raw hex messages look like this: (the 0xFC value denotes the boiler and 0xC8=200, 0x1A=26 are the heat demand values):

                Code:
                2017-05-02 08:57:47 045  I --- 01:073076 --:------ 01:073076 0008 002 FCC8
                Code:
                2017-05-02 08:57:21 045  I --- 01:073076 --:------ 01:073076 3150 002 FC1A
                I think the BDR91s listen out for the heat demand values for their assigned function (0xFC=Boiler 0xFA=DHW) and set their switching rates based upon these values. The BDR91s also report their status immediately whenever they switch state and repeat their state every 10min via a 3EF0 command and they confirm their operating heat demand value via a 3B00 message every 10mins too.

                I agree with your suggestion as to how to handle these different types of heat demand messages. I think I have to keep them as separate logging devices in Domoticz.

                Code:
                2017-05-02 09:06:19 045  I --- 13:068653 --:------ 13:068653 3EF0 003 0000FF
                Code:
                2017-05-02 09:06:18 045  I --- 13:068653 --:------ 13:068653 3B00 002 00C8
                Last edited by DanD; 2 May 2017, 05:05 PM.

                Comment

                • dty
                  Automated Home Ninja
                  • Aug 2016
                  • 489

                  #9
                  Excellent work, Dan! :-)

                  Comment

                  • dty
                    Automated Home Ninja
                    • Aug 2016
                    • 489

                    #10
                    Originally posted by DanD View Post
                    Unfortunately I don't have one of the DTS92s
                    I have two DTS92s due to arrive today (if I'm lucky!). One is not urgently needed, so I'll send it to Dan to use for testing purposes for a few weeks

                    Comment

                    • dty
                      Automated Home Ninja
                      • Aug 2016
                      • 489

                      #11
                      So now I've been using Dan's development code, I can see much more clearly when Evohome is asking for the boiler to be on. This has, however, highlighted a couple of interesting things...

                      Firstly, my Evohome was using 4 minutes minimum on time, and 6 cycles per hour. 4 minutes seems like a long time. What do others use? My boiler is a Potterton Suprima 100L 30kWh heat-only non-condensing, non-modulating dinosaur.

                      Secondly, it seems that during the day when temperatures are fairly stable, Evohome is using the minimum it can to keep the house warm: 4 minutes on, 6 minutes off. However, during the 4 minute period the boiler shuts down because it's reached its flow temperature. So it will fire up for a minute or so, then shut down for a minute or two, then fire up for 45 seconds, then shut down for the remainder of the cycle. This seems particularly inefficient to me. Does it also suggest other problems with the system, such as undersized radiators (failing to take enough heat from the flow)?

                      I will soon be replacing the boiler with a modulating, condensing one and attempting to set up OpenTherm too, so hopefully these problems will soon be behind me, but I'm certainly interested to hear people's opinions on whether this indicative of other issues.

                      Comment

                      • DBMandrake
                        Automated Home Legend
                        • Sep 2014
                        • 2361

                        #12
                        Originally posted by dty View Post
                        So now I've been using Dan's development code, I can see much more clearly when Evohome is asking for the boiler to be on. This has, however, highlighted a couple of interesting things...

                        Firstly, my Evohome was using 4 minutes minimum on time, and 6 cycles per hour. 4 minutes seems like a long time. What do others use? My boiler is a Potterton Suprima 100L 30kWh heat-only non-condensing, non-modulating dinosaur.
                        I use 6 cycles per hour and 1 minute minimum ontime - eg the default. I experimented with 3, 6, and 9 cycles per hour and with 1 and 2 minute minimum on times and for my system at least, my conclusion was that the default 6 cycles and one minute worked the best.

                        Reducing the cycles to 3 per hour made the system far too slow to respond to small changes in heat demand in a timely fashion - say bumping up the temperature in a room half a degree or even one degree, when the boiler TPI duty cycle is already quite low. It could be 20-30 minutes before I'd notice any extra heat from the radiator. I also found it allowed the room temperature to fluctuate more than 6 cycles did when overall system demand was low. So I wouldn't recommend 3 cycles per hour unless someone had a boiler that really didn't like being cycled more often. (Oil fired ?)

                        I found no advantage to more than 6 cycles per hour - in theory it would give a "smoother" control, but it has a side effect that it effectively makes your minimum on time percentage higher. EG if you use 6 cycles and 1 minute minimum on time, the minimum heat demand that the boiler can provide is 10% - or a 10:1 modulation ratio, in effect. If you were to use 12 cycles per hour you now have 5 minute cycles with a 1 minute minimum on time, now your minimum boiler output is 20% or a 5:1 modulation ratio - the smaller modulation ratio is not good when heat demand is minimal.
                        Secondly, it seems that during the day when temperatures are fairly stable, Evohome is using the minimum it can to keep the house warm: 4 minutes on, 6 minutes off. However, during the 4 minute period the boiler shuts down because it's reached its flow temperature. So it will fire up for a minute or so, then shut down for a minute or two, then fire up for 45 seconds, then shut down for the remainder of the cycle. This seems particularly inefficient to me. Does it also suggest other problems with the system, such as undersized radiators (failing to take enough heat from the flow)?
                        If you have a non-modulating boiler, like me, what you describe is normal. Under a low heat demand quite a bit (or all) of the BDR91 on time during a cycle may largely coincide with an off period for the boilers own flow thermostat. There's not much that can be done to avoid this, the boiler has to shut off when it reaches its set flow temperature, which will happen quickly if the radiators are hardly flowing and most of the flow is returning via the ABV.

                        If you have a modern modulating boiler it's probably a sign that the current heat demand is lower than what your boiler can modulate down to - either an oversized boiler or insufficient modulation ratio. But keep in mind that in a large house with a lot of radiators and a boiler specced for them that it would be almost impossible not to have the boiler cycling off and on if say only one radiator is demanding a small amount of heat. The heat demand of a single radiator is usually below the minimum heat that a boiler can modulate down to.

                        I think you'll find that your excessive minimum on time is not allowing evohome to reduce the boiler output low enough - effectively you're telling it that it has to run the boiler at at least a 40% duty cycle, or not at all. So it waits until a 40% heat demand builds up before it fires the boiler at all, but when it does so the boiler runs for long enough to hit its own flow temperature cutout. Change the minimum on time back to one minute and I suspect you won't see the boiler hitting its flow temperature limit under low load conditions nearly as often.

                        On my system I usually see very low loads (one bedroom radiator on at night in winter) resulting in an average flow temperature of around 40-50 degrees even when the boiler flow temperature thermostat is set to 70, because evohome is only running the boiler for about 1 minute out of each 10 minute cycle to maintain that one room at 17 degrees.
                        Last edited by DBMandrake; 4 May 2017, 04:07 PM.

                        Comment

                        • DanD
                          Automated Home Ninja
                          • Feb 2016
                          • 250

                          #13
                          Same here; 6 cycles per hour and 1 minute minimum on time and I have a modulating boiler. I think I messed around with these settings last year and came to the same conclusion as DBMandrake.

                          Dan

                          Comment

                          • bruce_miranda
                            Automated Home Legend
                            • Jul 2014
                            • 2307

                            #14
                            I use OT, so was surprised to see that I was even offered these options in the UI but they are set to 1min and 6 per hour. I suspect however with OT these parameters are ignored.

                            Comment

                            Working...
                            X