Hot Water issue - Random Overshoots

[PaulB]

My HR92 batteries (original factory supplied Alkaline) are lasting on average 18 months. I've just replaced the hallway and kitchen ones recently when they were generating multiple warnings in the fault logbook. In fact the hallway one went flat enough that the HR92 "crashed" with all symbols lit up on the screen at once and it was non-responsive.

I've had similar with one of my HR92's which is in the conservatory, it literally complained once on the controller about low battery the same morning, but when the HR92 was touched, or the dial rotated, it would crash, show all the symbols on the LCD & restart itself.

[DBMandrake]

Thanks for the information, it has been very useful. Out of the 5 hot water kits I have installed this is the first to show any issues, however most are only now 12 months old.

As the new CS92A receiver had come I decided to put it in anyway but I took the circuit board out bent over the contacts more and did this on the battery - funnily enough I had the exact same problem on a DT90E a couple of month ago where the contacts weren't even touching from factory.

I've also had this problem with the battery contacts in the bottom of a couple of HR92's - the grade of steel used for the contacts does not seem to be "proper" spring steel as spiral shared battery contacts usually are so it loses its tension relatively easily.

I tested the batteries that came with it - they were reading 1.61v so i've gone with them. (The ones in the old receiver were 1.6v) I usually upgrade everything to Lithium when doing an install but my local supplier keeps failing to keep AAs in stock. In future I think I may only use these.

1.6v should be plenty. The main advantage of the Lithium's is they won't drop below 1.6v until the battery is nearly depleted whereas an Alkaline will be down to more like 1.2v by then.

Yes I would agree the 62oc seems to be some sort of fail safe as it seemed to reach this temperature every time, however i'm not sure what would happen if you have your HW set greater than 62oc?

I don't know what would happen either - but all my overshoots when the battery contact issue was there were to exactly 62 degrees, regardless of whether my HW was set to 50 or 55 degrees, so there is something special about 62.

So once everything was up and running it heated up fine and the controller seemed to update on a regular basis the temperature increase and then shut off at the set point. Obviously only time will tell now as this only appeared to happen once a week. However going to my own EvoHome I find that it takes a while to update the temperature on the panel when heating (Longer than the system this morning). In the past I thought it was just a flaw in the design of the EvoHome but I might investigate that a bit further.

It seems to be normal for it to update infrequently when it is below the differential range. So for example if you had 55 as the set point and 10 as the differential, below 45 degrees it only updates after the temperature has changed many (5-10) degrees so the nothing will appear to be happening for a long time during initial heating, but then when it reaches 45 it will start updating much more frequently - usually every 1 or 2 degrees, and also when it hits the set point - 55 in this case.

Unfortunately it seems to go back to infrequent updates again once the temperature has gone past the set point on the assumption that the system will stop heating. But if that message doesn't get through for some reason it results in an overshoot, and another update isn't sent until 62 degrees.

There has only been a couple of times when we've run out of hot water - I just put the down to the 50oc set point with a 10oc drop, coupled with the fact my heat exchanger is cast iron so takes longer to heat up from cold. However it could be possibly be the EvoHome not updating quick enough.

I'm very familiar with how much I can run the hot tap before it starts dropping low enough to trigger a reheat, and I had run it much longer than I would have expected, and it still said 52 degrees (with a 54 degree set point and 5 degree differential) so I started to get suspicious.

I turned the tap off and left it for 5 minutes and it still claimed 52 degrees but I knew it couldn't be. I removed the battery from the CS92A and reinserted it and the reading immediately jumped to about 30 degrees. This is exactly the sort of symptom I used to see back when I had the original battery contact problems - long periods of time with no change in the reading and yet the correct reading was always sent when the batteries were reconnected. That's when I decided to change the batteries again.

[DBMandrake]

And again today, a "Comms error" with the hot water sensor reported on the touch panel, and an hour glass reported instead of the temperature. Hot water was scheduled on and up to temperature at the time.

I pressed the signal test button on the CS92A and it immediately reported 5 flashes for a full 5/5 signal. I then removed the battery and refitted it and the controller immediately reported the temperature and cleared the "comms fault".

