S-Plan vs Y-Plan for Evohome ?

[g6ejd]

I'm interested in this. When I received my (new) CS92 I too had operation problems with it not sending a temperature and started by thinking I'd been send a customer returned unit as the battery clips were misaligned, so with my meter I started checking the battery connections which were solid, although those contacts could have been better because if I gave the unit a shake the batteries would fall out quite easily unlike the HR92's or Controller so I was a little surprised at the difference in quality/construction, as there is a very low spring force holding the batteries in-place. I then worked back disassembling the unit as I went, applying switch contact fluid to those pads as I routinely do to any device with that arrangement to help reduce oxidisation problems (not that there should be with gold contacts) and reassembled and it worked, so I presume I never had temperature overshoots, but at install (NOOB) it definitely was not reporting temperature, then post my fiddling it was and has worked OK since.

Thanks for posting this, as it confirms there was probably a wider issue and my tweaking of the CS92 contacts was not an isolated case. To be honest, faced with getting the system working or delaying that until I got a replacement drove me to adjust the mechanicals of the CS92battery connections, but at least I know how to get it apart following my 'don't switch it on, take it apart' approach to most things

[DBMandrake]

This is more for Simon.

Looking through the Domoticz logs (remember I use an HGI80) it appears the controller repeats the current on or off command to the DHW BDR91 every 20 minutes.

2016-11-02 23:49:53 Off
2016-11-02 23:29:48 Off
2016-11-02 23:09:45 Off
2016-11-02 22:49:43 Off
2016-11-02 22:29:42 Off
2016-11-02 22:09:37 Off
2016-11-02 21:49:36 Off
2016-11-02 21:29:31 Off
2016-11-02 21:09:29 Off
2016-11-02 21:04:16 On
2016-11-02 20:44:16 On
2016-11-02 20:24:14 On
2016-11-02 20:04:29 Off
2016-11-02 19:44:28 Off
2016-11-02 19:34:44 On
2016-11-02 19:21:38 Off
2016-11-02 19:01:34 Off
2016-11-02 18:41:32 Off
2016-11-02 18:21:28 Off
2016-11-02 18:01:26 Off
2016-11-02 17:41:22 Off
2016-11-02 17:01:17 Off
2016-11-02 16:41:14 Off

Etc.

Just had what I believe is a confirmed instance of a lost heat demand signal to the boiler relay.

At 11pm our set points change - most rooms in the house go off and the bedroom drops a few degrees so heat demand should stop.

At 11:12pm I saw the "boiler control" relay click back on for a few minutes even though all zones were at least 2 degrees above their set points. I checked the heating and hot water relays (I use a 3x BDR91 config) and neither one of them was lit for the period that the boiler relay was.

I can't see any reason why the system would deliberately turn on the boiler relay for about 3 minutes but not turn on either of the zone valve relays.

So I think its pretty clear that what happened is that the heat demand has completely ceased with the schedule change, the duty cycle of the heating zone valve BDR91 was successfully set to 0% some time between 11pm and 11:04pm however the message to set the boiler control BDR91 to 0% sent at about the same time did not get through for some reason - thus the boiler relay continued merrily with its most recent duty cycle, which would have been about 30%.

From what you've posted above it looks like BDR91 heat demands are re-sent every 20 minutes so I expect that some time around 11:20 the heat demand message will be re-sent and get through, and the boiler control relay will go off and stay off.

The interesting thing is I only noticed it because I have a three relay config and there is some sanity checking I can do to see if two relays are coming on together - because apart from hot water overrun (which I have turned off anyway) there should never be just one relay on by itself. It should always be the boiler control relay in conjunction with one or both of the zone valve relays. A boiler relay or heating zone relay on by itself is a sign something isn't right.

With a single relay heating only configuration or an S-Plan configuration using two relays, you would never directly realise that the boiler was continuing to fire when it shouldn't be. Or potentially that it didn't fire when it should have.

I think this explains the occasional reports we see of people turning off their heating and the boiler relay continuing to cycle on and off well past the 5 minutes that it should take for everything to shut down. If one transmission gets lost it looks like the boiler relay would continue at its previous duty cycle for another 20 minutes but after that (unless you were really unlucky to lose the following transmission as well) it would right itself.

