Evohome DHW overshoots

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

    Evohome DHW overshoots

    Hello all,

    I'm investigating some random DHW overshoots that I get with Evohome.

    Basic setup: Evohome (obviously!), no CH valve, DHW valve controlled by BDR, boiler fired by BDR, DHW kit.

    See below:

    dhw-overshoot.jpg

    As you can see, overnight the cylinder is cooling, then the set point kicks in in the morning. At this point, the cylinder doesn't heat, but I assume this is because it's not quite hit the 5C hysteresis I've set. Eventually (around 7am in this graph), it does, the valve opens, etc. Then... WTF happens at 8am??? And then the same in the evening. Cooling cylinder until around 8pm when the valve opens, then at about 9pm something odd happens.

    This doesn't happen every day. It can work just fine for 7-10 days, then randomly do it. In this case, it's done it twice in quick succession.

    Any ideas?
  • killa47
    Automated Home Guru
    • Jan 2016
    • 123

    #2
    Is the insertion sensor fully inserted into the cylinder pocket so that it is getting the best temp reading? [Or are you using the strap on sensor?]
    Also just check the CS92 is not missing any wireless comm signals back to controller, which might allow overshoot.

    Comment

    • HenGus
      Automated Home Legend
      • May 2014
      • 1001

      #3
      Originally posted by killa47 View Post
      Is the insertion sensor fully inserted into the cylinder pocket so that it is getting the best temp reading? [Or are you using the strap on sensor?]
      Also just check the CS92 is not missing any wireless comm signals back to controller, which might allow overshoot.
      Have you got pump over-run selected? I ask because with it ON I used to get temperature over-runs. After chatting it through with my installer, he pointed out that my boiler is of an age where it isn't necessary. With pump over-run OFF, I have never had a temperature exceedance in nearly three years of use. I have had occasional HW comms faults but all have been in HW OFF periods.

      Comment

      • DBMandrake
        Automated Home Legend
        • Sep 2014
        • 2361

        #4
        Originally posted by dty View Post
        Hello all,

        I'm investigating some random DHW overshoots that I get with Evohome.

        Basic setup: Evohome (obviously!), no CH valve, DHW valve controlled by BDR, boiler fired by BDR, DHW kit.

        See below:

        [ATTACH=CONFIG]939[/ATTACH]

        As you can see, overnight the cylinder is cooling, then the set point kicks in in the morning. At this point, the cylinder doesn't heat, but I assume this is because it's not quite hit the 5C hysteresis I've set. Eventually (around 7am in this graph), it does, the valve opens, etc. Then... WTF happens at 8am??? And then the same in the evening. Cooling cylinder until around 8pm when the valve opens, then at about 9pm something odd happens.

        This doesn't happen every day. It can work just fine for 7-10 days, then randomly do it. In this case, it's done it twice in quick succession.

        Any ideas?
        Oh boy, you have some reading ahead of you. Start reading at this post in one of my threads:



        I had exactly the same problem as you initially and spent a long time diagnosing the root cause of this. When you've caught up with that thread come back here.

        The good news is I was able to resolve the problem.

        Comment

        • dty
          Automated Home Ninja
          • Aug 2016
          • 489

          #5
          Originally posted by DBMandrake View Post
          The good news is I was able to resolve the problem.
          If the good news ends with CH valve, DHW priority, and clever wiring of relays, then it's not good news at all for me... :-( I'll get reading and report back...

          Comment

          • dty
            Automated Home Ninja
            • Aug 2016
            • 489

            #6
            Originally posted by killa47 View Post
            Is the insertion sensor fully inserted into the cylinder pocket so that it is getting the best temp reading? [Or are you using the strap on sensor?]
            Also just check the CS92 is not missing any wireless comm signals back to controller, which might allow overshoot.
            I'm using a strap-on!

            Not sure how I'd detect lost messages from the CS92. My Domoticz data looks smooth, which suggests there are regular messages, and there's no error in the controller's logs.

            Comment

            • dty
              Automated Home Ninja
              • Aug 2016
              • 489

              #7
              Originally posted by HenGus View Post
              Have you got pump over-run selected? I ask because with it ON I used to get temperature over-runs. After chatting it through with my installer, he pointed out that my boiler is of an age where it isn't necessary. With pump over-run OFF, I have never had a temperature exceedance in nearly three years of use. I have had occasional HW comms faults but all have been in HW OFF periods.

              I have, but it's not an overshoot in the sense of going straight through the target temperature. If it was, overrun would be the obvious first port of call. In my case, the temperature stabilises for a good half an hour or more before suddenly shooting up again.

              Comment

              • Edinburgh2000
                Automated Home Guru
                • Dec 2016
                • 134

                #8
                Forgive me poking my nose in here, but I think DBMandrake's "good news" was referring to his discovery of a common fault on the CS92s. See:


                Specifically:
                it was a lack of battery contact tension on the rear of the PCB in the CS92. (Not the contacts at the batteries themselves)
                To fix it all I did was remove the batteries and front plate from the rear panel, gently lift up the plastic tab at the top that locks the PCB in place then carefully lever the top of the board out with a small screw driver and lift the board right out.

                This reveals the fingers that make contact with the rear of the PCB. I bent them both carefully up by about 2-3mm to give a decent amount of tension, then carefully reinserted the board into the bottom and clicked it into place at the top, and refitted the front and the batteries. Five minutes tops. No problems at all since then.
                That certainly seemed to fit with my own observations of my CS92 and I found that suggestion from DBMandrake very helpful.

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  #9
                  Originally posted by dty View Post
                  If the good news ends with CH valve, DHW priority, and clever wiring of relays, then it's not good news at all for me... :-( I'll get reading and report back...
                  Don't worry, clever wiring of relays not required - that was a completely unrelated issue.
                  Originally posted by dty View Post
                  I'm using a strap-on!

                  Not sure how I'd detect lost messages from the CS92. My Domoticz data looks smooth, which suggests there are regular messages, and there's no error in the controller's logs.
                  You use a direct RF interface for Domoticz don't you - can you post a few hours of data for your hot water temperature in CSV format during a period of time where you see overshoots ?

                  AFAIK when you use Domoticz with an HGI80 (or equivalent) every temperature update sent by the CS92A will be logged at the time it was sent, so the timestamp of the messages is just as useful as the temperature reading to diagnose if you have the same problem I did.

                  Originally posted by dty View Post
                  I have, but it's not an overshoot in the sense of going straight through the target temperature. If it was, overrun would be the obvious first port of call. In my case, the temperature stabilises for a good half an hour or more before suddenly shooting up again.
                  What's really happening is that the temperature is continuing to rise during the period where the graph shows it flat-lining - but there are no temperature updates being sent by the CS92A. A look at the CSV output of your hot water temperature during a problem time will confirm this if you can post it for us.

                  Originally posted by Edinburgh2000 View Post
                  Forgive me poking my nose in here, but I think DBMandrake's "good news" was referring to his discovery of a common fault on the CS92s. See:


                  Specifically:



                  That certainly seemed to fit with my own observations of my CS92 and I found that suggestion from DBMandrake very helpful.
                  Indeed. Here is a quick summary of the issues, as it did get spread amongst a couple of threads I think.

                  1) Some CS92A's do not have their battery contacts on the back side of the PCB tensioned sufficiently from new. This seems to be a problem with the contacts in some HR92's as well - to me the material seems too soft and is not a sufficiently springy grade of steel. To fix this dismantle the unit, remove the PCB board, carefully bend the two battery contacts that press against the board to lift them about 2mm above where they were before (more towards the board) then put the unit back together.

                  2) Changing hot water set point (especially increasing it) and/or differential doesn't always seem to update the CS92A with the new values which can lead to the cut-out trigger point being missed and result in an overshoot. Workaround - if this is happening after changing the hot water temperature, reboot the controller by parting the batteries while off the stand. This seems to re-send the set point to the CS92A and solve the overshoot.

                  3) The CS92A seems quite picky about its location. After fixing the battery contacts the problem was 95% solved but it still once in a while overshot. After ruling everything else out I eventually just moved its location in the closet to the only other reasonable location (and one which actually has worse line of sight) and the remaining 5% of overshoots went away. I don't get any overshoots at all now according to my graphs.

                  And here is the longer more technical explanation of what is going on for those interested:

                  There were two separate problems going on in my system causing the same symptoms. Problem one was that the CS92A was not sending temperature updates for as much as 20 minutes at a time during hot water reheat, due to the battery saving algorithm being fooled. This would cause a flat line on my graph and then suddenly it would realise it had overshot by 12 degrees.

                  The basis of this problem is that the sensor has a fairly clever battery saving algorithm that works something like this:

                  The controller informs the CS92A of the hot water set point and differential. Lets say its 55 degrees and 5 degrees respectively. The CS92A uses this to make judgements about when temperature readings are critical and when they can be delayed for maximum battery saving.

                  If the temperature is below the set temperature minus differential updates are very infrequent. An update is sent about once an hour, or after a few minutes if the temperature changes several degrees. (5 ?) This is why when you start heating a cold cylinder updates are very infrequent until the temperature approaches your set temperature range and then the updates come thick and fast.

                  In the differential range updates are sent fairly frequenly - as often as every 30 seconds to a minute or so. When the hot water set point is reached, an immediate update is sent, and I believe it is sent 3 times in a row with a 10 second delay. This will be to ensure that the message that says the hot water is up to temperature definitely gets through to avoid just such an overshoot.

                  The battery contact issue seems to cause the CS92A to malfunction in a way that the battery saving algorithm prevents it sending when it should. I suspect the poor connection just causes the device to intermittently reboot - every time it reboots it sends an immediate temperature update, and then doesn't seem to send anything for quite a while. I also suspect that the hot water set point and differential is only stored in ram in the CS92A so if it does reboot it goes back to the default (62 ?) until it next gets an update from the controller. Thus if this reboot happens in the middle of a reheat it overshoots as it doesn't know what the real set point is yet.

                  62 seems to be a magic number because all my overshoots were to 62 degrees. Either this is the default hot water set point of the CS92A after it reboots or it is a safety threshold where it always sends an update regardless of the hot water set point.

                  I don't know whether the controller refreshes the set point/differential periodically or only after the CS92A or controller is rebooted. I did find that when I changed the hot water temperature from 50 degrees (working perfectly) to 55 degrees, I then started getting overshoots to 62 degrees all day long until I rebooted the controller, then it started shutting off correctly at 55 degrees, so there is definitely an issue there with communicating the set point when it is changed.

                  The second problem I still had after the first was fixed was that some transmissions from the CS92A were being sent but not being received. This was much less frequent and only accounted for a small percentage of the problem, but was the remaining problem after the first issue was fixed. Instead of at least 5 overshoots a week I was seeing maybe one a week, but they still persisted.

                  If I had to guess I would say that the location of the CS92A (which is near the cylinder no matter where in the boiler closet I put it) was in a standing wave null for 868Mhz, despite the 5/5 signal test. I moved it to another wall with a 90 degree change in orientation which only gives a 4/5 signal, more or less as a last "I don't believe this will work, but I'll try anything now" test, and to my surprise it did work - no more overshoots at all now, which is a relief because for a long time there I felt that the hot water sensing system was fundamentally flawed in design.
                  Last edited by DBMandrake; 13 February 2017, 11:07 AM.

                  Comment

                  • dty
                    Automated Home Ninja
                    • Aug 2016
                    • 489

                    #10
                    Your timing could not be better, thank you! I was literally about half a page into the 10 page thread you referenced!

                    I'll take a look at the battery contacts and the Domoticz data and report back.

                    Thank you!

                    Comment

                    • DBMandrake
                      Automated Home Legend
                      • Sep 2014
                      • 2361

                      #11
                      Any luck ? I had my first hot water overshoot in months this morning, here is the CSV output from Domoticz. Keep in mind I use the Web API scripts which means I only get readings every 5 minutes, not at the times when readings are transmitted. Hot water set point is 54 degrees with a 5 degree differential. Notice how the reading rose to 52.56 then "stuck" there for a full 65 minutes before the reading suddenly jumped to 64.75. In reality the temperature would have been rising that whole time, but no updates were being sent. (or received - hard to be sure which)

                      Code:
                      20/02/2017 04:50	0	20/02/2017 04:50	43.11
                      20/02/2017 04:55	0	20/02/2017 04:55	43.11
                      20/02/2017 05:00	0	20/02/2017 05:00	43.11
                      20/02/2017 05:05	60	20/02/2017 05:05	43.33
                      20/02/2017 05:10	60	20/02/2017 05:10	43.33
                      20/02/2017 05:15	60	20/02/2017 05:15	50.07
                      20/02/2017 05:20	60	20/02/2017 05:20	52.56
                      20/02/2017 05:25	60	20/02/2017 05:25	52.56
                      20/02/2017 05:30	60	20/02/2017 05:30	52.56
                      20/02/2017 05:35	60	20/02/2017 05:35	52.56
                      20/02/2017 05:40	60	20/02/2017 05:40	52.56
                      20/02/2017 05:45	60	20/02/2017 05:45	52.56
                      20/02/2017 05:50	60	20/02/2017 05:50	52.56
                      20/02/2017 05:55	60	20/02/2017 05:55	52.56
                      20/02/2017 06:00	60	20/02/2017 06:00	52.56
                      20/02/2017 06:05	60	20/02/2017 06:05	52.56
                      20/02/2017 06:10	60	20/02/2017 06:10	52.56
                      20/02/2017 06:15	60	20/02/2017 06:15	52.56
                      20/02/2017 06:20	60	20/02/2017 06:20	52.56
                      20/02/2017 06:25	60	20/02/2017 06:25	52.56
                      20/02/2017 06:30	60	20/02/2017 06:30	64.75
                      20/02/2017 06:35	60	20/02/2017 06:35	64.75
                      20/02/2017 06:40	60	20/02/2017 06:40	64.75
                      As my boiler flow temperature is only set to 70 at the moment 65 degrees is about the hottest the hot water will get even if the hot water zone valve remained open permanently. Good thing my boiler doesn't use an 80 or 90 degree flow temperature boost for hot water or my hot water would have been REALLY (dangerous, scalding) hot this morning after a 65 minute overrun!

                      No idea what caused it - no fault logbook entries and no other signs of system misbehaviour, and the hot water behaviour has been flawless for months.

                      One question - do you have Alkaline batteries in your CS92A or have you put lithiums in ? I'm considering putting Lithiums in mine because they hold their terminal voltage higher for a lot longer as the battery discharges, and the device does seem to be sensitive to low battery voltage either due to low batteries, or poor battery contact. So a battery that keeps a higher terminal voltage for a longer portion of its life may be beneficial. So far I have only ever used Alkaline's in all my Evohome devices for cost reasons, but I'm starting to reconsider that due to the superior voltage discharge curve of lithium batteries.
                      Last edited by DBMandrake; 20 February 2017, 10:37 AM.

                      Comment

                      • dty
                        Automated Home Ninja
                        • Aug 2016
                        • 489

                        #12
                        I was just thinking yesterday that I should update this thread.

                        Having an HGI80 (-equivalent) doesn't help with data resolution. I still get a data-point every 5 minutes in Domoticz. So, as much as the Evohome integration must be capturing that data, Domoticz is somehow quantizing it. Also, because I don't run my Domoticz in debug mode (Raspberry Pi, smashed SD card...) I wasn't able to do any message-level debugging.

                        I did, however, disassemble the CS92A and improve the battery connection. Since doing that, I've not had an overrun. And I can understand a bit better about some of the odd behaviour I was seeing. For example, the set point changing at 5:30 in the morning, but the temperature in the cylinder not increasing for 30-45 minutes is cause by the battery-saving heuristics of the sensor (assuming your theory is correct!)

                        So I'll be keeping an eye on it, but for now things are definitely improved.

                        Comment

                        • paulockenden
                          Automated Home Legend
                          • Apr 2015
                          • 1719

                          #13
                          I've not had an overshoot since mid December.

                          chart (2).jpg

                          Alkaline batteries, never fiddled with them.

                          P.

                          p.s. Set point avg being below actual is because the DHW is off overnight, so lowers the average. I wish Domoticz would (optionally) ignore zeroes when averaging.

                          Comment

                          • dty
                            Automated Home Ninja
                            • Aug 2016
                            • 489

                            #14
                            Oh yeah, batteries. I'm using whatever batteries it came with! I didn't pay that much attention.

                            Comment

                            • dty
                              Automated Home Ninja
                              • Aug 2016
                              • 489

                              #15
                              If you're putting lithiums in your HR92s, don't forget to change parameter 9 to 1. Obviously, can't do that with the CS92A.

                              Comment

                              Working...
                              X