Page 3 of 11 FirstFirst 12345678 ... LastLast
Results 21 to 30 of 109

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

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

    Default

    Quote Originally Posted by g6ejd View Post

    Although the syntax makes it a little vague, but my reading is they used Zigbee and/or Z-Wave protocols. 'It is a well controlled relatively ‘quiet’ band used by manufacturers broadcasting ZigBee & Z-wave protocols and it is the protocol adopted by Honeywell whose bespoke protocol Ramses II works in this area.
    My reading is that Ramses II uses the same 868mhz band, rather than the same protocol.

    And like I said above, the historical timing suggests that it can't be ZigBee.

    And of course both ZigBee and Z-Wave are able to form Mesh networks (with plugged in rather than battery powered devices). Shame BDR91s don't do this.
    Last edited by paulockenden; 23rd October 2016 at 11:08 PM.

  2. #22
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    Reading from the article:
    How reliable is 2-way RF communication?
    The 2-way RF communication (also known as wireless
    communication) used by Honeywell is extremely robust
    and reliable. When installed correctly the signal strength
    test feature allows the Installer to locate the system
    components where mutual signal reception is strong.

    During communication, signals are sent several times
    to ensure receipt, and if any message is garbled, the
    error detection software recognises this and ensures the
    message is repeated again. The benefit of the two way RF
    is that symbols showing successful communications and
    systems operation can appear on both transmitter and
    receiver, making testing and fault finding easy
    I find these claims interesting - that it is a "2-way" protocol with an error detection and retry mechanism when packets gathered by HGI80's suggests that many periodic communications are sent with no expectation of acknowledgement, and if there is no expectation of an acknowledgement re-sending a message if it is lost is not possible.

    They do say that messages are sent multiple times for redundancy and they no doubt include forward error correction encoding so that minor errors can be corrected without re-transmission, but it still doesn't seem like a fully acknowledgement/retry capable protocol such as TCP.

    If it had full error detection, acknowledgement and retry mechanisms for all messages being sent I can't see how the "lost transmissions" that I see from time to time (especially manual HR92 overrides not reporting back to the controller) could occur. Or how peoples intermittent comms failures to BDR91's could occur as a retry should be sufficient to avoid visible problems, as the messages are not highly time critical - it doesn't matter whether a retry a couple of seconds later was necessary to get a message through as long as it arrives in a reasonable time and with 100% reliability.

    I can see I'm going to have to get myself an HGI80 and appropriate protocol analyser software to have a look for myself...

    For those who already have HGI80's - what Linux based software is available that will work with the HGI80 other than Domoticz ? Is there any equivalent to wireshark or tcpdump that will log and analyse the raw communication packets in a readable fashion ?
    Last edited by DBMandrake; 23rd October 2016 at 11:25 PM.

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

    Default

    The best way to see the data with an HGI80 is to use Domoticz with full logging.

    I know it's a sledgehammer to crack a walnut, but Domoticz is useful in other ways too (graphing temps, etc.).

  4. #24
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    Quote Originally Posted by paulockenden View Post
    The best way to see the data with an HGI80 is to use Domoticz with full logging.

    I know it's a sledgehammer to crack a walnut, but Domoticz is useful in other ways too (graphing temps, etc.).
    I already have Domoticz installed and running on a Pi for graphing via the API so it would be fairly easy to set up the HGI80 on that.

    However I wonder how low level the logging is and how much Domoticz would be "interpreting" the messages into its own event syntax. If possible I'd like to see a decode of the raw packets that hasn't be interpreted by Domoticz.

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

    Default

    If you turn debugging on in hardware/evohome.cpp and then recompile you get a log file showing the raw Evohome messages.

  6. #26
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    Quote Originally Posted by paulockenden View Post
    If you turn debugging on in hardware/evohome.cpp and then recompile you get a log file showing the raw Evohome messages.
    Thank for the info, sounds like just what I need. At 94 it might have to wait a while after the money that has just been spent on the S-Plan conversion though...

  7. #27
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    Quote Originally Posted by DBMandrake View Post
    Reading from the article:

    I find these claims interesting - that it is a "2-way" protocol with an error detection and retry mechanism when packets gathered by HGI80's suggests that many periodic communications are sent with no expectation of acknowledgement, and if there is no expectation of an acknowledgement re-sending a message if it is lost is not possible.
    So much for Honeywell's "robust 2-way protocol"...

    I was just standing at the boiler cupboard watching the relays/zone valves/boiler/pump etc operating after dropping my pump overrun time a bit, I deliberately ran the hot tap for a while to trigger a hot water reheat.

    After doing this I watched the temperature climb on the iPhone app until it hit 49 (target is 50) and then waited...and waited, then after about 5 more minutes thought hmm, something is not right, there's no way it takes this long to heat one degree. I tried pressing the button on the CS92 which cheerfully reported 5 flashes.

    Waited a few more minutes, still no change in the reading and the hot water relay was still on, so I decided to provoke a forced temperature send so I popped a battery out of the CS92 for a few seconds, put it back in, and suddenly the Evohome reports 58 degrees and the hot water relay turned off.

    Not impressed by the reliability of signal transmission here, and the 8 degree hot water temperature overshoot that resulted from it....

    Either there are serious bugs in the device firmwares or this is not a robust 2 way protocol that uses acknowledgements and re-transmissions as claimed in the blurbs...

    I have also noticed that the boiler relay and zone valve relays sometimes seem to "get out of sync" with each other in a 3 relay configuration. For example the boiler relay will come on 30 seconds before the heating zone valve relay comes on or vice versa, most other times they switch within just a few seconds of each other.

    All BDR91's and CS92 are 300mm apart and vertically stacked up the wall. They are a little bit closer to the hot water cylinder than recommended but there is absolutely nothing I can do about this. Every single device in the house reports Excellent 5/5 signal at all times including the CS92...

    I can see I'm going to have to arrange a back up cylinder thermostat as the wireless stat can't be trusted to not allow a massive overshoot in cylinder temperature due to apparently not reliably reporting the temperature. (But strangely reporting it just fine when I remove and refit the battery)
    Last edited by DBMandrake; 25th October 2016 at 11:13 AM.

  8. #28
    Automated Home Legend
    Join Date
    May 2014
    Posts
    988

    Default

    Quote Originally Posted by DBMandrake View Post

    I can see I'm going to have to arrange a back up cylinder thermostat as the wireless stat can't be trusted to not allow a massive overshoot in cylinder temperature due to apparently not reliably reporting the temperature. (But strangely reporting it just fine when I remove and refit the battery)
    The one thing that I have never seen on my unvented cylinder is a temperature overshoot. I have my HW Kit set to 62C in series with the tank limiter set at 65C. I know 62C is a bit high but my thermostatic shower needs a minimum input temp of 57C.

  9. #29
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    To be fair it has only happened once so far, oddly enough at a time when I was watching the boiler cupboard to monitor correct functioning of the new system configuration. But the fact that it can happen at all is worrying. If the Evotouch for some reason stops receiving updates from the CS92 during a heating phase the hot water relay will just remain on until it gets way over temperature.

    It's a vented cylinder heated via indirect loop so it can't heat to a point that is dangerous for the cylinder itself - at most it will heat to nearly the flow temperature of the boiler, but there is the risk of scalding of hot water users - avoiding this is one of the reasons I did the conversion in the first place as the old gravity circulation system sometimes resulted in scalding hot water in winter with high flow temperatures and heavy use of the boiler as there was nothing to stop it circulating once the hot water was hot enough.

    The immersion sensor pocket is already taken by the thermostat for the immersion element (which I'd like to keep functional as a backup) so adding a second strap on sensor and non-wireless backup thermostat would be the only real option, which is a lot of extra complication that I don't feel should really be necessary if the system was a bit more reliable in its communications.

    I'll keep an eye on it and see if it happens again before deciding what if anything to do.
    Last edited by DBMandrake; 25th October 2016 at 01:44 PM.

  10. #30
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,850

    Default

    Just had another hot water overshoot, this time 12 degrees.

    This time it happened while the house was unoccupied from 10:30am to 6pm - the heating was off but I deliberately left hot water on to see how frequently the cylinder would reheat with no hot water use. Below is my hot water temperature graph. Note that Domoticz always reports 60 degrees as the hot water set point as it is unable to query this value through the API, so ignore the blue line. The actual hot water set point is 50 with a 5 degree differential:



    Hot water was first up to temperature at 7:10am, some hot water was used between then and 10:30am causing a reheat to 50 again at 10:30am. After this the house was unoccupied.

    By 2:55pm the temperature had dropped to 44 degrees, triggering a reheat. (4 1/2 hours - not bad for a 5 degree differential)

    At 3:00pm the temperature read 49 degrees - a reheat from 45 to 50 degrees typically only takes about 7 minutes so this seems about right.

    However the readings at 3:05, 3:10, 3:15 all say 49 degrees, which I know is false. Clearly no temperature updates have been received during this time. At 3:20 the temperature reading jumps to 61 and presumably at that point the boiler went off. Temperature crept up to 62 over a few minutes.

    This is a pretty major overshoot in hot water temperature, and now the second time in less than a week.

    Previously I talked about how the hot water sensor seems to send an immediate update when the set point threshold is crossed - I think this overshoot may be the result of a firmware bug. So far every time that the overshoot has occurred there has been a reading of 49 degrees, eg 1 degree below the set point just before 50 degrees should have been reached.

    It seems as if the sensor is sending its immediate temperature update slightly below the 50 degree set point, (maybe it is 49.8 or something) which is not a high enough temperature to trigger the Evohome to shut off the hot water relay. It then sends no further temperature updates until the next "periodic" update, which was a full 20 minutes later, by which time the hot water temperature had massively overshot.

    I'm going to tweak the domoticz code to report hot water temperature to full decimal places to help troubleshoot this further - when I hacked the domoticz evohome script to give full temperature resolution for heating zones by using the V1 API I overlooked the hot water code as I didn't have hot water control at the time.

    But I've checked the V1 API response and it does include hot water temperature to at least one active decimal place so I'll see if I can tweak Domoticz to report this. My guess is that the reading was really 49.9 or something very close to 50.

    The problem may just be due to a rounding error or due to the CS92 and Evohome rounding the temperature differently.
    Last edited by DBMandrake; 30th October 2016 at 11:49 AM.

Posting Permissions

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