Results 1 to 3 of 3

Thread: Using evohome_rf as a Python transport

  1. #1
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default Using evohome_rf as a Python transport

    For you Python programmers: (evohome_rf) provides all sorts of advantages, including discovery, tracking state, QoS, and the most complete set of parsers.

    Here, we discuss using it to eavesdrop the RAMSES protocol (you can send commands too).

    Perhaps you want to write an MQTT or a node-RED wrapper?

    You can use evohome_rf as an async transport: a template protocol is provided, via a protocol_factory, create_client().

    I think an example says it all:

    Code:
    import asyncio
    from evohome_rf import Gateway
    
    def process_message(msg) -> None:
        print(f"{msg.dtm} {msg}")
    
    async def main(loop, serial_port, **config):
        if sys.platform == "win32":  # YMMV: ERROR:asyncio:Cancelling an overlapped future failed 
            asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
    
        config = {"reduce_processing": 1}
    
        gwy = Gateway(serial_port, loop=loop, **config)
        protocol, _ = gwy.create_client(process_message)
    
        try:
            await asyncio.create_task(gwy.start())
        except asyncio.CancelledError:
            pass
    
    loop = asyncio.get_event_loop()
    loop.run_until_complete(main(loop, "/dev/ttyUSB0"))
    loop.close()
    In this case, process_message is your own callback, and you can put anything in there (such as dispatching to MQTT):
    Code:
    def process_message(msg) -> None:
        {print(k, v) for k, v in msg.payload.items()}
    The output of the above will look like:
    Code:
    2020-11-08 21:06:55.241989 || TRV:189082 | CTL:145038 |  I | setpoint         | 06073A   || {'parent_idx': '06', 'setpoint': 18.5}
    2020-11-08 21:06:55.256636 || TRV:189082 | CTL:145038 |  I | window_state     | 060000   || {'parent_idx': '06', 'window_open': False}
    2020-11-08 21:07:21.556830 || STA:136285 |            |  I | temperature      | 0007A3   || {'temperature': 19.55}
    2020-11-08 21:08:50.299288 || STA:064023 |            |  I | temperature      | 0007AB   || {'temperature': 19.63}
    2020-11-08 21:08:54.714936 || CTL:145038 |            |  I | system_sync      | FF073F   || {'remaining_seconds': 185.5, '_next_sync': '21:12:00'}
    Last edited by zxdavb; 8th November 2020 at 09:28 PM.

  2. #2
    Automated Home Lurker
    Join Date
    Oct 2020
    Posts
    2

    Default

    Oh wow, this is what I'm looking for. I was using evohome-Listener to figure out what to do with a setpoint overshooting / OpenTherm boiler setpoint issue, but this is way cleaner. Thanks for creating this project! I look forward to code on top of it, my specialty is Django/PostgreSQL.


    Maybe you know what to do about this little issue I have - when capturing the data, often enough, I see some bad / truncated packets / Invalid Manchester Code errors, is this something fixable in software / firmware (using evofw3, uart branch), or is the 10cm omni antenna on my NanoCUL too weak to receive everything?

    It often happens in the opentherm_msg request/reply storm, and it also seems like the R8810A1018 isn't having perfect reception either, the controller sometimes repeat the query a few times before a reply comes back.

  3. #3
    Automated Home Guru
    Join Date
    Feb 2016
    Posts
    244

    Default

    Quote Originally Posted by booinky View Post
    Maybe you know what to do about this little issue I have - when capturing the data, often enough, I see some bad / truncated packets / Invalid Manchester Code errors, is this something fixable in software / firmware (using evofw3, uart branch), or is the 10cm omni antenna on my NanoCUL too weak to receive everything?

    It often happens in the opentherm_msg request/reply storm, and it also seems like the R8810A1018 isn't having perfect reception either, the controller sometimes repeat the query a few times before a reply comes back.
    I think you're using the current best firmware for the NanoCUL and these message reception errors are a limitation of the performance of the device+firmware due to variations in the message timing. I have a couple of the NanoCULs as part of my testing set-up and see exactly the same behaviour (with evofw3-uart) and it's mainly with the messages from the OT bridge, but this is definitely the best performance currently possible with the NanoCUL. I also have a Honeywell HGI80 which is able to receive the messages successfully which I use for comparison. It's all work in progress, but we're hoping that a different hardware platform using the Atmega32u4 utilising its hardware UART will achieve performance similar to the HGI80 and our testing to date has confirmed this.

    Dan

Posting Permissions

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