Page 4 of 4 FirstFirst 1234
Results 31 to 35 of 35

Thread: Boiler Pump/Fan cycling at random? Evohome at fault?

  1. #31
    Automated Home Legend
    Join Date
    Jan 2015
    Location
    NE UK
    Posts
    1,027

    Default

    Looking at this thread and the initial posting I am reminded that I had a similar problem in the early days. I installed Evohome in December 2014 and eventually stopped playing with it and left it alone. All works fine now, no odd boiler firings etc. I don't even bother changing settings when Summer comes as the heating won't come on if it does not have to and that has proved to be the case. There is some merit in saying "Set it up, leave it alone and stop playing with it"!

    As an aside where I have seen differences they are ones Honeywell has introduced with an improvement in the app and sadly some other changes recently, presumably at the server end that result in it taking longer for the app to connect and sometimes telling me there is no internet connection when there is.

  2. #32
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,851

    Default

    Quote Originally Posted by DBMandrake View Post
    Although I've done some anecdotal testing before I thought I'd do a thorough test of this to confirm once and for all whether BDR91's do in fact autonomously continue their last known TPI cycle and for how long, and whether HR92's can send heat demands directly to the relays or not.

    The answer is an equivocal yes on the first point, and no on the second point, as I had already believed. Here was the test that I did this morning which took a couple of hours, and which is interesting as it gives some insight into details of how the system works that Honeywell doesn't go into.
    After figuring this out anecdotally I've found the following post by the guy who wrote the original Domoticz support for Evohome basically confirm this at a protocol level:

    http://www.domoticaforum.eu/viewtopi...art=105#p73681

    Where 0xc8 (200) is the max value for a byte this appears to be a percentage i.e. n/0xc8*100 or n/2

    The 3B00 cmd is more than just a keep alive for the relay it also synchronises the start of a time period for any relays bound to the message. So if there are 6 cycles an hour i.e. 10 minutes per period then the 3B00 message is sent every 10 minutes presumably synchronised to the controllers clock or something. I've not tried altering the number of cycles which I think may be controlled via the 1100 message but I haven't confirmed that yet (so I also haven't confirmed if the 3B00 time period alters - guessing it does). So basically the controller broadcasts an 0008 demand message with a percentage demand i.e. 0 to 0xc8. The relay is bound to this message during binding so it's looking for the specific command / controller id combination to read its demand. As an example if the demand is 50% (0x64) then the relay will be on for half a time period using the 3B00 message to gauge the start of each period. The relay uses the most recent 3B00 and 0008 messages to generate its on/off periods which it will keep doing either until it receives a new message or goes into fail safe mode (if it hasn't received the appropriate messages within its time-out period).
    What's interesting to note is that whilst the BDR91 continues the last known duty cycle by itself up until the point where a comms error is reported, (somewhere between 45 and 60 minutes) there is also a command - 3B00 which synchronises the start point for the TPI cycle.

    This is especially important with a 3x BDR91 config, where you want the on periods of your Boiler Relay and Heating Zone valve relays synchronised so that they both come on together in unison. It's no use if the boiler relay comes on for 3 minutes by itself then goes off then two minutes later the zone valve relay comes on by itself for its 3 minutes then goes off! So this command periodically sent from the controller not only acts as a keep alive message, it synchronises the start time for the TPI cycle a bit like using ntp to periodically keep a computer clock synchronised with a reference time server.

    From the logs Paul gave in another thread it looks like this keep alive might actually only be sent every 20 minutes even with a 10 minute cycle configured, but that doesn't really matter as they probably won't drift far in that amount of time. (Or do you have your system set to 3 cycles an hour Paul ?)

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

    Default

    Quote Originally Posted by DBMandrake View Post
    (Or do you have your system set to 3 cycles an hour Paul ?)
    Bog-standard S-plan with no setting overrides available.

    Oh, one interesting thing I spotted last night - I /think/ I saw a message from the BDR91 back to the controller. Only one message though in several weeks since I last cleared my logs. Strange...

  4. #34
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,851

    Default

    Quote Originally Posted by paulockenden View Post
    Bog-standard S-plan with no setting overrides available.
    Ah OK.
    Oh, one interesting thing I spotted last night - I /think/ I saw a message from the BDR91 back to the controller. Only one message though in several weeks since I last cleared my logs. Strange...
    I wonder if its related to this aspect of the protocol ?

    http://www.domoticaforum.eu/viewtopi...art=120#p73918
    Actually it just occurred to me what the 1f09 message means. Initially I saw it comes just before the controller broadcasts its regular update which is usually zone temperature and set points or occasionally the zone settings instead. The payload seemed like it could be the interval between broadcasts ff070d where 070d=1805 or 180.5 secs. I couldn't really confirm this though and when I saw some other 1f09 messages popping up with a different seemingly random payload I thought my original guess was wrong. It just now occurred though that this might be the time to the next broadcast or 1f09 message at least. I checked this out and can confirm it is correct, basically the controller sends a broadcast write 1f09 with f8 in the first byte and the last 2 bytes giving the time in 10ths of a second to the next broadcast message. I also noticed if the TRVs don't hear the controller for a while they start sending a 1f09 request presumably looking for a 1f09 reply giving the time to the next broadcast. That's also why the controller sends it when the temperature sensor gets bound so the device knows how long till the next broadcast of zone temperatures and set points. So the only thing I'm not 100% on is if the regular broadcast with ff in the first byte of the payload is the interval or a countdown. I guess it would be safer to treat this as a countdown though as should be correct in both scenarios then.
    Funny thing is when I have previously timed the period between set point updates being sent to HR92's I had noticed that it wasn't always exactly 4 minutes and that it varied at least +/- 30 seconds with 4 minute only being the nominal time. I wondered how the HR92's would know when to wake up to to listen for transmissions if the time wasn't constant and realised that there must be something in the previous transmission to say how long it would be until the next scheduled transmission - so the HR92 uses this message to know how long to go to sleep for and when to wake back up and listen again.

    And apparently if the HR92 doesn't hear anything for a while (I think its 30 minutes) it will send the same message back to the controller, in essence asking "how long until you are going to send me the next update ?" to allow them to get back in sync time wise and let the HR92 get its "sleeping pattern" back in sync with the controller.

    This explains why it can take a long time for HR92's to get back in sync after a controller reboot - the HR92's are still waiting for the previous message that never arrived and don't know when to wake up next. Meanwhile the controller may attempt to inform the HR92 of when the next transmission is scheduled - but if the HR92's are sleeping at the time that message is sent they won't hear it.

    So the way out of that conundrum after a controller reboot is for the HR92 to wake up after 30 minutes or so of no received messages and poll the controller to ask it how long until the next transmission. And we know that pressing the button wakes up the HR92 immediately - perhaps it sends one of those messages as soon as you press the button, hence they get back into sync quickly by pressing the button after a controller reboot.

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

    Default

    I'm pleased to say that my system that exhibited some of these 'issues'/artefacts has now stabilised and is running perfectly, I wonder how much can be attributed to the TPI tuning itself, it's taken about 3-weeks maybe more.

Posting Permissions

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