evohome-listener - some questions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • lloyd
    Automated Home Guru
    • Oct 2020
    • 160

    evohome-listener - some questions

    Just started playing with evohome-listener, and I've got a few questions. To start with, I'm picking up a device type 12. But this is not defined anywhere. Any idea what this might be?

    The other question is what is zone 252? I'm seeing entries like this:

    2020-10-19 18:23:23 |1/073| ZONE_HEAT_DEMAND | I | CONTROLLER -> BROADCAST MESSAGE | 43.0% [Zone 252]

    I'm guessing it is the boiler relay, but I've defined that as Zone 99 in devices.json (or is it hardcoded to 252)?

    Great piece of software btw.
  • DBMandrake
    Automated Home Legend
    • Sep 2014
    • 2361

    #2
    What are you using as your receiver ? An HGI80 or something like a NanoCUL with CC1101 ?

    I'm using the latter and although I tried evohome-listener and got it to sort of work last year, I later settled on evohome_rf which does a very similar thing:

    An interface for the RAMSES RF protocol, as used by Honeywell-compatible HVAC & CH/DHW systems. - zxdavb/ramses_rf


    So might be worth checking that out too in case it can decode more packet and device types. It is also written in Python, although it needs a fairly recent version of Python 3 to work properly.

    I actually have it running 24/7 as a background service on a Raspberry Pi 2 logging all Evohome related traffic in the house and find it very useful for troubleshooting or just learning how the over the air comms works.

    Comment

    • lloyd
      Automated Home Guru
      • Oct 2020
      • 160

      #3
      Originally posted by DBMandrake View Post
      What are you using as your receiver ? An HGI80 or something like a NanoCUL with CC1101 ?
      I put together a Nano and C1101 (cheaper and quicker than buying one ready assembled), and its running on a Pi that acts as a media server. Now I want to find a MQTT broker, free if possible, and a good client for graphing.

      I'm using the latter and although I tried evohome-listener and got it to sort of work last year, I later settled on evohome_rf which does a very similar thing:

      An interface for the RAMSES RF protocol, as used by Honeywell-compatible HVAC & CH/DHW systems. - zxdavb/ramses_rf


      So might be worth checking that out too in case it can decode more packet and device types. It is also written in Python, although it needs a fairly recent version of Python 3 to work properly.
      For the moment I'll probably stick with evohome-listener. It seems to do what I need, and I know I can fall into the trap of trying lots of similar packages and diluting my efforts, rather than persisting with one. But what I will do is look at the source for evohome_rf and see if that casts any light on my device type 12. So thanks for the heads up on that one.

      Comment

      • lloyd
        Automated Home Guru
        • Oct 2020
        • 160

        #4
        Originally posted by lloyd View Post
        But what I will do is look at the source for evohome_rf and see if that casts any light on my device type 12. So thanks for the heads up on that one.
        And immediately I come up 12: Thermostat. Which of course I do not have
        Code:
        DEVICE_CLASSES = {
            "01": Controller,  # use EvoSystem instead?
            "02": UfhController,
            "03": Thermostat,
            "04": TrvActuator,
            "07": DhwSensor,
            "10": OtbGateway,
            "12": Thermostat,
            "13": BdrSwitch,
            "22": Thermostat,
            "23": Controller,  # a Programmer, use System instead?
            "34": Thermostat,
        }

        Comment

        • lloyd
          Automated Home Guru
          • Oct 2020
          • 160

          #5
          Probably bad form to be replying to my own posts but...

          Seems the device 12 messages are always associated with an invalid Manchester code, so probably ok to ignore.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #6
            Originally posted by lloyd View Post
            And immediately I come up 12: Thermostat. Which of course I do not have
            A neighbour perhaps ? It's not just Evohome that uses this wireless protocol. All the Honeywell wireless thermostats use the same protocol, so it could easily be a neighbour with a single zone thermostat.

            Comment

            • lloyd
              Automated Home Guru
              • Oct 2020
              • 160

              #7
              OK. Next question.

              Should the demand percentages that are decoded by evohome_listener (or evohome_rf) be the same as the values that I see on the controller. Because they are very different. I suspect the only times they agree are when they are 0% and 100%

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #8
                Originally posted by lloyd View Post
                OK. Next question.

                Should the demand percentages that are decoded by evohome_listener (or evohome_rf) be the same as the values that I see on the controller. Because they are very different. I suspect the only times they agree are when they are 0% and 100%
                No, they are not the same.

                The "heat demand" from an HR92 is actually just the valve pin position from 0-100%. This is what gets sent over the air and what you will receive when doing your own logging, and you should find what you receive over the air with the above programs will match the valve pin position reported by the HR92 on option screen 10.

                The controller applies a non-linear function to this valve pin position to derive the actual heat demand which is displayed in the System Summary page and used to control the boiler relay. I've previously derived this non-linear function empirically as shown in this graph:



                As you can see a valve pin position of less than 30% maps to a zero heat demand. This is done because water doesn't usually start to flow until an indicated valve pin position of >30%. Above 70% water is usually fully flowing so beyond that heat can only be controlled by boiler demand, this is why the slope doubles between 70% and 100% to keep the overall control of heat output of the radiator as linear as possible.
                Last edited by DBMandrake; 21 October 2020, 07:32 PM.

                Comment

                • smar
                  Automated Home Sr Member
                  • Feb 2018
                  • 57

                  #9
                  Originally posted by lloyd View Post
                  Just started playing with evohome-listener, and I've got a few questions. To start with, I'm picking up a device type 12. But this is not defined anywhere. Any idea what this might be?

                  The other question is what is zone 252? I'm seeing entries like this:

                  2020-10-19 18:23:23 |1/073| ZONE_HEAT_DEMAND | I | CONTROLLER -> BROADCAST MESSAGE | 43.0% [Zone 252]

                  I'm guessing it is the boiler relay, but I've defined that as Zone 99 in devices.json (or is it hardcoded to 252)?

                  Great piece of software btw.

                  Hi @Lloyd

                  Device type 12 - this is not defined as none of my devices have that type number!

                  Zone 252 - this is an internal number hard coded into evohome and is coming from the evohome devices.

                  Comment

                  • zxdavb
                    Automated Home Guru
                    • Jan 2018
                    • 106

                    #10
                    If I may advertise my own work.

                    evohome_rf (https://github.com/zxdavb/evohome_rf) has a goal of decoding every known packet type, and as much of each code' s payload as is possible. For example, the list of all known device types is in const.py (e.g. 17:, 23:, etc.) and all known packet codes in parsers.py. It is definitely not limited to evohome. It is over 8,000 LoC, but is still under development.

                    In addition, it has some intelligence with respect to the evohome protocol, and is not restricted to merely decoding packet payloads in isolation of each other. Thus, it could tell you when your system is misconfigured (from testing, this is surprisingly common).

                    There is documentation of the protocol at (https://github.com/Evsdd/The-Evohome-Protocol/wiki), but I have struggled to keep it up to date, and this is now well-behind what **evohome_rf** knows. For example, the 0005 and 000C packets are now fully understood - see: https://www.wordpress-1219309-438749...ol-site-survey

                    It is not only a listener (although it can be run in read-only mode); for example, if it sees a I/3EF0 packet, it sends a corresponding RQ/0008 & RQ/3EF1s to update all available state data for that relay.

                    It doesn't do MQTT, and only has a CLI, but it is designed to integrate tightly with HomeAssistant (https://github.com/zxdavb/evohome_rf) (and with that, you can do anything, MQTT, node-red, etc).

                    Oh, picking up your neighbour's devices is common too - evohome_rf has a blacklist/whitelist facility.
                    Last edited by zxdavb; 23 October 2020, 11:26 AM.

                    Comment

                    • smar
                      Automated Home Sr Member
                      • Feb 2018
                      • 57

                      #11
                      Great piece of work @zxdavb! Had I seen yours before, I wouldn't have bothered doing the evolistener script, and would have just used yours as the basis for what I need!

                      Would you consider hooking it up to MQTT, so that other home automation systems (e.g. openHAB) can also use it?

                      Comment

                      • zxdavb
                        Automated Home Guru
                        • Jan 2018
                        • 106

                        #12
                        Thanks.

                        I started mine less than a year ago - so still suffering from teething problems - even this week, I am still learning new things about the packets / the protocol - but I think I got it sorted now. It just took ages to work a lot of things out - like when the first two bytes of a payload are for zone 0, or they just null bytes!

                        I would implement MQTT/Node-RED/etc. - I am just too short of time - I think it's going to take another year to get evohome_cc working for HA (and it exposes issues in evohome_rf).

                        It is designed as a library to be used by a (wrapping) client - it includes a very basic client.py as a CLI. It is completely async, and includes QoS (Throttling, Priority, Retries) when transmitting packets and I could easily enough set it up to expose itself as a transport, then you can do anything by writing a wrapper as a protocol and have the benefits of callbacks.

                        I am keen to help people do this.

                        If you'd like to collaborate, then I'd be could implement the transport sooner rather than later. Then you just have to have code like below.

                        You could replace all your packet/payload processing with:
                        Code:
                        def self._mgtt_callback(msg.payload):
                            ...
                        where msg.payload is a simple dict.

                        This is the full protocol. You send command to send_data, and receive messages at mqtt_callback.

                        Code:
                        class EvohomeProtocol(asyncio.Protocol):
                            def __init__(self, mqtt_callback) -> None:
                                self._transport = None
                                self._pause_writing = None
                                self._mqtt_callback = mqtt_callback
                        
                            def connection_made(self, transport: SerialTransport) -> None:
                                """Called when a connection is made."""
                                self._transport = transport
                        
                            def data_received(self, msg):
                                """Called when some data is received."""
                                self._mqtt_callback(msg.payload)
                        
                            async def send_data(self, command) -> None:
                                """Called when some data is to be sent (not a callaback)."""
                                while self._pause_writing:
                                    asyncio.sleep(0.1)
                        
                                await self._transport.write(command)
                        
                            def connection_lost(self, exc: Optional[Exception]) -> None:
                                """Called when the connection is lost or closed."""
                                if exc is not None:
                                    pass
                                self._transport.loop.stop()
                        
                            def pause_writing(self) -> None:
                                """Called when the transport's buffer goes over the high-water mark."""
                                self._pause_writing = True
                        
                            def resume_writing(self) -> None:
                                """Called when the transport's buffer drains below the low-water mark."""
                                self._pause_writing = False
                        Last edited by zxdavb; 5 November 2020, 10:45 PM.

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          #13
                          Evohome hackers untie!

                          No, unite!

                          Comment

                          • philchillbill
                            Automated Home Legend
                            • Jan 2017
                            • 590

                            #14
                            If I were to run evohome_rf with my hgi80, does it have to have exclusive access to the hgi80 or would it be OK to have Domoticz also butting in from time to time with its own serial access to the hgi80? Is there any 'hold_off' functionality, as it were?

                            Comment

                            • smar
                              Automated Home Sr Member
                              • Feb 2018
                              • 57

                              #15
                              Originally posted by zxdavb View Post
                              Thanks.

                              If you'd like to collaborate, then I'd be could implement the transport sooner rather than later. Then you just have to have code like below.
                              That would be great! No urgency though, as I am a bit tied up with some work at the moment, and may not be able to give much time at the immediate moment, but definitely something worth doing. Please do keep me posted, whether here or maybe better on github?

                              Comment

                              Working...
                              X