S-Plan vs Y-Plan for Evohome ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • g6ejd
    Automated Home Guru
    • Oct 2016
    • 153

    #16
    Paul, they are 22cm apart and it would have been so easy to make it 30cm or more to remove this possibility, that will be my next step. But for now, so I've recorded the time when the rest took place and now ill wait to see if it will run without a comms. fault, which currently I think it won't.

    The Honeywell data sheet says the system is built-around/based on ZigBee protocols/modules according to their documentation which are well known and reliable, usually used in systems that need over-the-air updates; so that figures, but the repetitive nature of the fault then restore log entries appears to me to be a bit more than a comms fault unless they are keep-alive signals that don't get acknowledged, I don't know.

    Yes, most other products on the market just don't care about siting or other signals or metal or anything, my Davis Weather station has run continuously on 868MHz for the last 6-years 24/7 and never had a single comms fault in the log, so is does rather point to a protocol issue, being it can't cope with errors of any type. All these modules with their 'open' receiver front-ends are susceptible to blocking from other RF sources and it appears to me these Honeywell units are no different, but why does it not recover the link and handshake after what would be a short transient RF interference period, or whatever is causing the issue, I just don't understand it.

    One thing I found interesting is at 12:00 today I rest the controller and took the batteries out, then was on my way to the BDR91's when I heard a radiator whirring and then the heating came on, I was intrigued to see the heating BDR91 had turned on and the boiler of course was running, so the system was working autonomously from the controller that was definitely non-operational, maybe it's some form of providing heating during a controller fault, which is good if so.

    Dave

    Comment

    • paulockenden
      Automated Home Legend
      • Apr 2015
      • 1719

      #17
      Where did you see that the system is based around ZigBee?

      I thought it predated ZigBee. In fact I'm pretty sure Hometronic (which first used this comms system) was around in 2003-4, whereas ZigBee wasn't announced until 2005, and products didn't hit the market until sometime after that.

      Comment

      • g6ejd
        Automated Home Guru
        • Oct 2016
        • 153

        #18


        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.

        Could have been written:

        It is a well controlled relatively ‘quiet’ band used by manufacturers broadcasting ZigBee & Z-wave protocols and the bespoke protocol adopted by Honeywell Ramses II also works in this area.

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          #19
          Originally posted by DBMandrake View Post
          2) I have seen occasions when the boiler relay comes on without either of the zone valves, for minutes at a time, and also occasions where the heating zone valve opens for minutes at a time without the boiler relay coming on. I can only assume this is a communication problem ? No problems have been reported, and the boiler relay is located in the exact same position it always has been.
          Think I might have discovered the underlying cause for this, and it was operator error!

          Today while poking at the system testing things I noticed the boiler relay cycled on for about 3 minutes but neither hot water or heating zone valve relays came on, thus the boiler uselessly heated the automatic bypass loop. I knew it wouldn't be hot water demand so it was the heating zone valve that should have turned on.

          Then I suddenly realised what had happened - I had just a few minutes previously used the manual override button on both zone valve relays to open and then close the zone valves manually.

          The button on the relays whether used to turn on or off the relay acts as a kind of "temporary override" which eventually resumes normal operation automatically. At the time the relay should have turned on it must have still been in the override state. After about another 10 minutes they started working again.

          DOH! The question is (and perhaps top brake or Ramses can answer this) how long does the manual override from pressing the button stay in effect ?

          Is it a fixed time period like 10 minutes, or does it only last until the controller sends a change of heat demand ? I think it's the latter, but I'm not certain.

          If I only had a one or two relay configuration I would have never noticed a missed relay activation, it's only because the three relay configuration normally has both a zone valve and boiler relay come on and go off at the same time that one of the relays not responding was noticed.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #20
            Originally posted by g6ejd View Post
            https://www.google.co.uk/url?sa=t&rc...5QGJzSSqDQVcaw

            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.

            Could have been written:

            It is a well controlled relatively ‘quiet’ band used by manufacturers broadcasting ZigBee & Z-wave protocols and the bespoke protocol adopted by Honeywell Ramses II also works in this area.
            Yes it is poorly worded but it looks clear that what the mean to say is that they use the same 868Mhz frequency band as ZigBee and Z-wave, but using their own proprietary protocol.

            How well Honeywell's protocol stands up to interference from ZigBee and Z-Wave is an interesting question if it pre-dates both of those other protocols development, and we know that it is a largely acknowledgement free protocol...

            Comment

            • paulockenden
              Automated Home Legend
              • Apr 2015
              • 1719

              #21
              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; 23 October 2016, 10:08 PM.

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #22
                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; 23 October 2016, 10:25 PM.

                Comment

                • paulockenden
                  Automated Home Legend
                  • Apr 2015
                  • 1719

                  #23
                  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.).

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    #24
                    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.

                    Comment

                    • paulockenden
                      Automated Home Legend
                      • Apr 2015
                      • 1719

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

                      Comment

                      • DBMandrake
                        Automated Home Legend
                        • Sep 2014
                        • 2361

                        #26
                        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...

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          #27
                          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; 25 October 2016, 10:13 AM.

                          Comment

                          • HenGus
                            Automated Home Legend
                            • May 2014
                            • 1001

                            #28
                            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.

                            Comment

                            • DBMandrake
                              Automated Home Legend
                              • Sep 2014
                              • 2361

                              #29
                              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; 25 October 2016, 12:44 PM.

                              Comment

                              • DBMandrake
                                Automated Home Legend
                                • Sep 2014
                                • 2361

                                #30
                                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; 30 October 2016, 11:49 AM.

                                Comment

                                Working...
                                X