When you consider that the hot water sensor sends an update at least once an hour, and has to fail to report in for about 3 hours before a hot water sensor fault is logged on the controller, I can't see any way that this is a real comms fault, especially given that it immediately reported a 5/5 signal, and re-inserting the batteries immediately sent through a temperature reading. (These are new batteries too, fitted 2 weeks ago)

I wonder when Honeywell will admit that there a design flaw in either the hardware of the CS92A or a bug in its firmware where it just fails to send temperature updates for long periods of time ? Random inexplicable "loss of communication" and the occasional hot water overshoot despite doing a large amount of troubleshooting and investigation into the problem is getting very tiresome indeed. Something as simple as a temperature sensor for a hot water cylinder should just work, and work reliably.

Looks like I might have to get an HGI80 to prove once and for all where the real problem lies...

[Edinburgh2000]

I wonder when Honeywell will admit that there a design flaw in either the hardware of the CS92A or a bug in its firmware where it just fails to send temperature updates for long periods of time ? Random inexplicable "loss of communication" and the occasional hot water overshoot despite doing a large amount of troubleshooting and investigation into the problem is getting very tiresome indeed. Something as simple as a temperature sensor for a hot water cylinder should just work, and work reliably.

All of which supports the plea for Honeywell, in its next evolution of this product, to provide a mains-powered CS92 replacement. This would ideally fit into an identical baseplate to a BDR91 to ease the wiring and appearance when mounted in an array of BDR91s. The cylinder probe cable can be extended quite significantly with no material degradation in the accuracy of the temperature sensing so the location of the CS92 is not really a constraint and should be as easy to power from the mains as any BDR91. That should enable Honeywell to redesign the software to give much more frequent and reliable temperature updates without worrying about battery life.

[mtmcgavock]

Is it not possible that your CS92A is faulty?

After the one I have replaced the issue doesn't seem to have reoccurred, although I did carry out the various steps you mentioned on the new device to ensure there was no issue. And I am right in thinking yours is still in the same room as the BDR91's? How far away is it from the main panel.

[paulockenden]

If there was a design flaw in the CS92 (or firmware) surely we'd all be seeing these comms errors with our DHW? I'm with the poster above - I suspect you have a faulty CS92.

[DBMandrake]

Is it not possible that your CS92A is faulty?

After the one I have replaced the issue doesn't seem to have reoccurred, although I did carry out the various steps you mentioned on the new device to ensure there was no issue. And I am right in thinking yours is still in the same room as the BDR91's? How far away is it from the main panel.

