Evohome cylinder strap on sensor incompatible ?

[paulockenden]

For me the comfort factor is so much more important than the gas savings.

No more room temps ping-ponging around a hysteresis point. No more walking through the house feeling hot and cold points. No more rads that are either stupidly hot or stone cold. Now the rads are just warm enough to keep the rooms at the desired temp.

If you are only four days in it'll certainly get even better.

[HenGus]

I am getting communication errors on screen and in the log from the two BDR91 relays and but that aside everything is working as expected. I have other equipment running on 868MHz so I'm going to switch them off and see if that's the cause of the communication errors.

I'm pleased I discovered this forum, as the source of knowledge is invaluable.

Sorry if I am teaching you to suck eggs but, in my experience, the most likely cause of comms errors is BDR siting. The 300mm separation is a minimum. It took me 6 months to get an error free system with a lot of help/advice from the Honeywell team.

[DBMandrake]

Sorry if I am teaching you to suck eggs but, in my experience, the most likely cause of comms errors is BDR siting. The 300mm separation is a minimum. It took me 6 months to get an error free system with a lot of help/advice from the Honeywell team.

I'm about to go from one BDR91 to three when I do my S Plan conversion - and there is a 100 litre hot water cylinder in the boiler closet and a fairly restricted number of places to mount the relays so achieving a 300mm separation between the individual relays and the metal of the hot water cylinder may be difficult to impossible... should be interesting! (I also have to squeeze the CS92 in there somewhere)

[g6ejd]

Sorry if I am teaching you to suck eggs but, in my experience, the most likely cause of comms errors is BDR siting. The 300mm separation is a minimum. It took me 6 months to get an error free system with a lot of help/advice from the Honeywell team.

I'm sure my problems could be associated with siting, but in my experience copper being non-ferrous and of ultra low magnetic permeability, the impact should be minimal. For example it is not unusual to shield RF sources from external RF or electrostatic effects using copper but still allow the transmitter to operate. I will probably fit some ferrite beads (well proper RF suppression clamps) to the BDR91 supply cables.

I also suspect like many low power RF devices, the 868MHz transceivers like nearly every 433Mhz (note 2 x 433=866Mhz! and the band is actually 433-434Mhz) unit on the market, do-not use a traditionally filtered front-ends, choosing the undertake digital filtering then sampling with so-called SDR radios, which results in blocking of the front-end by a nearby source such as another BDR91, however, that ought to be resolved by a re-transmission which it appears the system does on the basis that statically both will not re-Tx again at the same time and other factors. Paradoxically I could add a ferrous material shield between the two units, to help reduce that effect. Siting near metal objects with these low-power devices is usually a good thing, as you get induced currents and in-effect improved range from what would be an antenna, so my money is on receiver front-end blocking due to close proximity, hence Honeywell's recommendation to separate the BDR91's by 30cm or more.

My house is festooned with transmitters of various types and I suspect that's my problem, but I've lived with that for years, so eventually I will find a solution, if nothing else I'll site the Controller within a couple of metres of the BDR91's.

Wednesday night is my wife's friends night = house full of women and me and the dog confined to my study/shack, well to my surprise tonight they all heard the valve's operating and were intrigued as to what they were doing and why, but all commented how much warmer and even the room was as there was none of the normal swings in temperature, so again I'm really pleased with this system - before the lounge would overheat with their body heat (gassing ), that would close down the TRV's then it would cool down and get too hot again and so-on, but thankfully all that has now gone.

[g6ejd]

Almost certainly the reason for sending two additional readings spaced only 10 seconds apart after the set point is crossed is to deal with the situation of a lost transmission - since there are no acknowledgements if only one was sent and there was a collision, the relay would not switch off and the cylinder would continue to heat for another 8 minutes until the next periodic transmission, causing an overshoot in the temperature.

Two additional transmissions makes the chance of all three transmissions being lost extremely remote, so at worst the relay turning off will be delayed about 20 seconds.

When the temperature is not crossing the set point it sends a periodic update which seems to be approximately every 8 minutes. Which explains why the reading updates so infrequently when the set point is not being crossed - which will be done for battery conservation reasons.

So as far as controlling the temperature goes the system seems to work well and should be very responsive and accurate, however the displayed temperature on the screen may lag a long way behind actual temperature if it has not recently crossed the set point.

I've been thinking about the operation because I have been getting communication errors reported by the controller, but if it was a broadcast command protocol how would it know there has been a communication error, either it issued a command that was not acknowledged or there has been no change in water temperature since the command was issued or the transmission received from the CS92 had an error. On balance transmission errors must always happen, or no system changes would be normal following a command, so I think its reasonable to assume it is a 'connected' protocol that uses command and acknowledgements.

