Using evohome_rf as a Python transport

[zxdavb]

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:

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

def process_message(msg) -> None:
    {print(k, v) for k, v in msg.payload.items()}

The output of the above will look like:

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'}

[booinky]

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.

[DanD]

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