Evohome : opentherm compatibility problem with Navien combi

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • bheading
    Automated Home Jr Member
    • Aug 2020
    • 15

    Evohome : opentherm compatibility problem with Navien combi

    Hi all,

    I've had an evohome setup, with a Honeywell Opentherm gateway, for just over a year now, working fine with my old Ferroli boiler.

    However, recently I had the boiler replaced with a shiny new Navien unit.

    As best I can tell, in Opentherm mode, the Navien disables front panel control of both the heating and the hot water. However, the Evohome does not seem to send the necessary command that the boiler expects, so hot water remains disabled.

    I signed up for the Evohome beta and it is now running on my Evotouch but this has not had any effect on the problem.

    To solve the problem the boiler installer has loaned me a BDR91 and put the boiler in regular switched thermostat mode, which works perfectly but obviously I lose the benefits of Opentherm.

    Is there anything I can do here other than hope that either the evohome or the boiler have their firmware updated to account for this scenario ?
  • kevinsmart
    Automated Home Ninja
    • Sep 2018
    • 257

    #2
    Originally posted by bheading View Post
    Hi all,

    I've had an evohome setup, with a Honeywell Opentherm gateway, for just over a year now, working fine with my old Ferroli boiler.

    However, recently I had the boiler replaced with a shiny new Navien unit.

    As best I can tell, in Opentherm mode, the Navien disables front panel control of both the heating and the hot water. However, the Evohome does not seem to send the necessary command that the boiler expects, so hot water remains disabled.

    I signed up for the Evohome beta and it is now running on my Evotouch but this has not had any effect on the problem.

    To solve the problem the boiler installer has loaned me a BDR91 and put the boiler in regular switched thermostat mode, which works perfectly but obviously I lose the benefits of Opentherm.

    Is there anything I can do here other than hope that either the evohome or the boiler have their firmware updated to account for this scenario ?
    What kind of Navien boiler is it, a combi? So heating mode is working, but the hot water mode temperature is not set correctly?

    The issue could probably be debugged and fixed with an OpenTherm Gateway. It could be that the DHW setpoint temperature needs set as the boiler is not reporting it correctly. With this gateway intercepting communication between the Evohome OpenTherm bridge and the boiler, it can be programmed by its Opentherm Monitor application to set the DHW setpoint.



    You can buy one ready built.

    I've read that issues like this with other boilers (e.g. Vokera) can be resolved by plugging in the manufacturer's OpenTherm controller to set up the parameters. Then when the Evohome OpenTherm bridge is reconnected everything works. I'm not sure whether this is persistent in the case of a power loss though.

    Comment

    • bheading
      Automated Home Jr Member
      • Aug 2020
      • 15

      #3
      Kevin, yes, it is indeed a combi - I should have been clearer.

      I was also thinking that it looks like the best idea, short of a proper fix, is to purchase a gateway, which would be handy thing to keep around in any case. Power loss is rare around here but it can happen. The Navien does seem to keep its temp settings in some kind of non volatile RAM so it's possible we would be quite safe here.

      It's been suggested to be elsewhere that the bait and switch technique you mention could work too.

      I will investigate and report back.

      Comment

      • bheading
        Automated Home Jr Member
        • Aug 2020
        • 15

        #4
        I had another thought about this : I wonder if it might be possible to set a hot water setpoint to the Opentherm gateway using wireless, ie Rameses II.

        I know the wireless protocol is not the same as native Opentherm, but it seems likely that the gateway might support a command to set the DHW setpoint ..

        (edit):

        Interestingly, RAMSES II seems to have an Opentherm message type (https://github.com/Evsdd/The-Evohome...nTherm-Message) which seems to be used to send Opentherm messages directly. This makes the Honeywell OT gateway a fairly simple device which is presumably decoding RAMSES-II messages towards the boiler, and encoding them on the way back.

        If I can get an RF device for an Arduino/RPI that can inject Opentherm message #56, in theory this should work ..
        Last edited by bheading; 2 September 2020, 02:55 PM.

        Comment

        • bheading
          Automated Home Jr Member
          • Aug 2020
          • 15

          #5
          So a while back I got an RFBee and UARTSBee. As others have recorded here, this setup is OK but not great, and has been superceded by better approaches (my new SSM-2 based device is now on order!). However, I was able to get some success with it.

          I flashed the RFBee using the evsdd Development branch of the EvohomeWirelessFW. This seems to be much more stable than the main branch and better able to pick out the RAMSES data. As indicated it is not perfect, I estimate it's dropping around 30% of the messages. But it's good enough to work.

          The solution turns out to be dead simple with the excellent ramses_rf suite. The command is as follows, and should work on any Opentherm boiler connected with an R8810A Opentherm gateway. Using ramses_rf client.py :

          ./client.py -lf execute -o write.log -x'RQ 10:133866 3220 0010383C00' /dev/ttyUSB0

          Let's break that down :
          10:133866 is the ID of the R8810A.
          0x3220 is the RAMSES OpenTherm Message command.

          encoded into the data payload is :

          - first byte is zero.
          - byte 1 is the msg type nibble : the parity bit is 0, the message type is 001 (0x1) = WRITE_DATA
          - byte 2 is the command ID 56 (Opentherm "DHW Setpoint") = 0x3C
          - bytes 3 and 4 are the value in Opentherm f8.8 format. This is calculated by multiplying the required temperature by 256 - 60 x 256 = 15360 = 0x3C00.

          ramses_rf thinks that this sequence of bytes is invalid. The regular expression they are using is wrong, it expects 00, followed by 4 hex digits and 4 zeros, which is not correct. I think it should be '^00[0-9A-F]{8}$'. Anyway, here is the output.

          09:52:36.445 RQ --- 18:056026 10:133866 --:------ 3220 005 0010383C00 < Corrupt payload: Payload doesn't match '^00[0-9A-F]{4}0{4}$': 0010383C00
          2022-09-05T09:52:36.444430 || HGI:056026 | 10:133866 | RQ | opentherm_msg | 38 || {'msg_id': 56, 'msg_type': 'Write-Data', 'msg_name': 'DHWSetpoint', 'value': 60.0, 'description': 'DHW setpoint'}
          2022-09-05T09:52:36.849322 || OTB:133866 | HGI:056026 | RP | opentherm_msg | 38 || {'msg_id': 56, 'msg_type': 'Write-Ack', 'msg_name': 'DHWSetpoint', 'value': 60.0, 'description': 'DHW setpoint'}


          Now DHW works.

          One interesting detail is that if the boiler is power cycled, it forgets the setting, so it needs to be reapplied. That would mean that any Opentherm controller would have to poll the settings at a regular interval to check they have been set correctly and apply as appropriate.

          The Evohome controller itself seems to poll the boiler every couple of minutes to check a number of parameters - I get the pressure reading as well as the live flow and return temperature. It should be possible for something like Domoticz to do this, this would allow continuous monitoring to confirm whether or not the boiler return temperature is being kept below 55 degrees.

          Comment

          Working...
          X