Using evohome_rf as a Python transport

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • zxdavb
    Automated Home Guru
    • Jan 2018
    • 106

    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; 8 November 2020, 10:28 PM.
  • booinky
    Automated Home Lurker
    • Oct 2020
    • 2

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

    Comment

    • DanD
      Automated Home Ninja
      • Feb 2016
      • 250

      #3
      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

      Comment

      Working...
      X