Yes the CS92A is in the closet with the boiler and the hot water cylinder. (Although it's only a small 100 litre cylinder) It is 70cm from the nearest BDR91 and 50cm from the cylinder. Distance to the controller which is permanently wall mounted is 6 metres with line of sight through the closet wall and a glass door. Signal test is 5/5.

I've already moved the CS92A as far away from other objects as possible - moving it further away from the BDR91's last year did help quite a bit but it is still not completely reliable.

If there was a design flaw in the CS92 (or firmware) surely we'd all be seeing these comms errors with our DHW? I'm with the poster above - I suspect you have a faulty CS92.

Perhaps, but only if it is faulty from new. You only have to look on forums to see how common these symptoms are though. I had a look on the evohomeshops own forum a couple of days ago and found 3 threads in the last few months all for the same problem I'm seeing of intermittent hot water overshoots. So I doubt it is an isolated experience given the relatively few threads on that forum in total.

The level of troubleshooting that I've already performed in the last 9 months is already well beyond what would be expected from a normal end user so I think I'll email Richard and ask him if he will swap it. (I think it's still within the warranty) I'm sceptical that it will help though. I think the problem really is just a result of the less than 100% reliable communications protocol in anything other than perfect and unrealistic RF conditions.

[mtmcgavock]

Do you not think it is possible that there is interference from the Relays? Then again the HW kit at my parents is probably more than 70cm closer and we don't appear to have any issue there. Have you also checked your probe connections as I suppose if you don't have a good connection then it wouldn't read the temperature.

The most obvious thing seems to be that your CS92 is faulty, bar the one that I had the issue with i've had little issue with the ones i've installed so far. Now when all the batteries start going that might be another issue.

[DBMandrake]

Richard sent me a replacement CS92A which I installed on Sunday.

It has gone back into the same location with the same original batteries (still 1.57v) and I deliberately did not bend any battery contacts etc. I also swapped the strap on sensor to be thorough, although I don't think it could be related to the problem I was seeing. All bindings were thoroughly cleared and I set up the whole stored hot water section from scratch. (EG cleared and rebound all BDR91's etc)

So far, touch wood, I have not noticed any overshoots, but it has only been a few days. Based on the unpredictable and intermittent nature of the problem it will need to run without problems for a couple of months before I can draw any real conclusions. Fingers crossed!

The part number of the replacement is identical to the original - only the date code differs, but I suppose its theoretically possible that the newer unit could have revised firmware on it that would alter its sampling and transmission behaviour.

[DBMandrake]

Two weeks since swapping the CS92A without an overshoot. Promising so far but still too soon to draw any firm conclusion.

I'm crossing my fingers that the problem is properly resolved though..!

[mtmcgavock]

Two weeks since swapping the CS92A without an overshoot. Promising so far but still too soon to draw any firm conclusion.

I'm crossing my fingers that the problem is properly resolved though..!

The CS92A I replaced that was showing the same issues has also been fine over a 4 week period. Could it have been they were both faulty units?

[Edinburgh2000]

Just a thought.....could it be that it is summer time? I too have found my CS92 to be behaving well in recent weeks. In earlier months, the DHW heating would often trip out on the mechanical thermostat in my cylinder and the CS92 would only catch up some minutes later to show that the temperature had gone well past the setpoint. That has not happened recently. Could it be that there is much less RF chatter going on while we have our heating off and the DHW is the only heating demand?

[DBMandrake]

Nearly a month and no overshoots that I'm aware of, although I haven't scrutinised my Domoticz logs to be 100% sure.

So it looks like I had a faulty unit. I'm not sure if that's good or bad to be honest! Good that it may not have been a fundamental comms design flaw as I was beginning to suspect, but bad in that it was faulty from new, and I'm not the only one to run into this problem.

Right back from new it was giving trouble although most of the symptoms went away after tensioning the battery contacts on the rear of the PCB - as it did for some other people with similar problems. But it never really fixed it 100% it seems, it just put it into remission.

Perhaps its something like the copper trace on the rear of the PCB being slightly oxidised from new, never quite getting a reliable connection. The spring contacts aren't a particularly good spring steel so seem to lose their tension over time, which wouldn't have helped if there was some oxidation. (Same problem with poor spring steel in the battery contacts in the HR92, which I've had to re-tension on 3 HR92's now)

I'm happy at least that it seems to be functioning normally now, whatever the underlying reason.

[The EVOHOME Shop]

Good news, glad its been resolved...

[Edinburgh2000]

Good news, glad its been resolved...

I would not want you to remove this from your list of 'issues' for the Evohome kit. I am still wary of my CS92 and regard it as a dodgy bit of kit. True, it seems to be working OK during the summer but let's see what happens when I put my heating back on again and there is a lot of RF traffic going to and from my boiler room.

I suspect that it is only the 'nerds on this forum' who are spotting overshoots on their CS92s. Those on the forum who are principally installers may cite no known problems. But that is probably because 'normal' users would not be aware of an overshoot by the CS92 and thus not report anything to their installer. Especially if, like mine, the DHW valve control is wired in series with a mechanical thermostat in an unvented cylinder, the user will not know (or care) whether the hot water heating is terminated by the CS92 reaching the set point or by the mechanical thermostat operating. Unlike we nerds, most users will not obsess over the controller to see the DHW temperature, so they will simply know that they have hot water when they expect it and will not identify any problem.

That could imply that, if a normal user would not see a problem, it is not a problem worth fixing. But I am still uneasy about the robustness of the CS92 control of my DHW heating and I would be very nervous if I did not have the mechanical thermostat as backup.

Please do not close your file on the CS92 overshoots just yet.