Phantom override

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • morpheus
    Automated Home Sr Member
    • Apr 2016
    • 68

    #16
    I will test and let you know.

    P.S. Please note If I am correct the "danger zone" which is for me 4 minutes after the hour and fter the half an hour will depend from people to people ... I think Honeywell told me this timeframe because they saw that the PRogram I was using for that faulty zone was 18:00 to 18:30, so fixed hour and half hour.
    I still need to check with Honeywell but it could be that someone who has the phantom override issue on a zone for which there is a progeam from 18:10 to 19:20 should swap the batteries out site of the hour:10 - hour:14 and hour:20 - hour:24 timeframe ...

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #17
      I've been giving this some more thought and I don't think this explains the problem I was seeing and reported at the beginning of this thread, although it does seem to explain what you were seeing.

      Here is my understanding of your issue based on what you've fed back from Honeywell support:

      Apparently an HR92 sends a set point change / update message to the Evotouch every 30 minutes counting from the time the device booted (battery insertion) even though you are not adjusting the control wheel. This is presumably to help the HR92 automatically resync with the controller should the controller be rebooted. This set point update simply sends the current set point the HR92 is set to, and the message is presumably the same or similar message that is sent if you actually turned the wheel to make a change to the set point.

      However this creates a window of opportunity of up to 4 minutes when the controller has a scheduled set point change. For example:

      Before 9am the set point is 5 degrees, at 9am it is scheduled to change to 20 degrees. However that message is not sent from the Evotouch immediately - it waits for the next 4 minute communication period for that HR92 before sending the message, so the message could actually be sent any time between 9am and 9:04am depending on when the periodic 4 minute communication window to that HR92 falls. Lets say it will be sent at 9:03am. Between 9am and 9:03am the controller set point is 20 degrees but the HR92 set point is still 5 degrees.

      At the same time the HR92 is sending its current set point (5 degrees) back to the controller every 30 minutes since it booted. If that 30 minute set point sending interval happened to fall between 9am and 9:03am this would be interpreted as a manual override to 5 degrees, because the controller currently believes the zone is set to 20 degrees even though it hasn't actually sent the set point change to the HR92 yet. Thus you get a manual override icon on the screen and the zone temperature reverts to what it was before the set point change - in this case 5 degrees. Because the set point was changed back to what it already was before 9am, no set point update message to 20 degrees ever gets sent to the HR92.

      To the user it appears that someone manually overrode the temperature back to the previous set point.

      The window of opportunity is a maximum of 4 minutes, but the actual value is going to depend on how the 4 minute communication cycle to the HR92 is aligned with the system time, since automated set point changes can only occur on 10 minute intervals. (5 if you use optimum start, I think, since optimum start makes 15 minute adjustments) And whether that window of opportunity is hit at all in practice is going to depend on the timing of the periodic 30 minute update from the HR92.

      The worst case scenario is that a 4 minute cycle occurs just before a 5/10 minute clock interval (say 4:59) which means you have to wait up to about 4 minutes for a set point change to be sent out - any 30 minute broadcast from the HR92 during that 4 minute window will cause the issue, if a set point change was due. On the other hand say the 4 minute interval was aligned 30 seconds after the set point change, now there is only a 30 second window of opportunity for that 30 minute broadcast to cause a problem - much less likely to happen.

      This only applies to scheduled set point changes that fall on even 5/10 minute boundaries of course, a manual set point change made by the user from the controller or via phone app is still potentially at risk if you are unlucky with the timing of when you make the change...

      This poses some interesting questions - it sounds like the 30 minute interval is specific to each HR92 and basically begins when the batteries are connected and the device boots - thus the advice to reboot the HR92 avoiding certain times to avoid any clashes with your normal set point changes for the zone.

      However its not clear where the 4 minute cycles start from (are they established by the HR92, or by the controller ?) and whether they are different for each zone/HR92 or nearly the same for all of the HR92's... From my own observations it seems that after turning the heating on there will be a delay of up to 4 minutes then most (all ?) HR92's will start opening at roughly the same time, which makes me think the controller may be what is establishing the 4 minute cycle, and that each zone is communicated with fairly rapidly in sequence - eg not all at the exact same moment, but they are not randomly staggered either as all the valves start to open within a few seconds of each other.

      It will be interesting to see how they fix this problem - especially if they have to do so with only a controller firmware update. Although HR92's have mini USB sockets and are probably theoretically field upgradable, if the older colour controller is anything to go by I think it's very unlikely that Honeywell would offer a USB based firmware update for HR92's to end users unless the problem was critical and couldn't be solved another way...

      The reason why I don't believe I was seeing the same problem as you, is because during the period that I was seeing random set point changes it was not a simple case of the set point reverting back to what it was after a scheduled set point change - it occurred over night when there were no scheduled set point changes, and the temperature jumped up and down to several different temperatures seemingly at random, some of which were odd temperatures I don't even have scheduled at any time on any zones...(like 30 degrees - ouch!)
      Last edited by DBMandrake; 11 May 2016, 12:39 PM.

      Comment

      • morpheus
        Automated Home Sr Member
        • Apr 2016
        • 68

        #18
        Originally posted by DBMandrake View Post
        I've been giving this some more thought and I don't think this explains the problem I was seeing and reported at the beginning of this thread, although it does seem to explain what you were seeing.

        Here is my understanding of your issue based on what you've fed back from Honeywell support:

        Apparently an HR92 sends a set point change / update message to the Evotouch every 30 minutes counting from the time the device booted (battery insertion) even though you are not adjusting the control wheel. This is presumably to help the HR92 automatically resync with the controller should the controller be rebooted. This set point update simply sends the current set point the HR92 is set to, and the message is presumably the same or similar message that is sent if you actually turned the wheel to make a change to the set point.

        However this creates a window of opportunity of up to 4 minutes when the controller has a scheduled set point change. For example:

        Before 9am the set point is 5 degrees, at 9am it is scheduled to change to 20 degrees. However that message is not sent from the Evotouch immediately - it waits for the next 4 minute communication period for that HR92 before sending the message, so the message could actually be sent any time between 9am and 9:04am depending on when the periodic 4 minute communication window to that HR92 falls. Lets say it will be sent at 9:03am. Between 9am and 9:03am the controller set point is 20 degrees but the HR92 set point is still 5 degrees.

        At the same time the HR92 is sending its current set point (5 degrees) back to the controller every 30 minutes since it booted. If that 30 minute set point sending interval happened to fall between 9am and 9:03am this would be interpreted as a manual override to 5 degrees, because the controller currently believes the zone is set to 20 degrees even though it hasn't actually sent the set point change to the HR92 yet. Thus you get a manual override icon on the screen and the zone temperature reverts to what it was before the set point change - in this case 5 degrees. Because the set point was changed back to what it already was before 9am, no set point update message to 20 degrees ever gets sent to the HR92.

        To the user it appears that someone manually overrode the temperature back to the previous set point.

        The window of opportunity is a maximum of 4 minutes, but the actual value is going to depend on how the 4 minute communication cycle to the HR92 is aligned with the system time, since automated set point changes can only occur on 10 minute intervals. (5 if you use optimum start, I think, since optimum start makes 15 minute adjustments) And whether that window of opportunity is hit at all in practice is going to depend on the timing of the periodic 30 minute update from the HR92.

        The worst case scenario is that a 4 minute cycle occurs just before a 5/10 minute clock interval (say 4:59) which means you have to wait up to about 4 minutes for a set point change to be sent out - any 30 minute broadcast from the HR92 during that 4 minute window will cause the issue, if a set point change was due. On the other hand say the 4 minute interval was aligned 30 seconds after the set point change, now there is only a 30 second window of opportunity for that 30 minute broadcast to cause a problem - much less likely to happen.

        This only applies to scheduled set point changes that fall on even 5/10 minute boundaries of course, a manual set point change made by the user from the controller or via phone app is still potentially at risk if you are unlucky with the timing of when you make the change...

        This poses some interesting questions - it sounds like the 30 minute interval is specific to each HR92 and basically begins when the batteries are connected and the device boots - thus the advice to reboot the HR92 avoiding certain times to avoid any clashes with your normal set point changes for the zone.

        However its not clear where the 4 minute cycles start from (are they established by the HR92, or by the controller ?) and whether they are different for each zone/HR92 or nearly the same for all of the HR92's... From my own observations it seems that after turning the heating on there will be a delay of up to 4 minutes then most (all ?) HR92's will start opening at roughly the same time, which makes me think the controller may be what is establishing the 4 minute cycle, and that each zone is communicated with fairly rapidly in sequence - eg not all at the exact same moment, but they are not randomly staggered either as all the valves start to open within a few seconds of each other.

        It will be interesting to see how they fix this problem - especially if they have to do so with only a controller firmware update. Although HR92's have mini USB sockets and are probably theoretically field upgradable, if the older colour controller is anything to go by I think it's very unlikely that Honeywell would offer a USB based firmware update for HR92's to end users unless the problem was critical and couldn't be solved another way...

        The reason why I don't believe I was seeing the same problem as you, is because during the period that I was seeing random set point changes it was not a simple case of the set point reverting back to what it was after a scheduled set point change - it occurred over night when there were no scheduled set point changes, and the temperature jumped up and down to several different temperatures seemingly at random, some of which were odd temperatures I don't even have scheduled at any time on any zones...(like 30 degrees - ouch!)
        To be honest I started to read half of the lessage then got lost in your explanations, but I think I got it anyway ;-)

        I understand the issue is simply that if the HR92 is sending its legacy report within the 4 minutes following a program change on the controller, the controller will set this setpoint and therefore override the program.
        Please note the zone which Honeywell investigation on my system had a program change at 18:00 then at 18:30, and that is probably why they ask me to swap the batteries outside of the 4 minutes AFTER the hour and half the hour.

        If my faulty zone had a program change at 18:15 then 19:45, they would probably have asked to swap the batteries outside of the hour:15 > hour:19 AND hour:45 -> hour:49 ...


        For your information, the faulty zone where I swapped the batteries never got faulty anymore.
        A second faulty zone Honeywell asked me to try to set is as "multi" ... I set it up yesterday and no issue anymore on that one neither ...

        Now, I understand your point where you say for you it happened during the night where no setpoint change was programmed .... but you seem to say there is another reason why for you this is another issue ? Which reason ?

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          #19
          Originally posted by morpheus View Post
          Now, I understand your point where you say for you it happened during the night where no setpoint change was programmed .... but you seem to say there is another reason why for you this is another issue ? Which reason ?
          I have no idea what the cause of it might be, just that I don't think it's the same issue you are seeing. As it has not happened again it doesn't give me much chance to analyse the behaviour any further - the two graphs in this thread are the only record I have of it ever occurring. Until it happens again I'm not going to worry about it.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #20
            Originally posted by morpheus View Post
            I understand the issue is simply that if the HR92 is sending its legacy report within the 4 minutes following a program change on the controller, the controller will set this setpoint and therefore override the program.
            Please note the zone which Honeywell investigation on my system had a program change at 18:00 then at 18:30, and that is probably why they ask me to swap the batteries outside of the 4 minutes AFTER the hour and half the hour.

            If my faulty zone had a program change at 18:15 then 19:45, they would probably have asked to swap the batteries outside of the hour:15 > hour:19 AND hour:45 -> hour:49 ...


            For your information, the faulty zone where I swapped the batteries never got faulty anymore.
            I've just observed the same issue you describe twice in the last week.

            A couple of days ago I overrode the Bathroom from the scheduled 16 degrees to 20 degrees until 11:30 am (about an hour away) via the main controller in preparation for a shower. About 15 minutes later I happened to glance at the controller and to my surprise it was showing a manual override until 11:30 not of 20 degrees, but of 16 degrees...so the temperature never actually changed and the bathroom was still cold... So this problem can also occur in response to a manual override at the controller, where the override temperature (but not override time) get reverted.

            An incident earlier in the week I did not directly observe but I caught via my graphs. At a time when the bathroom was scheduled to drop from 20 degrees to 16 degrees there was a small downwards blip on the graph to 16 degrees for one 5 minute sample period and then the temperature was back to 20 degrees again until the next set point change to 5 degrees - some 10 hours away... so in this case it caused the zone to remain too hot for a good 10 hours, as clearly observed when comparing the graph to my set point schedule.

            Now that I think back through my time of ownership there have been a few times where a temperature change I thought I had made had not been applied when I came back later - I had put it down to forgetfulness but in hindsight I think its pretty clear that I have seen this happen (albeit very rarely) over a long period of time.

            I really hope a proper solution to this with a software update is possible, rather than just workarounds.
            A second faulty zone Honeywell asked me to try to set is as "multi" ... I set it up yesterday and no issue anymore on that one neither ...
            Yes, because HR92's in multi-room zones don't override the set point on the controller. The HR92 will still be sending out the set point change that causes the problem, but the controller ignores it, like it used to before the local override display feature was added in a software update.

            Comment

            • morpheus
              Automated Home Sr Member
              • Apr 2016
              • 68

              #21
              Originally posted by DBMandrake View Post
              I've just observed the same issue you describe twice in the last week.

              A couple of days ago I overrode the Bathroom from the scheduled 16 degrees to 20 degrees until 11:30 am (about an hour away) via the main controller in preparation for a shower. About 15 minutes later I happened to glance at the controller and to my surprise it was showing a manual override until 11:30 not of 20 degrees, but of 16 degrees...so the temperature never actually changed and the bathroom was still cold... So this problem can also occur in response to a manual override at the controller, where the override temperature (but not override time) get reverted.

              An incident earlier in the week I did not directly observe but I caught via my graphs. At a time when the bathroom was scheduled to drop from 20 degrees to 16 degrees there was a small downwards blip on the graph to 16 degrees for one 5 minute sample period and then the temperature was back to 20 degrees again until the next set point change to 5 degrees - some 10 hours away... so in this case it caused the zone to remain too hot for a good 10 hours, as clearly observed when comparing the graph to my set point schedule.

              Now that I think back through my time of ownership there have been a few times where a temperature change I thought I had made had not been applied when I came back later - I had put it down to forgetfulness but in hindsight I think its pretty clear that I have seen this happen (albeit very rarely) over a long period of time.

              I really hope a proper solution to this with a software update is possible, rather than just workarounds.

              Yes, because HR92's in multi-room zones don't override the set point on the controller. The HR92 will still be sending out the set point change that causes the problem, but the controller ignores it, like it used to before the local override display feature was added in a software update.

              ok ... here is the status of today with the phantom derogation ... my contact in Belgium is still in contact with the development team I think based in UK.
              The proposed solution of swapping the batterines on the HR92, outside of the 4 minutes legacy report sending time seems to work. Problem never happened anymore on the zone I changed the batteries on ...
              Putting a zone in "multi" also seemed to work ... I had not seen anymore the issue on a faulty zone being set in Multi

              BUT ....

              I still have 2 concerns :

              1. If the issue is the legacy report being sent within the 4 minutes after a T° setpoint change on the Evotouch, then it means following le the problem should happen every day at the same time on the same zone (assuing the egacy report is sent once a day at the same time ...) .... and this is not the case !!! The issue seems to occur some days only.

              2. Today I have seen for the first time the same issue appearing on a zone which never presented the issue so far (!!!)

              this is worrying me a lot.



              P.S. : How much involvement does it cost to implement the log you have with the graphs ? How does it work ?

              Many thanks !!

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #22
                Originally posted by morpheus View Post
                1. If the issue is the legacy report being sent within the 4 minutes after a T° setpoint change on the Evotouch, then it means following le the problem should happen every day at the same time on the same zone (assuing the egacy report is sent once a day at the same time ...) .... and this is not the case !!! The issue seems to occur some days only.
                I thought you implied earlier than the legacy report was sent every 30 minutes ? If so, 4 minutes does not divide evenly into 30 minutes...

                I'm also not sure that it is exactly 4 minutes - when I have timed it it seems to vary between about 3 1/2 minutes and 4 1/2 minutes, perhaps the time is deliberately staggered slightly to minimise the chance of collisions between different devices on the network.

                Perhaps someone with an HCI80 can confirm the exact timing of the "4 minute" update schedule.
                P.S. : How much involvement does it cost to implement the log you have with the graphs ? How does it work ?

                Many thanks !!
                My graphs are made with a Raspberry Pi running the evohome-munin plugin with the munin monitoring and graphing software.

                It was a fair bit of work to set up and get running to my satisfaction. (munin is fairly fiddly to set up and isn't well documented in my opinion) I've thought about writing a How-To on how to set it up before but unfortunately I just don't have the time to do something like that at the moment.

                Comment

                • morpheus
                  Automated Home Sr Member
                  • Apr 2016
                  • 68

                  #23
                  Originally posted by DBMandrake View Post
                  I thought you implied earlier than the legacy report was sent every 30 minutes ? If so, 4 minutes does not divide evenly into 30 minutes...

                  I'm also not sure that it is exactly 4 minutes - when I have timed it it seems to vary between about 3 1/2 minutes and 4 1/2 minutes, perhaps the time is deliberately staggered slightly to minimise the chance of collisions between different devices on the network.

                  Perhaps someone with an HCI80 can confirm the exact timing of the "4 minute" update schedule.

                  My graphs are made with a Raspberry Pi running the evohome-munin plugin with the munin monitoring and graphing software.

                  It was a fair bit of work to set up and get running to my satisfaction. (munin is fairly fiddly to set up and isn't well documented in my opinion) I've thought about writing a How-To on how to set it up before but unfortunately I just don't have the time to do something like that at the moment.

                  no ... Honeywell confirmed to me the legacy report was sent hourly at the time you inserted the batteries in the HR92.
                  IF it suits with the time of a setpoint change on the Evotouh, it will then override this setpoint change.

                  In my case for that zone the setpoint change was at 18:00 and 18:30, reason why they asked me to swap the batteries OUTSIDE of the xx:00 - xx:04 and xx:30 - xx:34 minutes ...

                  Comment

                  • morpheus
                    Automated Home Sr Member
                    • Apr 2016
                    • 68

                    #24
                    We are now more than a year after this issue was raised and according me there is still no fix deployed to avoid this issue ...
                    Do you still encounter it ?

                    I did because I had to change some of my batteries and I did it on purpose in the 4 minutes warning zone ...

                    Comment

                    • IM35461
                      Automated Home Sr Member
                      • Jan 2012
                      • 69

                      #25
                      My hallway HR92 has started doing it again adopting a manual override temperature at night equal to the daytime program time.

                      I guess time to try the battery removal again

                      Comment

                      • Rameses
                        Industry Expert
                        • Nov 2014
                        • 446

                        #26
                        Originally posted by IM35461 View Post
                        My hallway HR92 has started doing it again adopting a manual override temperature at night equal to the daytime program time.

                        I guess time to try the battery removal again
                        Sounds like a double bind
                        getconnected.honeywell.com | I work for Honeywell. Any posts I make are purely to help if I can. Any personal views expressed are my own

                        Comment

                        • morpheus
                          Automated Home Sr Member
                          • Apr 2016
                          • 68

                          #27
                          CRAZY !!! We are September 2018, and I just got the following automated mail from honeywell ... 2 and an half year after issue reported !!!
                          I can not check if issue is solved, because I had applied at that time the workaround with the batteries that Honeywel provided, but I see now I am with SW version :

                          Application SW Version : 02.00.17.03
                          Wifi SW Version : 02.00.17.00

                          ########################
                          Dear Sir, Madam
                          You recently contacted Honeywell with a technical support issue. Following is a summary of your support ticket. Please review and respond to the question below.
                          Ticket number: 02382098
                          Email address:
                          Subject: Evohome displays derogation
                          Date ticket created: 1/4/2016
                          We believe we have resolved your request. Would you agree that we can close your case?
                          If you disagree a member of our team will follow up with you.

                          Thank you,
                          Honeywell Technical Support


                          ########################

                          ... and I read on another post on this forum that this version is solving the "Ghost Zone fix" as mentioned on the first post here :


                          ...

                          Comment

                          • top brake
                            Automated Home Legend
                            • Feb 2015
                            • 837

                            #28
                            nothing to worry about guys, just a change in systems has resulted in some legacy cases being opened inadvertantly
                            I work for Resideo, posts are personal and my own views.

                            Comment

                            • guyank
                              Automated Home Sr Member
                              • Sep 2015
                              • 73

                              #29
                              I know this is an old thread, but I’ve experienced a very strange set of phantom overrides this morning. I’ve previously had the overrides described above, but haven’t seen them in a while. This morning, with the set point set at 18C the temp kept changing to 20C with a local override indicated. If I reset the override, within a few minutes it would return. This happened 6 times in the space of an hour. I’ve tried removing the batteries from both HR92s and the Y87, but it keeps happening.

                              Comment

                              • DBMandrake
                                Automated Home Legend
                                • Sep 2014
                                • 2361

                                #30
                                20C is the default temperature of an HR92 when it boots up. If you take the batteries out of an HR92 then put them back in, it will go to 20C and apply an override on the controller.

                                Most likely the battery contacts in the HR92 are loose causing the device to spontaneously reboot, perhaps when the motor turns. (Increasing load on the battery)

                                Lift it off the radiator and try these two tests.

                                1) Hold it upright in one hand then bring it down, thumping it into your other palm with moderate force. You may find it reboots.

                                2) Remove the knob at the top and try to wiggle and turn both batteries - you may find that causes a reboot as well.

                                In both cases remove the batteries and carefully bend up the contacts from below a little bit with a small screwdriver to put a bit more pressure on the batteries. Sometimes it's necessary to bend the shorting bar on the top slightly as well.

                                The battery contacts in the HR92 - both the bottom ones and the shorting plate at the top are dreadful, and I have had these kind of intermittent connection problems on nearly all of my HR92's and have had to fix some multiple times. The metal is far too soft and is not a spring grade of steel as it should be for battery contacts, so once the weight of the batteries bends the contacts they stay bent and don't spring back.

                                Putting the security screws into the shorting bar at the top can help apply a bit more pressure on the top side of the batteries.
                                Last edited by DBMandrake; 6 October 2018, 12:34 PM.

                                Comment

                                Working...
                                X