Results 1 to 9 of 9

Thread: fun with evohome and rfbee

  1. #1
    Automated Home Jr Member
    Join Date
    Aug 2020
    Posts
    15

    Default fun with evohome and rfbee

    To investigate my problems with Opentherm/Evohome and my new boiler (ref. in another thread) I decided to get an RFBee and UartSBee.

    To my pleasant surprise, this took about ten minutes to get working. I flashed the Evohome Firmware to the RFBee, reset it and it started dumping out the RAMSES-II messages on the serial port. Using the documentation on gitlab I was able to manually decode the hex to understand the message. Since I am using a regular BDR91, an evotouch and a bunch of HR92s, the messages passing to and fro seem to be completely consistent with the documentation on the wiki provided by "evsdd".

    Rather than me decode the hex values by hand it would be handy if there was a script/tool that would sit on the serial port and decode each packet as it comes in - and even better, allow me to generate outgoing packets. Does such a thing exist ?

    My thinking here is to leave the evotouch in place to manage the heating, but to augment it with something like Domoticz which can log statistical information and also allow me to control the Opentherm DHW setpoint.

  2. #2
    Automated Home Ninja
    Join Date
    Feb 2016
    Posts
    250

    Default

    Have a search for evohome_rf or evohome-listener. They should be able to provide some of the functionality you're looking for. Evohome_rf can send messages too.

  3. #3
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    2,307

    Default

    The device of choice is noW a NanoCUL because the evofw3 written by Pete has been optimised to work on it using the faster clock and the additional memory it provides.
    The evohome_rf is the decoder of choice as it is constantly maintained with the RF protocol as we learn more.
    Last edited by bruce_miranda; 22nd October 2020 at 01:36 PM.

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

    Default

    Quote Originally Posted by bruce_miranda View Post
    The device of choice is not a NanoCUL because the evofw3 written by Pete has been optimised to work on it...
    Is there a typo in the first part of that post? Should it read now instead of not?

  5. #5
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    2,307

    Default

    yes sorry. It is absolutely recommended

  6. #6
    Automated Home Jr Member
    Join Date
    Aug 2020
    Posts
    15

    Default

    Thanks for this - I will try evohome_rf.

    Quote Originally Posted by bruce_miranda View Post
    The device of choice is noW a NanoCUL because the evofw3 written by Pete has been optimised to work on it using the faster clock and the additional memory it provides.
    Do you mind if I ask what "optimised" means here ?

  7. #7
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    57

    Default

    The evohome system is made of multiple radio transmitters. They're all trying to behave like wireless UARTs at 28400 baud.

    Unfortunately they all have their own crystal from which the baudrate is generated and all these crystals are slightly different.

    ideally, you want a HW UART to try interpret the received signal because this will be best able to deal with the variation in the transmitters it's listening to.

    Unfortunately, the nanoCUL doesn't have an available HW UART, unlike the Honeywell devices which do not use their UART to communicate with a PC.
    This means evofw3 has to implement a SW UART on nanoCUL devices. This is only possible on 16MHz devices because of the processing required.

    Better devices for evofw3 are atmega32u4 based because this has a direct USB connection to any host PC leaving a HW UART free to communicate with the radio interface.
    evofw3 will run on 8MHz atmega32u4 devices.

    Until recently the only packaged atmega32u4 devices that would support this behaviour were CULV3 devices.

    Unfortunately the available devices were based on unreliable CC1101 modules which appear to have very poor crystals making it difficult to successfully receive the transmitted messages.
    CULFW should be able to receive evohome (RAMSES II) messages adequately but transmission is more difficult because of the variation in both the MCU crystal and CC1101 crystals.
    I Suspect Honeywell avoid this problem by using components with low tolerance values.

    The latest version of evofw3 (0.7.0) uses different RX mechanisms depending on the platform but a common TX method that avoids the clock conflicts.

  8. #8
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    57

    Default

    38400 baud

  9. #9
    Automated Home Lurker
    Join Date
    Apr 2013
    Posts
    1

    Default

    When I wrote the culfw support for Ramses/EvoHome, both the V1 and V3 devices I tried had good crystals and work reliably in send and receive mode. But I've a friend with a NanoCUL and a poor tolerance crystal seeing exactly the problems you describe. Swapping the crystal for a better tolerance unit fixed the problem, and wasn't too hard given I'm used to SMT work. But its a pain that this is needed. Adding calibration / autotune support for culfw is on a long list of outstanding projects.

    More generally, really good to see all the work on improving general EvoHome support via DIY hardware and well developed software!

Posting Permissions

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