[DBMandrake]

Confirmed - the boiler relay did not come back on again after about 11:20pm and my 12 minute pump overrun timer has since expired, confirming that the relay was off for at least a whole 10 minute TPI cycle.

[g6ejd]

Interesting observation it confirms what happens to my system, which I solved by using Optimum Stop or more recently (from my neighbours Evohome experience) having at least two zones go off at different times, so I set our Shower Room to go off at 23:10 and the rest of the house at 23:00, if I don't do either of these measures it cycles continuously, but as the radiators are all off and the flow through the ABV is low (set by a gate valve) the boiler does not ignite due to insufficient water flow rate, so it's an annoying pump cycle for us. What's odd is that two relatively new systems (mine and my neighbours) both do the same thing. I presume Honeywell advised him to separate the zone off times, because as soon as I told him what my system was doing he said add a new off time, sounds like a software issue to me. His system is 1.02 mine 1.03.

[paulockenden]

You REALLY need an HGI80 Simon. I can't help thinking that someone with your determination and enthusiasm could end up discovering so much that would be of benefit to the whole community.

Do you want to borrow mine for a few weeks?

[DBMandrake]

Thanks for the offer Paul but despite appearances to the contrary (lots of long forum posts ) I'm going to be pretty tied up the next few months and won't really have the time to make good use of it.

I will get one of my own eventually though, maybe in a few months time. I'll ferret away a little bit of money for it and patiently watch for a bargain to come up...

[paulockenden]

You sound like you're about to be detained at Her Majesty's pleasure! ;-)

[DBMandrake]

I happened to be up early this morning when the hot water was scheduled to come on and I noticed that the reading on the controller seemed to be stuck at 33, which is the temperature it had sat at most of the night as unlike most nights where the hot water is up to temperature when it goes off at 9pm, and gradually drops through the night, there was quite a bit of hot water used after the scheduled off time causing the reading to drop down to about 33 by bed time.

I watched this for a while worried that I was about to see another overshoot but no - after some 20 minutes the reading jumped suddenly from 33 to 50 (actual readings according to Domoticz, 33.5 and 50.9) and the hot water shut off. So no problem with overshoot at all.

I think we can deduce from this that if the temperature is a long way below the set point and stays almost constant (not much heat loss will occur when the cylinder is already down to 33) the sensor goes to sleep and stops sending updates for extended periods of time to conserve battery life, and even when the temperature does start to change, when it is in this sleep mode it still doesn't send an update for quite a while. (unless the set point is crossed)

It also seems to prove my theory that the CS92 itself "knows" what the hot water set point is, and will wake up and send an immediate update when the set point is crossed regardless of any sleep mode currently in force - otherwise why would it suddenly jump from 33 to 50 at the exact time that the cylinder did in fact reach 50 degrees ? Crossing the set point must be a trigger that always wakes it up and sends an update.

When not sleeping it seems to send an update for every 1 degree of temperature change, which is borne out by my Domoticz graph CSV export which in most cases shows it reporting every 1 degree change during a re-heat.

It also occurs to me that my original problem with overshoots which I suspect was caused by the CS92 randomly rebooting, might be due to the CS92 forgetting my hot water set point until it is refreshed at a later time by a transmission from the controller - if it forgets the set point (or goes back to some default set point that does't match MY hot water set point, like 60) then it wouldn't wake and send an immediate update when MY set point was crossed, hence sometimes the target would be missed.

That makes a lot of sense. Some time after it randomly reboots the controller sends a periodic refresh to the CS92 informing it of what MY hot water set point is, and then until the next time it reboots it works properly again. But if the reboots from the poor battery connection become frequent it will overshoot quite often.

Does anyone remember what the default hot water temperature was ? I have a feeling it might have been 60...

[DBMandrake]

I'm rather disappointed to report that after perfect operation for so long I got a 62 degree overshoot again this morning

Hopefully this is a one off, not a return to previous form, however I have noticed that the sensor does seem to be reporting infrequently again. The only things that have changed recently is I reduced the reheat flow temperature from 78 to 70, so it does take a bit longer for a reheat now, (but didn't seem to cause an issue) and the day before the problem I did increase the hot water temperature to 55 for about an hour, decided I found that too hot and set it back to 50 again. Whether that is related or not I don't know.

Here is the overshoot in question:

2016-11-13 06:35:00,0,2016-11-13 06:35:00,38.48
2016-11-13 06:40:00,0,2016-11-13 06:40:00,38.48
2016-11-13 06:45:00,0,2016-11-13 06:45:00,38.48
2016-11-13 06:50:00,0,2016-11-13 06:50:00,37.16
2016-11-13 06:55:00,0,2016-11-13 06:55:00,37.16
2016-11-13 07:00:00,0,2016-11-13 07:00:00,37.16
2016-11-13 07:05:00,60,2016-11-13 07:05:00,37.16
2016-11-13 07:10:00,60,2016-11-13 07:10:00,37.16
2016-11-13 07:15:00,60,2016-11-13 07:15:00,45.34
2016-11-13 07:20:00,60,2016-11-13 07:20:00,48.64
2016-11-13 07:25:00,60,2016-11-13 07:25:00,48.64
2016-11-13 07:30:00,60,2016-11-13 07:30:00,48.64
2016-11-13 07:35:00,60,2016-11-13 07:35:00,48.64
2016-11-13 07:40:00,60,2016-11-13 07:40:00,48.64
2016-11-13 07:45:00,60,2016-11-13 07:45:00,48.64
2016-11-13 07:50:00,60,2016-11-13 07:50:00,48.64
2016-11-13 07:55:00,60,2016-11-13 07:55:00,48.64
2016-11-13 08:00:00,60,2016-11-13 08:00:00,48.64
2016-11-13 08:05:00,60,2016-11-13 08:05:00,62.06
2016-11-13 08:10:00,60,2016-11-13 08:10:00,62.06
2016-11-13 08:15:00,60,2016-11-13 08:15:00,62.06
2016-11-13 08:20:00,60,2016-11-13 08:20:00,62.06
2016-11-13 08:25:00,60,2016-11-13 08:25:00,62.06
2016-11-13 08:30:00,60,2016-11-13 08:30:00,62.06
2016-11-13 08:35:00,60,2016-11-13 08:35:00,62.06
2016-11-13 08:40:00,60,2016-11-13 08:40:00,62.06
2016-11-13 08:45:00,60,2016-11-13 08:45:00,62.06
2016-11-13 08:50:00,60,2016-11-13 08:50:00,62.06
2016-11-13 08:55:00,60,2016-11-13 08:55:00,62.06
2016-11-13 09:00:00,60,2016-11-13 09:00:00,62.06
2016-11-13 09:05:00,60,2016-11-13 09:05:00,60.41
2016-11-13 09:10:00,60,2016-11-13 09:10:00,60.41
2016-11-13 09:15:00,60,2016-11-13 09:15:00,60.41
2016-11-13 09:20:00,60,2016-11-13 09:20:00,60.41

Hot water was scheduled on at 7:00am, there was a temperature update at 7:15 of 45.34, one at 7:20 of 48.64 and then no changes reported until 5:00am - a full 40 minutes later, by which time the reading was 62 degrees. Why the sensor did not report any changes for a full 40 minutes even though it knew the water was heating (albeit more slowly at the lower flow temp) is beyond me. This is NOT normal behaviour.

I guess I have no choice but to watch and see if it happens again, but it doesn't give me good confidence in the reliability of the CS92 that 40 minutes can go by with a 14 degree temperature increase with no incremental temperature updates while the water is heating...

[paulockenden]

But IS it that the sensor didn't report, or is it that the controller missed the message? Without an HGI80 you won't know.

[DBMandrake]

But IS it that the sensor didn't report, or is it that the controller missed the message? Without an HGI80 you won't know.

You're absolutely right, I don't really know.

It does seem a lot more likely that it's the sensor misbehaving though, as I never have reported comms faults to HR92's or BDR91's, and have only quite rarely observed any behaviour that would suggest lost messages around the system, like the occasional BDR91 running on when I believe it shouldn't.

I think if the sensor was sending an update for every degree change during heating and at variable time intervals - as it seemed to be doing a few days ago when it was working 100%, then it would be extremely unlikely for 5 or more messages in a row to not be received by the controller due to collisions, interference etc, and yet not have any other devices experience any problems. As far as I'm aware nothing else is malfunctioning when the hot water is overshooting. It's much more likely that the CS92 (which we know must use power saving heuristics to decide when to send) just didn't send updates for a while for some reason.

My concern is that I'm about to install loop in a few days (just waiting for it to arrive) and the gas sender for that will be about half a metre from the CS92 and will be operating in the same 868Mhz band, and this will potentially muddy the waters from a diagnostic point of view as I am introducing another uncontrolled variable to the situation. So even though the problem was there prior to installing loop I can imagine any official troubleshooting support from Honeywell would start by them asking me to temporarily remove loop! (And I can see their reason to ask - there's nothing to say that there couldn't be two sources of interference instead of just one once loop is added)

I will get an HGI80 eventually but it will have to wait both for time and monetary reasons, I've spent a lot more time on the S-Plan conversion than I should have had to so if it just misbehaves once a week I'll just live with that for now until I can get the time to set up an HGI80 and investigate properly.

[DBMandrake]

Bother. On Saturday morning I actually had a comms fault on the hot water sensor.

It happened just a few minutes after hot water was scheduled to come on and I happened to be up and walking past the controller to notice a big red comms failure error on the screen (the first I've seen) and double dashes for the hot water temperature...

I went straight into boiler cupboard and pressed the button - 5 flashes indicating an excellent signal, and checked from the controller end as well - excellent. I took the battery out of the CS92 and put it back in, the controller immediately registered the temperature and turned the hot water relay back on - no more problems that day. Then on Sunday one overshoot.

One thing I've learnt from this is that the signal test mode on the Evohome system is....well..... worse than useless. It always cheerfully reports excellent signals even on systems experiencing problems. And it's really no help in deciding where is or isn't a good place to locate a device - for that you need magic pixie dust.

With nothing else to try I've moved the CS92 to a different wall in the boiler closet, basically the only other possible location it could go without drilling a hole through a brick wall for the wire and running it into a different room. On this new wall its orientation is 90 degrees different to what it was before, it is quite a lot further from the BDR91's and a little bit further from the cylinder, but it is a worse vantage point for line of sight to the controller, and indeed the signal strength has dropped from Excellent to Good.

So if this helps it will be a good example of placement relative to other objects being more important than outright signal strength, if it doesn't work, then I don't know what it tells us, or what I should do.

I really get the impression that 10mW on 868Mhz just isn't a reliable medium - I'm having similar problems with loop from the same boiler closet - the signal reading reported by loop fluctuates anywhere from 3 bars down to nothing and lost connection then back again all with nothing being touched or moved anywhere. I've had to try reorienting the loop receiver twice now to get a connection to the gas sensor. (Luckily the loop stores data and has a retry mechanism to send it when the connection is re-established, unlike Honeywell!)

I don't know what houses these companies using 868Mhz tested in when they came up with the figure of 30 metres, but they must have had cardboard interior walls!

[g6ejd]

868MHz and 10mW - yes, it's very noble of Honeywell to meet the (stringent) standards and nothing less would be expected of them, but those standards are not workable or suitable IMO for the chosen application, the attenuation through most building materials and the greater number of Fresnel zones at that frequency (standing waves that cancel each other out (e.g. a signal from A to C and one that goes from A to B to C, arrive at the same time and cancel themselves out = 0) even though a high signal strength is being reported) all lead to an unreliable communication system that has to be compensated for by improved protocols, which aren't implemented I believe.

I've just calculated the Fresnel zone for 868MHz and 10mW (10dBM) and for a 15M maximum range, to my surprise the radius is 2.3M with the peak occurring 7.5M from the RF source, so I think it's a definite issue to consider and moving the BDR is a good decision. Here's a visualisation of the Fresnel stay-out zone:
fresnelzone01e.jpg

I notice the way they describe doing a site survey / pre-installation check with a BDR91 is telling as it recommends trying a variety of prospective locations and monitoring signal strength at each point to create a signal strength map of the property, when ordinarily with such short ranges in the majority of properties it would not be required, leading me to conclude there is a problem with the RF link.

[DBMandrake]

It's also interesting to note that while most of the 868Mhz band is limited to 10mW, the exact frequency Honeywell uses - 868.3 Mhz is actually within a slice that is allowed to use 25mW. See page 10 in this PDF:

https://www.ofcom.org.uk/__data/assets/pdf_file/0025/38095/final_report.pdf

You can find reference to the exact frequency in use through some reverse engineering here:

http://www.domoticaforum.eu/viewtopic.php?f=7&t=5806&p=46065&hilit=868#p46065

I could have sworn I read that it was 10mW in that thread but it must have been elsewhere. I'm also pretty sure I read that the transmit power is software programmable.

According to info in that thread both the older (then current) Black and White evotouch and the RFG1000 use the same CC1101 transceiver chip, for which spec sheets are readily available:

http://www.ti.com/product/cc1101

I'm not sure that other devices like the CS92 or BDR91 or new Evotouch for that matter use the same chip.

I've been giving some thought to the issue of devices being mounted too close to each other and why that might cause problems and I wonder if its something as simple as AGC response time in the receiver ? (Do these modern chip based receivers even have a concept of analogue AGC I wonder...or is it a broadband digitiser without any AGC in front of it ?)

As far as unrelated devices such as a CS92 and BDR91 are concerned (since they don't talk directly to each other) their immediate neighbour might at random happen to transmit a message it is not interested in immediately before a much more distant, wanted transmission is sent.

So say a CS92 was too close to a BDR91. The BDR91 is waiting for a distant signal from the controller but gets blasted by the CS92 which is only a few inches away... with attenuation following inverse square law if they're only a few inches apart or heaven forbid almost touching, the signal level could be very high indeed. What if this saturates the AGC in the receiver so that a weaker wanted transmission immediately following, just a few milliseconds later is lost because the gain is turned way down and hasn't had time to recover...

Most of the time it would work OK but if the timing was unfortunate and the nearby "blast" occurred just before the wanted signal it would still be "deaf". Move them a bit further apart and saturation of AGC wouldn't be as much of a problem - the recovery time would probably be a lot quicker and/or the change in gain might not be enough to cause the transmission to be lost anyway.

Makes sense to me, because for devices that aren't allowed to transmit for more than 1% of the time they sure are fussy about not being too close to each other by all accounts...

Your comment about standing waves is a good one too, depending on the precise location of each end of the link you could be unlucky and have the receiver sitting in a standing wave null - move it just a few inches and it may work fine again. Move a human body in the nearby vicinity and it might get better or worse too!

[g6ejd]

I think I've read too in Honeywell's brochures' along the lines of 'they are proud to announce achievement of the 10mW limit', but when they don't need to it does make one wonder why. Most RF chips are software programmable, but they will have been through type-approval, so adjusting it would almost certainly mean seeking re-approval with the higher RF power. IN the days of yore, not that long ago, maybe 5-years, the RF front-end would have been a nice clean design with tuned circuitry with huge out-of-band rejected of unwanted signals, now receivers have no AGC as such, they are almost exclusively a wide band front-end (you will not see any tuned components on most boards) that feeds a DSP (digital signal processor) than typically performs a Fast-Fourier-Transform to bring the signal into the frequency domain, to which digital filters can be applied and tuned to the required frequency (all hugely over-simplified), but front-end artefacts and a out-of-band signals can stop the receiver from working because they become the dominant front-end signal hence preventing the link from working, that said, for the most part it all works, especially if the protocol allows for a re-transmission (ETHERNET like) should the first transmission attempt not get through.

Yes, standing waves and Fresnel zones can be affected by movement of just a few cms, it just so happens that 868cms is ~35cm, the popular radio amateur band (440MHz is colloquially called 70cms) which just happens to be the same distance that Honeywell seek for inter-BDR separation, but that must be coincidence, I can't think of any other reason, other than as you suggest, when an adjunct BDR transmits, it blocks the other BDR receiver, which takes times to recover, typically many seconds.

I have my BDR91's now separated by the recommended width, but line of sight they are no more than 2M from the controller, so I don't expect any communication issues.

You could as a temporary measure do something similar and move the controller closer to the BDR's to see if that improves communication reliability. That said, I note there are a few recommendations that Honeywell make during the binding process, like moving the controller within I think 0.5M of a BDR or was it the CS92, which all indicates RF link problems are evident and this is how they solve them for a reliable bind.