Heating demand taking half hour to update?
Hi,
I thought id start a new thread with a more accurate title. I'm not giving up on this issue.
OK so after a lot of back and forth with Honeywell, lots of photos being taken and sent and lots of, try the obvious, we still don't yet have a proper answer so I was hoping someone might clarify the flow of data for me.
Temperature is set on the controller. Temperature is sent to HR92. HR92 opens to a point it considerers sufficient to achieve temperature, then it sends a signal back to ...the controller and the BDR91? Then the BDR91 switches on the boiler..?
What happens with my system is temperature is set, and sent to HR92's and HR92's operate all fine within 2 to 4 minutes. I have never set a temperature increase or decrease and had the valves so the wrong thing.
The problem for me is the feedback of the demand requirement.. I have 19 HR92's connected to 11 zones, and the demands get stuck off or on during the operation. So if I switch 5 zones on, 1 or 2 may or may not feedback a demand, so it is stuck on zero. The valves to these zones operate fine. I can go to menu 10 on the valve and it says it is open, you can hear the valve open, the radiator obviously get hot.. but the demand still does not update. I've timed it, its not an exaggeration, and i've taken photos every 4 minutes to prove it.. it takes HALF AN HOUR until the demand changes. If there are two zones that didn't feedback the 100% demand, then it is entirely possible and again has been documented, that one of the feedbacks updates after 30 minutes, and the other is missed again, then it takes another 30 minutes to update. Does anyone know why it is 30 minutes? Does the system do a full communication at 30 minute intervals and only partial the other times... this 4 minute interval all the documentations talk about?
Anyway, the same thing happens with the valves switching off, except, of course, this is the biggest issue, because all the time the boiler demand is set on, the boiler stays on. I have had it where its taken an hour from the zones updating on controller and valves, to all zones reporting 0%, and then the boiler demand was still set at 30% for another 30 minutes.. (the last zone to clear was at 30%).
There is no pattern I can see. It doesn't matter if a zone had 1 HR92 or 4 attached to it. each and every zone could be one that succeeds on one attempt and fails on the next so I don't believe its an issue with the HR92's, the valves or anything physical.
All RF tests report excellent signals.
I thought it might be interference. I have tried switching telephones, wifi routers, sky boxes off and same thing happens. I've changing channels on both frequencies of the wifi, same thing happens. I thought maybe it was my TEXECOM wireless alarm system which is running on 868 frequency as well, but I went round and removed every battery in every sensor and controller and tested evohome, and still does the same thing. (now my alarm needs sorting out lol)
I've unbound everything. Pressed and held button on BDR till light went red slow flashing then fast flashing. Cleared the binding on every HR92 by pressing and holding till it says cleared... then reset each HR92 through menu 12, taken batteries out over night... unbond everything on the controller, then factory reset.. then batteries out over night... then retired set up and same thing happened. Ive done this three times now and always get the same results.
What could be wrong? Is it possible it might be a fault with the BDR91 as I think this is what receives and sends out the demand info isn't it..? I also notice during taking all my photos for Honeywell, that the temperatures in the zones didn't seem to be updating on the controller across the half hour periods...
I am close to Leeds West Yorkshire, and I cant find an installer to come round and help me. I've tried Honeywell's page and called everyone on there, and it seems like this list was put together 5 years ago or so, as no one answers the phone, I had one answer and he's not been a plumber for about 5 years he said... I don't know what else to do. I'm still waiting for Honeywell to get back to me from the most recent dialog and photo sessions on Friday, but I'm wondering, should I go but another controller and receiver, and try this, then if it doesn't work just give it up as a bad job..?
Thanks for your feedback so far..
The demand from the HR92s is sent to the controller. So ignore the BDR91 for now.
When you set five zones you say two respond instantly (or rather, as instantly as you can get with Evohome!) is is always the same two, or is it random?
Right now I’m suspecting that your controller could be faulty.
P.
Hi Paul. I've read a lot of your posts trying to find answers to this, thanks for replying.Originally Posted by paulockenden
Its completely random. I've even set up the controller a meter from the BDR91, and opposite the Rads in the hallway with clear "sight" between all and had the hallway fail to send the 0% demand after they closed. It could be any of them, none of them, one, two three four at a time. All zones respond instantly in terms of valve movement. (within a couple of minutes), Every time the valves react no problem at all, but random zones don't update on demand. I guess I could set up all HR92's on a table in front of the controller and see what happens... unless this would cause interference all being so close to each other..?
I should pergaps add, when one fails to feedback 0%, I set that zone to high temperature manually, then wait till valve opens, then cancel the request, wait for valve to close and that then updates and shuts off... If I unclip the HR92 the feedback instantly goes to 0...
I think it's sounding like a controller with slightly duff RF.
Simon (@dbmandrake) is the real expert at diagnosing things like this. He has a talent for spotting things that everyone else has missed!
P.
Thanks Paul.
I've ordered a replacement, there really isnt anything else I can do I've tried everything i believe within my capabilities I'm just curious because honeywell specifically asked me to look at results after half hour like they were on to something. If the replacement does the same thing then I give up. Lol.
Thanks again
Having read the previous thread about this problem as well it sounds like the comms are a little bit unreliable between HR92's and Controller, and that could be partly interference and partly the limitations of the way the 868Mhz wireless comms work on Evohome...(many message types are unacknowledged, so the sender doesn't know if the recipient got it or not, and there is no rapid retry mechanism - just infrequent periodic re-transmissions of existing status to refresh the overall system state)
The worst case scenario for the system that will expose any comms issues is when the controller tries to make a large set point change to all zones at once that would cause all HR92's in the house to either open or close, as you have a lot of wireless comms between controller and HR92's in a very short space of time.
For example if you use the heating off action you are basically just sending a set point change to 5C to all 19 HR92's in the house, once they close their valves all 19 of them (assuming all were previously open) will have to send back new 0% heat demands to the controller.
Only if every single HR92 in the house receives the set point change, actions it, and its new heat demand sent back to the controller is actually received by the controller will the heat demand for the boiler relay actually go to zero in a timely fashion. So a single one of those 38 transmissions going missing due to a transmit collision between different Evohome devices (for example two HR92's try to send their heat demands at the same instant due to unfortunate timing) or with a 3rd party device (for example your TEXECOM system happened to transmit at the same time through unfortunate bad timing) will cause the controller to think there is still a heat demand from one of the zones, and thus pass on that heat demand to the boiler relay. (Message 39 - which could also get clobbered by a transmit collision or interference)
I only have 8 HR92's and to be honest I still see the same issue happen where the heating is scheduled to go off in the evening and I notice the boiler runs on for about another 30 minutes, and one zone in the system installer page on the controller reports there is still a heat demand however it happens very infrequently. I maybe notice it a couple of times a month, although I wouldn't be surprised if it happens the odd time when I don't notice it.
Probably not the answer you want to hear, but I think that occasional examples of this happening are inevitable because as mentioned a lot of the comms is unacknowledged by design and therefore does not expect replies nor have a rapid retry mechanism. So for example when an HR92 sends an updated heat demand to the controller (which happens every time it moves it's valve pin control motor) it waits for the channel to be clear, sends the new heat demand, crosses its fingers that the controller received it and goes back to sleep. Literally. The controller does not acknowledge the receipt of the heat demand message, and the HR92 doesn't expect to get an acknowledgement. If two HR92's through extreme bad luck transmit at the same time (CSMA collision) then one or both messages will be garbled at the controller depending on relative signal strengths and the heat demand at the controller for one or both zones won't update.
This is in contrast to most wireless protocols these days that have a message/acknowledgement structure where any message not acknowledged in a fairly short period of time is resent and the sending device can be positive that a message was received by the recipient and that it can stop trying to resend it.
Part of the reason for this choice not to acknowledge most periodic messages is probably that the 868Mhz band usage requirements dictate that devices are only allowed to transmit in very short bursts and occupy a total of <1% of the available channel time, so an acknowledgement to every message would eat into that allowance especially if you have a lot of devices, and may result in a device not being "allowed" to transmit when it has something to send due to it exceeding it's allowed channel time.
My loop energy monitor is similar in that if I unplug the receiver for a few days the gas and electricity sensors locally buffer that data and then dole it out at a very slow rate when the receiver comes back online again - so slow in fact that 3 days worth of electricity usage data with the receiver unplugged takes about 6 hours to sync back up to date when the receiver is turned on again - because they're only allow to transmit very short infrequent messages on 868Mhz.
To get around this issue of possible collisions Evohome seems to take the approach of periodically re-sending the status quo, and thus recovers from such situations in a relatively graceful fashion, albeit after a period of time. For example the heat demand from the controller to the BDR91 is transmitted every time the heat demand changes, and the same value is resent every 20 minutes. Likewise the HR92's send a heat demand to the controller every time they turn the pin control motor and resend the same heat demand periodically - although in this case I think it's every 30 minutes. (would need to re-check that to confirm that though)
Temperature sensor readings (from HR92 or wall mounted sensors) are sent to the controller periodically every few minutes or faster if the temperature is changing quickly so if one transmission gets lost you'd never know - the temperature just doesn't update quite as quickly and it's not the end of the world as the correct temperature will be received a few minutes later.
Given the way the comms work and the nature of CSMA controlled wireless communications without rapid retries I would say that the likely-hood of collisions that cause lost transmissions increases the more devices you have - if you have a lot more HR92's and wall sensors then the chance of two colliding especially when you're doing a house wide set point change that causes a flurry of activity in a short time increases. This may well be one reason that Evohome is limited to 12 zones so that the total number of devices and chance of collisions doesn't get out of hand.
Heating off is that one scenario where any lost comms will be immediately noticed, because only one HR92's heat demand has to not get through to allow the boiler to run on another 30 minutes until the HR92 re-sends its heat demand. A lost message in the heating switched on scenario might mean that one zone is reported as having a 0% heat demand when it actually does need heat, but because several other rooms probably came on and called for heat at the same time the boiler comes on and everything seems fine - only if you checked the installer screen heat demand would you notice a problem. (And yes I have seen this happen too, but rarely)
In your situation your alarm system could be making the situation worse - it's hard to know. In my house I have a loop energy monitor and also a Bresser 5-in-1 weather station - both work in the same 868Mhz band and they both got installed more than a year after I first got Evohome, and I can't say I noticed any difference in the Evohome's incidence of strange behaviours before or after.
If the only symptom you're seeing is that sometimes the boiler doesn't always go off within 5 minutes of the heating off action, but it does always go off within about 30 minutes and all your radiators are HR92 controlled I'm not sure that I would necessarily worry too much about it - with all the radiators closed the boiler will only flow through the ABV and will just end up pumping hot water in a loop but without heating it much, so the gas used by that will be very minimal. It's not the same as if a radiator had kept heating.
If that does bother you and you've tried everything you can to resolve it then Evohome may not be for you. Most of us long time Evohome owners while liking our systems and generally getting good service out of them are aware that the wireless comms used by the system is getting a bit antiquated now and really needs a clean sheet of paper redesign to bring it up to modern standards.
Last edited by DBMandrake; 2nd October 2019 at 03:26 PM.
Thanks DBmandrake for a clear and detailed explanation of the data exchange protocol. As a business systems integrator, I naturally assumed that Evohome would follow the recognised send/acknowledge process. I have also had these curious system run-on after supposedly turning every valve to 5C. I have also seen odd occurrences of valve overrides when there is no one in the house! I can see why Honeywell may have taken the approach they have using the particular frequency and the fact that they do eventually "tidy up" any CSMA CD incidences is comforting and would explain why when I have left the system to still run-on it does eventually switch off. I suppose that if the system was installed in a black box environment then one would not notice the system calling for heat etc after the turn off time. However, as I understand it most installations are done by those of us with a techy background and so we "monitor" the system closely and notice these odd-balls - lol. Now that we have an authoritative explanation of the comms I will stand back knowing that eventually the system sorts itself out and I don't need to "fire fight it"Shame again that in the manual there is not a more techy guide that could just touch on these matters to reassure us techy types
Yes perhaps it is time for a rethink of how Evohome operates, its app and controller interface etc. Regardless I still love the system even with its foibles
Steve
Thank you both for your input.
I had kind of come to the same conclusion.. the benefits for me to have the system far outweigh the issues with comms. I realised that the on off function I was attempting was just too demanding of the system, and also thought maybe it was trying to do something a bit more clever than on and off, so going from 100% on all devices to 0% was just too much. If the system is running normally, obviously the decline in demand is gradual, so even if a valve doesn't get the final 0 signal when it is meant to, the heating has ramped down a lot anyway, so the extra half hour is not much of an issue if it happens. Trying to talk to Honeywell about this was a nightmare.. they kept responding with copy and pastes from their website.. and we ended up falling out in quite a big way, after I might have lost my rag with them a little.
I can't be the first person to try to test the system after installation to experience this, and that's what confused me having found no information. I ordered another controller and it did exactly the same thing so I'm happy that it isn't a device issue now, and happy I haven't had to send everything back as half the packaging I had binned off. lol
Again, thank you both for helping out and spending the time to reply.
much appreciated.
Richard
I confess I'm pretty much 'non-techy' but find DBMandrake's explanation of the wireless protocols absolutely compelling - thank you!
Am I right in inferring that it's maybe preferable to avoid additional devices that put yet more traffic on 868Mhz? Also temperatures reported on the mobile app presumably monitor the central hub so is there any value in sending the "heating off" command a couple of times, say, in case of CSMA collision?
Posting Permissions
Reply With Quote