Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: evohome-listener - some questions

  1. #1
    Automated Home Guru
    Join Date
    Oct 2020
    Posts
    160

    Default 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.

  2. #2
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    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:

    https://github.com/zxdavb/evohome_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.

  3. #3
    Automated Home Guru
    Join Date
    Oct 2020
    Posts
    160

    Default

    Quote 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:

    https://github.com/zxdavb/evohome_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.

  4. #4
    Automated Home Guru
    Join Date
    Oct 2020
    Posts
    160

    Default

    Quote 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,
    }

  5. #5
    Automated Home Guru
    Join Date
    Oct 2020
    Posts
    160

    Default

    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.

  6. #6
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote 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.

  7. #7
    Automated Home Guru
    Join Date
    Oct 2020
    Posts
    160

    Default

    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%

  8. #8
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote 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; 21st October 2020 at 07:32 PM.

  9. #9
    Automated Home Sr Member
    Join Date
    Feb 2018
    Posts
    57

    Default

    Quote 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.

  10. #10
    Automated Home Guru
    Join Date
    Jan 2018
    Posts
    106

    Default

    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.automatedhome.co.uk/vbul...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; 23rd October 2020 at 11:26 AM.

Tags for this Thread

Posting Permissions

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