[paulockenden]

Or maybe corrupted packets?

[g6ejd]

Yes corrupted packets could be a cause, but I'd expect it to not report them and try again, which is what makes me think it is a connected protocol not a broadcast system. With broadcast it has to assume the packets arrived, but with connected it would expect an acknowledgment and then if it does not get one, then report a fault in the unit, which is what it's doing.

The Honeywell instructions paraphrasing from the Evohome Shop web site are more like Installers minimalist documents for use by a trained installer rather than User documents. I expect the average user when they see on-screen faults, would call their maintainer, when in-fact it might be a momentary never to be repeated error. The documentation could usefully make reference to the faults and explain what's gone wrong, I don't believe they do, maybe I've missed other documents, but then I do admit in a true male engineer fashion that I have not yet read the manuals

[bruce_miranda]

My bigger grip with the faults are that unless you are fortunate enough to look at the controller during an error event there is no way of knowing that a fault had occurred, including battery warnings. The front screen should have had an icon that a new fault has occurred prompting you to look at the log. Honeywell chose to instead use the screen real estate for an Optimisation prompt that never returns once you have played with Optimisation. The mobile app not being able to poll the error messages is another issue. So you never completely install the controller out of sight.

[g6ejd]

Agreed, maybe add this to the request in this forum for things that customers would like to see in future releases/updates.

[HenGus]

My house is festooned with transmitters of various types and I suspect that's my problem, but I've lived with that for years, so eventually I will find a solution, if nothing else I'll site the Controller within a couple of metres of the BDR91's.

It's never that simple. My original installation had the 2 BDRs separated by 300 mm on the right hand side wall of my airing cupboard - about a Metre above the wall-mounted controller. There was very little metal etc in the direct line of sight. The BDRs are now located on the right hand side of my airing cupboard 300mm or more above an unvented cylinder. The BDRs now work as they should with no comms outages.

My Honeywell Connected Specialist told me that, due to a lack of space, his BDRs were located next to each other and they were working just fine.

[paulockenden]

The spacing thing is a huge issue. It's incredible that the RF comms is this susceptible to interference.

I once considered mounting each BDR91 in a screened metal box....

... until 5 seconds later when I realised the flaw in that plan!

[g6ejd]

AintBigAintClever on YouTube has confirmed my suspicions because he shows what's inside the controller and there are no conventional RF components visible, telling me like most of these products that the receiver front end is a wide open to the RF spectrum and what these receivers do is process any signal at their front end, so no selectivity such that two transmitters on the same or near-by frequencies will be received as if they are valid, just like the 433Mhz units used world wide, this means that a nearby unit will block the front-end and prevent communications, usually solved by increasing spacing from the near field; comprehensive error detection, checking and correction and two-way protocols. Typically designers us off-the-shelf transceiver designs then integrate these into their design and hence these issues. For the most part they work well, but what with 868 being the 2nd harmonic of 433 then problems abound, let alone when customers have 868Mhz equipment too.

Often these little 868MHz receivers use a fast-Fourier transform to convert signals from the time to frequency domain, then select the desired signal with a digital filter, then demodulate it to a data stream, but the FFT routines are not that selective either, hence compounding the problems. When I compare the front end circuit used by Honeywell to my UHF transceiver they are orders of magnitude different in complexity - the Evohome unit has nothing to prevent in-band or co-channel interference, but of course budget driven.

My Davis Weather station uses 868Mhz, so I'm running a trial later today with it switched off to see if that makes a difference, but I have to get up and disable the remote sender as the base unit is receive only. I'll report the outcome of 6-hours of testing later today.

[g6ejd]

I've left the controller in the same position where it was reporting an average of 3 communication errors a day since installation and have fitted EMC filter clamps to the supplies of the BDR91's and turned off my weather station and since 12:30 today there are no reported errors, so tomorrow I'll switch back on the (868Mhz) weather station which sends an update every 2-secs and I'm expecting some of the errors to return, but hopefully not with a nice clean supply to them.

[bruce_miranda]

There appear to be good and bad days wrt the comms issues. So run each test for longer and report back. I'd be interested to hear your results.

[DBMandrake]

Has anyone looked at the design of the "antenna" on the board ? Is it vertical or horizontal polarisation ?

If it's horizontal, the unit will be sensitive to its orientation relative to the controller in the yaw axis - perpendicular to the controller should give the best signal. If it's vertical it shouldn't matter which way it is oriented in the yaw axis.