Page 8 of 11 FirstFirst ... 34567891011 LastLast
Results 71 to 80 of 109

Thread: S-Plan vs Y-Plan for Evohome ?

  1. #71
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Quote Originally Posted by paulockenden View Post
    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.
    Last edited by DBMandrake; 14th November 2016 at 10:50 AM.

  2. #72
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    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!

  3. #73
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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.

  4. #74
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    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/asse...nal_report.pdf

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

    http://www.domoticaforum.eu/viewtopi...lit=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!

  5. #75
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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.

  6. #76
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Hmm, this sounds eerily familiar....

    http://www.automatedhome.co.uk/vbull...ing-Controller

    Especially the part about frequent updates after rebooting the CS92 (by re-inserting the batteries) which then over time taper off to infrequent updates...

    Reading that thread I wonder if there is something to one of my previously expressed theories after all - the theory of deliberate power saving through less transmission when battery voltage is low. If that's the case it might be worth trying lithium batteries instead of Alkaline in the CS92 because not only do they start at a significantly higher terminal voltage than Alkaline, they maintain a much more constant voltage during discharge whereas an Alkaline tends to fall progressively with use.

    So even though the CS92 no doubt only uses a tiny amount of power, the higher and flatter terminal voltage of a lithium might be beneficial, as it would tend to avoid any such low voltage power saving mode from being entered.

    Come to think of it I haven't even checked the voltage of the batteries that were shipped, but will do so tonight. And I might put it back to its original wall location but with Lithium's installed to see what happens.
    Last edited by DBMandrake; 22nd November 2016 at 02:37 PM.

  7. #77
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Time for an update - I left the CS92 in the new wall location with the original batteries and it has worked nearly flawlessly for the last month. I say nearly because there were very rare occasions (twice I think, in a whole month) where I got an overshoot to 62 degrees. I believe these occasions were probably due to lost transmissions (comms errors, interference etc) rather than the CS92 deciding not send anything. Unfortunately I now have a loop transmitter in the same closet as the CS92 which operates on the same frequency band so this muddies the waters slightly in the event of rare transmission errors as I can't prove that it's not the loop to blame. But overall I was satisfied that it was working at about 99% reliability.

    Until yesterday, when I decided to increase my hot water temperature from 50 to 55, when it immediately started playing up again.

    The current measured temperature was 51 degrees when I went into the installer menu and changed hot water from 50 to 55. I then ran the hot tap for a few minutes to get it to drop down to about 49, at which point (due to my 5 degree differential) it kicked into heating mode.

    I happened to notice the reading on the controller creeping up from 49->50->51 and then stop at 51. Quite some time later (probably at least 20 minutes) I glanced at it again and saw it reading 62. Grr...

    My first suspicion was that although the hot water temperature was changed on the controller it did not for some reason communicate this change to the CS92, at least not in a timely fashion - therefore the CS92 stopped sending frequent updates after the temperature went past the old set point of 50 degrees.

    I also have a suspicion that there is a "safety threshold" programmed into the CS92 that causes it to ALWAYS send an immediate temperature measurement to the controller any time the water temperature goes past 62 degrees, regardless of what the set point is. This would probably be to ensure that the hot water can't get to a dangerous temperature, and 62 is slightly above the default hot water temperature of 60 degrees, so that makes sense.

    It's too much of a coincidence for the hot water to overshoot to exactly 62 every time overshoot has occurred, regardless of whether the hot water is set to 50 or 55.

    About an hour later I decided to conduct a test - I scheduled hot water off and left the hot tap running to completely use the hot water, (the reading dropped to about 13) I then turned hot water back on again and waited. Once again once the temperature reached about 45 I saw frequent temperature reading updates 45->46->47->48->49->50->51 and then no more updates past 51 for a long time then eventually it jumped from 51 to 62, so again, another overshoot to 62.

    I then rebooted the controller, and then the CS92 in that order and repeated the same test of draining the hot water and letting it heat up again. This time I didn't start to see frequent temperature updates until nearly 50 degrees, and saw readings of 50->51->52->53->54->55 and then the hot water switched off as expected.

    Since yesterday it has reheated to 55 degrees in normal use probably a dozen times without any problems, stopping on 55 or 56 every time.

    So my conclusions are:

    1) The CS92 definitely is made aware by the controller of what the hot water set point and differential is, and uses this information to send much more frequent updates when the temperature is changing within this range, especially as the temperature increases and the shut off temperature is reached. This is to avoid overshoots.

    2) There appears to be a hard coded safety threshold of 62 degrees whereby the CS92 always sends a temperature update when 62 is passed regardless of what the hot water set point is. This is why all the overshoots end up at 62 degrees and not some random high temperature.

    3) For some reason changing the hot water set point on the controller did NOT immediately inform the CS92 of the change - it perhaps either sends it much later (once a day ?) or only sends it once such that a comms error could cause it not to be received and then never update. Even an hour after I changed the setting the CS92 appears not to have registered the change.

    4) Rebooting the controller or the CS92 (I don't know which) forced the new hot water set point to be updated in the CS92. After this the system performed as expected. I didn't bother rebooting only one then testing then rebooting the other to verify which reboot helped, but I could do that I suppose if there was interest.

    Conclusion - it looks like there is a bug in the Evotouch that causes the CS92 not to be informed in a timely and reliable fashion of a new hot water set point when you change it, which can lead to overshoots to 62 degrees due to the two devices not agreeing on what the hot water set point is. Even if you only raised your set point a couple of degrees this situation could be triggered.

    The workaround is to reboot both the controller then the CS92 after changing your hot water temperature!
    Last edited by DBMandrake; 29th December 2016 at 06:36 PM.

  8. #78
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,633

    Default

    I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.

  9. #79
    Automated Home Legend
    Join Date
    May 2014
    Posts
    998

    Default

    Quote Originally Posted by paulockenden View Post
    I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.
    I have changed the HW temperature a number of times over the past 3 years - and the differential - and never had an issue with temperature overshoots. My present tank temperature is set at 62C as I have a temperamental thermostatic shower.

  10. #80
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Quote Originally Posted by paulockenden View Post
    I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.
    Nope - as I described in my first test I scheduled hot water off for the period of time that I ran the tap to use all the hot water, (about 20 minutes) mainly to avoid the boiler from trying to heat it back up while I was trying to use it. I then scheduled hot water back on and it overshot to 62 degrees.

    Quote Originally Posted by HenGus View Post
    I have changed the HW temperature a number of times over the past 3 years - and the differential - and never had an issue with temperature overshoots. My present tank temperature is set at 62C as I have a temperamental thermostatic shower.
    Set at 62 degrees you wouldn't have an issue, because it seems the CS92 always sends an update at 62 degrees anyway.

    I'm not saying that this problem always happens when the hot water temperature is changed, and maybe eventually it would have sorted itself out. But there is definitely a case where changing the hot water temperature can lead to the controller and CS92 getting their set points out of step with each other, and this can lead to overshoots.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •