And the latest hot water "comms fault":
Here is what my monitoring system has received from the DHW sensor from 12pm up until 7:44pm:
As can be seen, it received a temperature update at 6:50pm - about 38 minutes before the comms fault was reported at 7:28pm. Given that it's normal for the hot water sensor not to send anything for up to an hour when the temperature is not changing this should not cause a comms fault - if the Evotouch received this message at 6:50pm. The next one before that was 5:57pm, approx 1 1/2 hours before the comms fault was logged.Code:2020-09-16T12:03:55.595943 || DHW:CS92A | Evotouch | RQ | dhw_params | 0015020... || {'setpoint': 53.78, 'overrun': 0.0, 'differential': 4.98} 2020-09-16T12:03:55.612421 || Evotouch | DHW:CS92A | RP | dhw_params | 0015180... || {'setpoint': 54.0, 'overrun': 0.0, 'differential': 5.0} 2020-09-16T12:43:27.849412 || DHW:CS92A | <announce> | I | dhw_temp | 00134D || {'temperature': 49.41} 2020-09-16T13:33:43.178648 || DHW:CS92A | <announce> | I | dhw_temp | 0012E5 || {'temperature': 48.37} 2020-09-16T14:33:12.556016 || DHW:CS92A | <announce> | I | dhw_temp | 001281 || {'temperature': 47.37} 2020-09-16T14:36:28.581228 || DHW:CS92A | <announce> | I | dhw_temp | 001377 || {'temperature': 49.83} 2020-09-16T14:37:13.594957 || DHW:CS92A | <announce> | I | dhw_temp | 0013DF || {'temperature': 50.87} 2020-09-16T14:38:28.590636 || DHW:CS92A | <announce> | I | dhw_temp | 001447 || {'temperature': 51.91} 2020-09-16T14:40:43.602872 || DHW:CS92A | <announce> | I | dhw_temp | 0014C2 || {'temperature': 53.14} 2020-09-16T14:42:58.629919 || DHW:CS92A | <announce> | I | dhw_temp | 00152A || {'temperature': 54.18} 2020-09-16T15:42:13.016563 || DHW:CS92A | <announce> | I | dhw_temp | 001513 || {'temperature': 53.95} 2020-09-16T16:03:57.163585 || DHW:CS92A | Evotouch | RQ | dhw_params | 0015020... || {'setpoint': 53.78, 'overrun': 0.0, 'differential': 4.98} 2020-09-16T16:03:57.180186 || Evotouch | DHW:CS92A | RP | dhw_params | 0015180... || {'setpoint': 54.0, 'overrun': 0.0, 'differential': 5.0} 2020-09-16T16:18:44.255765 || DHW:CS92A | <announce> | I | dhw_temp | 0014C2 || {'temperature': 53.14} 2020-09-16T17:07:59.570439 || DHW:CS92A | <announce> | I | dhw_temp | 00145A || {'temperature': 52.1} 2020-09-16T17:57:44.899303 || DHW:CS92A | <announce> | I | dhw_temp | 0013F3 || {'temperature': 51.07} 2020-09-16T18:03:43.939994 || DHW:CS92A | <announce> | I | device_battery | 00FF01 || {'battery_level': None, 'low_battery': False} 2020-09-16T18:03:44.938888 || DHW:CS92A | <announce> | I | device_battery | 00FF01 || {'battery_level': None, 'low_battery': False} 2020-09-16T18:50:30.229182 || DHW:CS92A | <announce> | I | dhw_temp | 00138B || {'temperature': 50.03}
While preparing the screenshots for this post the fault rectified itself at 7:50pm, and the following CS92A messages have been received by my monitoring system after 7:44pm:
The transmission at 7:50pm matches when the fault was "restored".Code:2020-09-16T19:50:14.628982 || DHW:CS92A | <announce> | I | dhw_temp | 001327 || {'temperature': 49.03} 2020-09-16T19:54:45.653415 || DHW:CS92A | <announce> | I | dhw_temp | 001310 || {'temperature': 48.8} 2020-09-16T19:59:00.675498 || DHW:CS92A | <announce> | I | dhw_temp | 00138B || {'temperature': 50.03} 2020-09-16T20:00:00.687402 || DHW:CS92A | <announce> | I | dhw_temp | 00140A || {'temperature': 51.3} 2020-09-16T20:02:00.697454 || DHW:CS92A | <announce> | I | dhw_temp | 001485 || {'temperature': 52.53} 2020-09-16T20:03:58.724210 || DHW:CS92A | Evotouch | RQ | dhw_params | 0015020... || {'setpoint': 53.78, 'overrun': 0.0, 'differential': 4.98} 2020-09-16T20:03:58.740686 || Evotouch | DHW:CS92A | RP | dhw_params | 0015180... || {'setpoint': 54.0, 'overrun': 0.0, 'differential': 5.0} 2020-09-16T20:04:30.720909 || DHW:CS92A | <announce> | I | dhw_temp | 0014FF || {'temperature': 53.75} 2020-09-16T20:06:15.734409 || DHW:CS92A | <announce> | I | dhw_temp | 001567 || {'temperature': 54.79}
So either the Evotouch didn't receive that message at 6:50pm which was received by my monitoring system, or it reports comms faults far too quickly when it hasn't received a message in a long but normal length of time.
Perhaps someone from Honeywell can confirm what the length of time should be between the last received CS92A temperature and a comms fault being logged ? In older firmware versions I was under the impression this was 3 hours, however it seems as if this length of time has been reduced in more recent firmware versions...(which would result in more false lost comms which then quickly correct themselves) either that or it has missed receiving multiple CS92A temperature updates in a row in the prior 3 hours!
Last edited by DBMandrake; 16th September 2020 at 08:22 PM.
But surely if the Evotouch had a poor receiver then similar faults would be reported from HR92s etc. And not just the HW sensor. I believe your own earlier researches showed the HW sensor is weak. I changed to lithium batteries some months ago. I don’t get as many faults reported as was used to, I still get them though, just not so frequent.
In my 6 years of use the one device that throws up a loss of contact is the HW sensor. Nothing else does produce a fault unless it is a battery going down.
Exactly the same here. I have 8x HR92's and ONLY the CS92A HW Sensor ever reports a Comms Failure, which can be months apart or 2 in the same day !!
The Comms Failures are mainly overnight, but not always.
[My system was installed by a Honeywell approved EVO System Specialist in mid 2014.]
Last edited by DerekWilliamsUK; 18th September 2020 at 08:10 AM.
That was what I thought before I set up a 24/7 independent monitoring system to monitor the wireless transmissions. And it has shown conclusively that in every case where I'm getting a "comms fault" from the CS92A (which is triggered by the Evotouch not receiving temperature updates within a certain amount of time - which used to be 3 hours) my independent monitor is receiving the transmissions. Every time. This is contrary to what I originally expected to find.
It's true that the CS92A might have a weak transmitter, but if my other device can receive it (positioned near the Evotouch) the Evotouch should be able to receive it too. In fact my device has another wall to go through as it's sitting inside the hallway cupboard near the Evotouch which is sitting on the hallway wall. So it's already at a disadvantage to the Evotouch with another wall in the way and yet it receives the messages OK.
HR92's send updates much more frequently than the hot water sensor. When the temperature isn't changing the hot water sensor only sends an update hourly. HR92's send at least once every 20 minutes, and if the temperature is changing more frequently than that. More frequent transmissions greatly reduce the chance of not receiving anything for a long period of time. The system is designed to cope with the occasional lost message - it happens from time to time and unless you are scrutinising the system very carefully you will not notice it.In my 6 years of use the one device that throws up a loss of contact is the HW sensor. Nothing else does produce a fault unless it is a battery going down.
I haven't had reported comms errors with HR92's before but I have certainly had the occasional comms error with BDR91's.
Last edited by DBMandrake; 18th September 2020 at 09:53 AM.
The initial installation of my HW sensor was on the other side of a stud and plaster wall, less than 0.5m from the Evotouch and gave frequent comms faults. It was moved to the other side of the airing cupboard, so now about 1m from the Evotouch, and this gives less comms faults, so signal strength does not appear to be my issue. I have never had comms problems with any other devices. This does support DBMandrakes theory that it could be a timing issue with communications between the Evotouch and the HW sensor.
Edit. Battery power does not appear to be relevant as I have seen comes faults with new batteries and they do not increase as the batteries age.
Last edited by CT1; 18th September 2020 at 12:52 PM.
...and I now have another hot water quirk to resolve. Earlier this week my 3-way valve and control unit were replaced. My engineering skills of hitting the valve with a hammer to free it were being requested to often. After all was done, a check was made to see that it worked. The heating was switched on in the app etc. All fine. But, the next morning the HW was not heated. It is set to come on at 06:30 for an hour. The app and the Control Panel both said it was on but the boiler had not fired up. The BDR91 showed “off”. I switched it on manually. No problem. At the set time for off it went off. As it should. It fires up twice a day and it worked fine in the evening. The next two mornings the same it would not switch on at 06:30 but any other time it works fine. Not a temperature sensor issue but certainly a communication one but at the same time 3 days running. I’ll change the set time and see if that cures it!
Addendum.
I reduced the on time to 30 minutes, as that is more than enough to get the water up to 55C, resetting the start time. It worked! Not having used the Control Panel much for some time I was reminded how slow and laborious it is. Making changes is like walking in mud. We are spoilt by the touch sensitivity of our modern devices. But then the Control Panel is meant to be a modern device!
Last edited by G4RHL; 19th September 2020 at 09:50 AM.
So after a week or so of perfect operation, no changes, and two overshoots in as many days. Deep joy, just when I thought I’d cracked it!