Phantom override

[morpheus]

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 !!

[DBMandrake]

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.

[morpheus]

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 ...

[morpheus]

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 ...

[IM35461]

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

[Rameses]

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

[morpheus]

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 :
https://www.automatedhome.co.uk/vbul...on-02-00-17-03

...

[top brake]

nothing to worry about guys, just a change in systems has resulted in some legacy cases being opened inadvertantly

[guyank]

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.

[DBMandrake]

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.