Page 6 of 11 FirstFirst 1234567891011 LastLast
Results 51 to 60 of 109

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

  1. #51
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    What I don't understand is why with what appears to be a connected protocol, they cannot send and get confirmation back that a command has been implemented. I think my continuing problem of the heating not being turned off when the days' scheduled has ended (but Optimum Stop or at least two different end-times in schedule rather than all rooms off at the same time solves) has a similar genesis in that the BDR91 is not receiving the off signal, or is and is ignoring it for whatever reason.

    I'm currently a little hacked off with the system because having spent 1400 on Honeywell products and having called their Technical Support twice they do-not seem to care or be bothered that there are system issues that need fixing and IMO there is an endemic lack of positive control over the BDR91's, otherwise DHW would stop heating when it was supposed to and HTG would too.

    I'm trying hard not to get grumpy with Honeywell over this and I don't blame the supplier even though I have a contract of supply with them rather than Honeywell.

  2. #52
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    I think for hot water control the design of the hot water kit is fundamentally flawed from a systems design perspective to achieve reliable operation.

    At the moment the feedback loop involves a battery powered temperature sensor which due to its battery operation must transmit updates as infrequently as possible to conserve battery, and must use clever algorithms to decide when it is important to send an update (like "hot water target being approached soon, send frequent updates!") or not send an update for a long time. ("hot water turned off and at 32 degrees and hasn't moved significantly in 30 minutes. Nothing to see here.")

    It appears that temperature sensor readings may be sent on an unacknowledged basis (the sensor broadcasts its measurement to all and sundry and doesn't expect a reply) or if not that the sensor may not be sending a measurement when it should be. Either way the Evotouch can miss a temperature reading.

    It's then up to the Evotouch to make a decision about whether to turn on the hot water relay or not, and send a heat demand to a BDR91. We're not sure whether those heat demands are immediately acknowledged or not either, my guess is they are not.

    So there are two separate wireless paths in a basic feedback loop to control the temperature of the hot water, if either has problems your temperature could go way over the target.

    If the sensor stops sending (battery goes dead) during a heating phase it will keep heating until the hot water reaches maximum attainable temperature. I haven't tested it but from testing other devices it looks like the sensor would have to go missing in action for at least 60 minutes before the Evotouch would give up and recognise a fault - because during normal operation it appears that CS92 transmissions can be as infrequent as hourly. (It took that long to re-acquire the CS92 after restarting the controller)

    Another failure method would be a loss of communication between Evotouch and hot water BDR91 - we've already established that a BDR91 will continue it's existing heat demand duty cycle (which will be 0% or 100% for hot water) for about an hour in the event of loss of communication whether by interference or by the Evotouch going offline.

    If the Evotouch was left off the charger and the battery went flat during a hot water warm up phase then again the hot water will keep heating for up to an hour without any control. So there are a lot of things that can go wrong.

    Here's how the hot water kit should have been designed.

    Instead of having both a BDR91 and a CS92 as separate items there should have been one mains operated relay like a BDR91 but with temperature sensor element connections like the CS92 has. You strap the sensor on your cylinder, wire it into this hybrid box and also wire that box to power and zone valve.

    Now the control flow is - the Evotouch sends the set point, differential, hot water overrun values and hot water schedule ON/OFF status to the hot water controller periodically or if any of those settings are changed.

    However the logic to switch the relay off occurs directly inside the box - when it detects the temperature passes the set point it is able to directly act on this and turn off the relay.

    This solves a lot of problems:

    1) Because nothing is battery powered there is no need to conserve transmissions for battery life. The sensor would be free to report the temperature back to the Evotouch on a much more frequent basis like an HR92, such as every 4 minutes and additionally when set points are crossed or rapid temperature changes occur.

    2) It's not necessary for the Evotouch to receive the these updates for the hot water temperature to be properly controlled - they are largely informational. (Although if you used a 3x relay config the Evotouch would still have to activate the boiler relay I suppose) In theory a large overshoot is impossible - even if the Evotouch went offline hot water temperature would not exceed the set point.

    3) One less wireless box to try to space 300mm away from other boxes on your precious boiler closet wall space.

    Downsides would be that zone valve and temperature sensor would need to be within reasonable cabling range of each other, and that power would need to be available near the cylinder. Not a problem in many installs, but might be problematic in some cases.

    But from a systems control perspective a far superior solution.
    Last edited by DBMandrake; 2nd November 2016 at 05:52 PM.

  3. #53
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,602

    Default

    I know you think your hot water overshoots are because of the way the CS92 works, but have you considered that the problem could also be with either your DHW BDR91, or your hot water valve?

    The reason I ask is that I just looked in the airing cupboard and noticed that Mrs O had piled stuff right up against the two port value. Not her fault - it sits right at the back of one of the shelves. I'm sure this could have impeded the little lever that moves across when the valve opens/shuts, so maybe this could account for some of my overheats. If any rads were calling for heat but the hot water valve wasn't properly shut then the tank would heat up.

  4. #54
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    I wonder what would happen if you added a 2nd off entry in the DHW schedule, something like 50'C 21:00 OFF then 50'C 21:10 OFF, this is how I solved my never ending on/off cycling at the end of the day, works for my heating issue and I'm no-longer using Optimum Stop, it's a fudge/cludge but it might work for DHW.

    Incidentally I asked my neighbour who's had similar issues unbeknown to me and that's (2xoff) what he does.

  5. #55
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,602

    Default

    Your neighbour has Evohome? I wonder if that could explain sone of your problems?

    Get an HGI80 and you could turn his heating off!

  6. #56
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,602

    Default

    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.

  7. #57
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    Only real engineers stay up late yes it's possible we have interfering systems but he's had the same problems and Honeywell sent him replacement BDR91's and a new controller, so he runs two system upstairs and downstairs. Surely Honeywell must have considered a neighbour possibility and resolved that through the binding process. Luckily Honeywell meet the current RF stanards and use no more than the allowed RF power of 10mW, which does bring its challenges for range, perhaps 20M (metres) at most, most other suppliers would use the upper limit of 25mW which would make for a reliable link. I'll have a listen on 868 tomorrow and see what the signals are like, mine will be very strong obviously.

  8. #58
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    Happened again this morning:

    Code:
    03/11/2016 04:20	0	03/11/2016 04:20	35.61
    03/11/2016 04:25	0	03/11/2016 04:25	35.61
    03/11/2016 04:30	0	03/11/2016 04:30	35.61
    03/11/2016 04:35	60	03/11/2016 04:35	35.61
    03/11/2016 04:40	60	03/11/2016 04:40	35.61
    03/11/2016 04:45	60	03/11/2016 04:45	48.22
    03/11/2016 04:50	60	03/11/2016 04:50	49.45
    03/11/2016 04:55	60	03/11/2016 04:55	49.45
    03/11/2016 05:00	60	03/11/2016 05:00	49.45
    03/11/2016 05:05	60	03/11/2016 05:05	49.45
    03/11/2016 05:10	60	03/11/2016 05:10	49.45
    03/11/2016 05:15	60	03/11/2016 05:15	62.67
    03/11/2016 05:20	60	03/11/2016 05:20	62.67
    03/11/2016 05:25	60	03/11/2016 05:25	62.67
    03/11/2016 05:30	60	03/11/2016 05:30	62.67
    Same story as the last four (?) times. About 20 minutes of no further updates after 49.45 then a reading of 62.67.

    Quote Originally Posted by paulockenden View Post
    I know you think your hot water overshoots are because of the way the CS92 works, but have you considered that the problem could also be with either your DHW BDR91, or your hot water valve?

    The reason I ask is that I just looked in the airing cupboard and noticed that Mrs O had piled stuff right up against the two port value. Not her fault - it sits right at the back of one of the shelves. I'm sure this could have impeded the little lever that moves across when the valve opens/shuts, so maybe this could account for some of my overheats. If any rads were calling for heat but the hot water valve wasn't properly shut then the tank would heat up.
    Thanks for the suggestion, but I'm pretty confident the issue is with temperature updates not being received by the Evotouch, not a problem controlling the BDR91's, or a mechanical problem with the zone valves. EG it's an input side issue not a control side issue.

    I initially kept a close watch on the operation of the system after the S-Plan conversion, to make sure the plumbing and boiler side of the conversion is working well as much as anything else (as I ended up redoing half the piping in the closet ) and by coincidence three of the occasions where the temperature has overshot I have been right at hand, watching the boiler closet where I can see the status of the relays and check the zone valves, and had noticed the system running on past the point where it should have shut off.

    In every case I personally witnessed I noticed:

    1) During the approx 20 minute period where I believed the hot water should have been up to temperature and shut off, the Evohome continued to display 48 or 49 degrees on the screen, as did the iPhone app. This is consistent with the Domoticz logs which also show the temperature reading flat-lining somewhere below 50 degrees for 20 something minutes.

    2) During this period the hot water BDR91 was lit and the zone valve was open.

    3) The instant that the temperature on the Evotouch or iPhone app updated to a value of 50 or above the hot water relay went off and the zone valve swung shut. (The noise is very obvious when it closes)

    4) If the problem was on the control side (relay, zone valve etc) then the Evotouch display itself would show a temperature of 50 or over and yet the zone valve would still be open. And the domoticz log would show the temperature going over 50, and continuing to increase to 62 in multiple steps showing that the over temperature situation was being measured but couldn't be controlled. Instead what I see is the temperature not being measured properly, and when an over 50 reading does belatedly arrive the control side shuts the zone valve instantly. I've seen no evidence in any of my testing that the zone valve is not under reliable control of the Evotouch. I've manually switched hot water on and off lots of times and the response of the relays is instant.

    So I'm satisfied that there is no problem on the control side and that the issue is on the measurement side.

    Quote Originally Posted by paulockenden View Post
    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.
    Thanks for posting that - that's interesting to see that the heat demand is "refreshed" every 20 minutes to the relays, makes sense when I discovered that they will start flashing their red lost communication light after between 45 and 60 minutes of no communication with the Evotouch. So you'd have to loose three transmissions in a row for the BDR91 to go into an error state. Of course if you only lost one transmission that means the reaction would be delayed by 20 minutes, unless a modified heat demand was sent in the meantime. (which would typically be the case on the boiler or hot water relays whose duty cycle is modulated with demand - the hot water is either fully off or fully on)

    I see where you're going with the 20 minute figure but as above I don't think the issue is on the control side. I also notice two things from your log - one is that when a change occurs the 20 minute refreshes re-time themselves to count from the last transmission. So the refresh time relative to the hour changes every time an immediate change is sent. The other thing I notice is your log sample above shows a lost refresh - there should be one at about 2016-11-02 17:21:17 ? It's the only one that seems to be missing in that log snippet.

    I presume when Domoticz is used with the HGI80 that every event received is logged immediately with the time that it was received rather than being polled like the web API scripts ? And it appears that even if two identical readings are received they will be independently logged ? If so, are you able to provide a log snippet like the above of your hot water temperature sensor readings so we can see how frequently and in response to what they get sent ?

    If you could grab a section from say an hour before your hot water is scheduled to come on in the morning, through the heat up phase and until there has been some hot water use that would be extremely useful, so we can try to work out when and why the sensor sends updates. Also let us know what your hot water temperature and differential is set to.
    Last edited by DBMandrake; 3rd November 2016 at 10:21 AM.

  9. #59
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    I might have some good news to report in a few days. Fingers crossed.

    I've been in touch with Richard at theEvohomeshop directly (since I bought all my Evohome hardware through him) and he made a number of suggestions of things for me to try which I am testing one at a time to see if I can narrow down the cause.

    I picked the suggestion that seemed most likely to fit the symptoms to test first and touch wood, it does appear to have fixed the problem so far. I haven't had a single overshoot since then and I've tested it quite a bit It's too early to tell for sure though as the problem didn't occur every day, but if it runs for a week without a re-occurrence I'll consider it solved and post what I did. No point saying what I did if it turns out not to fix it!
    Last edited by DBMandrake; 4th November 2016 at 11:39 AM.

  10. #60
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    I don't want to jinx it, but it has been 5 days without a single re-occurance of overshoot, so I think this problem is now fixed. Many thanks to Richard at theevohomeshop for his help in solving this.

    So what was it ? Believe it or not, it was a lack of battery contact tension on the rear of the PCB in the CS92. (Not the contacts at the batteries themselves)

    On these units the battery contact strips go behind the corner of the PCB and have spring loaded fingers that make contact with two gold pads on the PCB - the connection is not as I first assumed it might be, soldered. Had I realised it was only spring loaded fingers I might have thought to check it myself, as these kind of contacts can be problematic in general.

    This is especially interesting in light of the issue I just had with the battery contacts in an HR92 as described in this thread.

    To fix it all I did was remove the batteries and front plate from the rear panel, gently lift up the plastic tab at the top that locks the PCB in place then carefully lever the top of the board out with a small screw driver and lift the board right out.

    This reveals the fingers that make contact with the rear of the PCB. I bent them both carefully up by about 2-3mm to give a decent amount of tension, then carefully reinserted the board into the bottom and clicked it into place at the top, and refitted the front and the batteries. Five minutes tops. No problems at all since then. It just started working properly.

    You can see the difference in my temperature graphs, this one was taken while the problem was still there, with overshoots circled in red: (set point in pink)



    This is the 5 days immediately following the adjustment of the contacts:



    Something that I noticed immediately after fixing the problem is that the sensor seems to report in much more often now. Specifically during a reheat it reports in almost every degree step, so previously if I ran the hot tap until it dropped to 44 then waited, I would get maybe two updates between 44 and 50 - maybe 46 then 48 then either 50 or nothing until 60. Now it seems to update very frequently during a reheat. The following test was done soon after the repair where I timed and noted every update of hot water temperature on the evotouch display while running a tap and then while reheating:

    Code:
    Temp - minutes:seconds
    51 - 0:00 (hot tap turned on)
    49 - 1:13
    47 - 1:46
    45 - 2:19
    44 - 2:28 (hot water relay turned on)
    
    44 - 0:00 (hot tap turned off)
    45 - 1:57
    46 - 2:30
    47 - 3:02
    49 - 3:25
    50 - 3:52 (hot water relay turned off)
    51 - 5:37
    You can see that it reports in every 1 or 2 degrees even when it is falling or rising rapidly, and some updates are as little as 20 seconds apart. It was most definitely not like that previously. Updates were few and far between, ever since I first installed it.

    So lets try to analyse how a bad battery contact could cause these infrequent updates and try to rule out other possibilities.

    Things that were not touched during the repair were the sensor on the cylinder, the back plate, or the wires going into the terminals on the rear back plate - so it can't be any of those.

    Of course I had to remove the batteries and thus reboot the device in the course of the repair, but I have removed the batteries on at least 2 other occasions since I first noticed overshoots and this did not help. So "rebooting" the device was not the answer. I had also adjusted the tension of the contacts that press against the battery but that did not help either.

    Removing the front plate from the back plate will disconnect the pin contacts that connect the PCB to the terminal block at the rear that goes to the sensor - could it have been an intermittent connection there ? Perhaps, but I think its quite unlikely. Any spurious resistance there would cause an incorrect temperature reading, and I never saw any readings that I had cause to believe were incorrect, the problem only ever seemed to be a lack of frequent updates, but it did send completely plausible readings when they were sent.

    If the sensor connection went completely open circuit intermittently I would imagine that a fault would be recorded but I'd need to try that to confirm it. (And I don't really want to disturb it now it's working!) So I think its 90% likely that it was indeed the battery contacts on the rear of the PCB to blame and maybe only a 10% chance that disturbing the pin connector for the sensor made a difference.

    OK so lets assume the battery contact on the PCB was the culprit - how does it cause symptoms of readings only being intermittently sent ? There are two possibilities I can think of:

    1) Intermittent resistance from a poor connection causes a voltage drop that still allows the device to operate but puts it in some sort of battery saving mode. Maybe when the battery is getting very low, as well as sending a low battery alert to the controller it reduces the frequency with which updates are sent to "stretch out" what remaining battery life it has left until the owner is alerted to the issue and replaces the batteries. This may be done at the expense of accuracy. (EG overshoots due to infrequent sampling of the temperature)

    So why wouldn't it have sent me a low battery alert ? We know from DanD's domoticz work that HR92's only send their battery status once every 24 hours - and I have no reason to believe that the CS92 would send it any more frequently. And they probably only send the status of the battery at the time that the alert is sent, rather than saying "some time in the last 24 hours my battery seemed low but now it seems ok again". So if the intermittent connection isn't causing a low voltage at that time, no alert. A gradually declining battery would be caught by a 24 hour sample period but an intermittent battery voltage might easily evade detection as far as low battery alerts are concerned.

    2) The intermittent connection was varying enough (in response to heat/vibration in the boiler closet) to cause random spontaneous reboots of the microcontroller in the CS92. One thing I've noticed is that when you first put the batteries in the CS92 it always sends an update more or less right away, but the next update is many minutes later. And a reboot would obviously cause a loss of internal state in ram, so the sensor would lose track of what it had been doing and have to start over as if the batteries had just been inserted.

    This is important when you think about the battery saving heuristics. To save as much battery power as possible it will obviously reduce the frequency of sampling the temperature and sending transmissions to the controller when it can. If the temperature is 32 and steady there's no reason to send a reading every 20 seconds. Every few minutes is fine. If it then detects the temperature rising it would increase the sampling rate to keep a closer watch on the rising temperature, and if the temperature is rising really fast (small cylinder) or getting near the set point it will send quite frequently - as you can see some of my readings are now as little as 20 seconds apart during a rapid reheat.

    So what happens if a spontaneous reboot occurs during a reheat at say 48 degrees with a target of 50 ? After the reboot it sends an update saying 48 and then...... does nothing for quite a while. Because it has forgotten that it has been tracking a reheat and sending frequent updates. So maybe 10-20 minutes go by before it realises that a reheat is occurring and starts sending more frequent updates again - it lost the state it was previously tracking.

    Of the two theories I think the second one is much more likely. So in short I believe a poor battery connection on the back of the PCB was causing lots of random spontaneous reboots of the CS92 that were fooling the battery saving heuristics into going for long periods of time without sending an update in circumstances like reheating where it should be sending frequent updates.
    Last edited by DBMandrake; 8th November 2016 at 02:44 PM.

Posting Permissions

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