Boiler relay still firing with no heat demand.

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

    Boiler relay still firing with no heat demand.

    About 15 minutes ago I switched the system to Economy mode. As a result all rooms are well above the proportional band, and thus no heat demand. Also, the hot water tank is within the temp band.

    But the boiler just fired. So I looked in Domoticz to find the zone demanding heat, and there isn't one.




    First ever genuine proof I've seen of what others have complained about. Still a demand percentage on the boiler BDR91 some time after zones have stopped calling for heat. This is live data from an HGI80.

    I wonder whether the controller operates some kind of 'moving average' smoothing algorithm?
    Last edited by paulockenden; 29 December 2016, 12:44 PM.
  • roydonaldson
    Automated Home Guru
    • Jan 2013
    • 205

    #2
    Are any of your zones due to come on shortly ? and do you have optimum start turned on ?

    Comment

    • paulockenden
      Automated Home Legend
      • Apr 2015
      • 1719

      #3
      This is a lower level than that Roy. It's the raw data between the controller and the devices, so if optimisation was kicking in it would show as demand on one of the zones. Actually this is lower level than zones - this data shows the individual radiators (hence, for example, three labelled 'big lounge' - that's three radiators).

      Comment

      • DBMandrake
        Automated Home Legend
        • Sep 2014
        • 2361

        #4
        Most likely a heat demand message from the controller to the BDR91 was not received, so the BDR91 continued on its last known heat demand. At the next 20 minute "refresh" (or a change of heat demand, if that occurs sooner than the 20 minute refresh) it would have righted itself. (Was the problem still there another 20 minutes later ? My guess is no)

        I see this occasionally and the reason I probably notice it more than you is that my 3x BDR91 configuration provides some visual sanity checking of the system behaviour - in normal operation the boiler relay should turn on and off in time with the heating zone valve relay (assuming no hot water demand) and when they don't switch on and off together (boiler relay on by itself, or heating zone valve relay on by itself for extended periods of time like a whole TPI cycle) I know that a heat demand message to one of the relays was lost.

        It happens very rarely and comes right again usually within 10-20 minutes and is therefore not a big deal in the overall scheme of things, but for those of us that like to know every detail of how the system works and are perfectionists, it does irk a little bit.

        Comment

        • paulockenden
          Automated Home Legend
          • Apr 2015
          • 1719

          #5
          I don't think that's the case Simon.

          Even if the BDR had missed the message the HGI80 wouldn't have - it's sitting just a few feet away from the controller.

          I don't think any message was sent. It would be amazing if BOTH devices had missed the message.

          To me it looks like the controller doesn't set the heating BDR91 to zero at the point of zero demand, but instead slowly ramps it down.

          Perhaps others using an HGI80 could look for similar behaviour.

          P.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #6
            Originally posted by paulockenden View Post
            I don't think that's the case Simon.

            Even if the BDR had missed the message the HGI80 wouldn't have - it's sitting just a few feet away from the controller.

            I don't think any message was sent. It would be amazing if BOTH devices had missed the message.
            If there was a collision between the heat demand transmission from the controller and some other nearby device (wall stat, HR92, whatever) then it could very easily cause both the HGI80 and the BDR91 to receive a corrupted packet - which will then be discarded by both devices.

            Depending on the modulation scheme used (I'd have to check that reference material I dug up recently to remember what kind of modulation is used) the stronger signal (from controller to HGI80) would typically have to be at least 20dB stronger than the weaker one to fully "capture" the receiver and prevent the weaker signal corrupting the packet. This is possible but unlikely.

            So in my opinion if the cause was a collision between the transmission from the controller and some other device it's fairly likely that the HGI80 would also experience a corrupted packet, and thus both Domoticz and BDR91 would still indicate the last known heat demand. This would be consistent with your screenshot.
            To me it looks like the controller doesn't set the heating BDR91 to zero at the point of zero demand, but instead slowly ramps it down.
            I haven't seen any indication of this type of behaviour in all the (admittedly empirical, without an HGI80) testing I've done in the past. When a device like an HR92 sends a new heat demand the controller sends an updated heat demand to the BDR91 within seconds and jumps immediately to the new demand without any ramping as far as I can see. I can't think of a good reason for it to ramp or interpolate the demand.
            Last edited by DBMandrake; 29 December 2016, 06:51 PM.

            Comment

            • paulockenden
              Automated Home Legend
              • Apr 2015
              • 1719

              #7
              I'd kind of agree with you if it wasn't for the fact that several people have now posted exactly this same thing happening. Albeit until now it's been anecdotal. This is the first time with actual data evidence.

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #8
                Originally posted by paulockenden View Post
                I'd kind of agree with you if it wasn't for the fact that several people have now posted exactly this same thing happening. Albeit until now it's been anecdotal. This is the first time with actual data evidence.
                I'm surprised more people don't report these issues actually - probably because it happens but goes unnoticed unless you watch the system closely like we do on here.

                Transmission collisions between devices are inevitable with any wireless protocol where a device can transmit at an arbitrary time, and we've seen the design of Ramses II is such that some (many ?) types of messages do not expect a response from the recipient, so their absence at the receiving end is often not noticed since without an expectation of a reply you can't have an immediate retry mechanism, with the problem only "corrected" on a subsequent transmission that gets the devices back in sync.

                In this regard it is a bit like how network based FPS games work - they use UDP since they need low latency but packets sometimes go missing causing server and client state to get out of sync, however subsequent packets will get the game state back in sync again as enough information is sent in each packet to complete any missing state.

                There is a good reason why individual devices in Ramses II are limited to using no more than 1% of the available air time - it's to reduce the statistical likelyhood of collisions between devices to a "manageable" level where lost packets are infrequent enough to be not noticed or cause minimal disruption. (but not reduced to zero - only an acknowledgement based protocol could achieve that)

                The more devices you have in your system statistically speaking the more likely collisions are as well...

                Comment

                • paulockenden
                  Automated Home Legend
                  • Apr 2015
                  • 1719

                  #9
                  Ok, but why does that collision always seem to happen with the boiler relay?

                  I'll try to run a few more experiments.
                  Last edited by paulockenden; 29 December 2016, 10:14 PM.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    #10
                    Originally posted by paulockenden View Post
                    Ok, but why does that collision always seem to happen with the boiler relay?
                    Interesting question, but who says that it does though ? It's probably just a more obvious sign that something is amiss with communications because the BDR91 has an LED, and people do tend to obsess about things like why their boiler is running 10 minutes after they turned their heating "off".

                    If you turn all your HR92's a few degrees below the set points (or off) like you did and the boiler relay stays cycling for 15 minutes due to a lost message to the BDR91 that's quite obvious - the LED is still on and if you boiler is noisy you hear it running. (Thankfully ours is outside the living space and is nearly silent anyway)

                    However what happens if you have 10 different HR92's all maintaining their set points and then one of those opens slightly and sends a slightly increased heat demand to the controller - which gets lost due to a collision.

                    In practice nothing of significance happens - the heat demand forwarded to the BDR91 by the controller may fail to change slightly, say from 20% to 25% which would not be that noticeable. And depending on what the demand was from other HR92's at the time, it's possible that the heat demand to the BDR91 may not have changed even if the message was received.

                    For example an HR92 increasing its demand from 20% to 25% (which then gets lost due to a collision) may have had no effect at all on the boiler relay if another HR92 was already demanding 80%. So in this regard the system is probably fairly resilient to a small amount of packet loss, as next time the same HR92 makes another incremental change the state between HR92, controller and BDR91 will get back in sync.

                    Or another example - collisions with a temperature sensor transmission to the controller - as far as we know these transmissions are not acknowledged by the controller - if one goes missing how would we even know ? Maybe the room temperature didn't change in the last few minutes, or didn't change enough to be worth reporting ? That would be very hard to prove even with an HGI80.

                    I think DanD reported in another thread that an HR80 sends a temperature sensor update regularly every 4 minutes, however an HR92 sends its sensor updates anywhere between 4 minutes and 30 minutes depending on whether there is a temperature change that is sufficient to be worth reporting or not - obviously done for battery conservation reasons.

                    The only consequence of the lost message would be an additional delay in the change in temperature being acted on by the HR92 - which might result in a small amount of room temperature overshoot for example, but identifying that as the cause would be next to impossible.

                    So I'd argue that packet loss does happen with other devices, but the consequences are smaller and much harder to identify or prove.

                    I've certainly seen packet loss issues with the CS92 (in additional to the hot water set point issue discussed in my other thread) that didn't (mostly) go away until I moved the CS92 location.

                    And the most common packet loss (?) problem I see in regular use is actually HR92 local overrides failing to report on the controller - I first complained about that about a year ago - that approximately 1 in 10 times that I make a manual override on an HR92 it is not reported on the controller - any HR92 in the house, even the one about a metre from the controller. But if I make another adjustment a few seconds later it does go through.

                    I gave up worrying about that a long time ago and just accepted it as a quirk of the system...
                    Last edited by DBMandrake; 30 December 2016, 12:06 AM.

                    Comment

                    • killa47
                      Automated Home Guru
                      • Jan 2016
                      • 123

                      #11
                      Great Stuff DBMandrake.

                      Completely irrelevant to my system but I love reading your and Paulockenden's logic analysis. Some of us less capable members might think you two are Prof Brian Cox and Einstein incognito (not sure who is which).

                      It certainly reads like particle physics to me.

                      Cheers.
                      Last edited by killa47; 31 December 2016, 02:36 PM.

                      Comment

                      Working...
                      X