Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

This is odd - send me a packet log & a HA log. AFAIK, there is no means for a relay to change its role (i.e. there is a bug).

@DanRP Try the latest release.

Looking good. Thanks!

I’ve just noticed this error.

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/ 
First occurred: 27 September 2021, 6:00:36 (2 occurrences) 
Last logged: 3:17:24

RP --- 10:051349 18:135447 --:------ 3220 005 00601B0003 << AssertionError(OpenTherm: Invalid msg-type|data-value: Data-Invalid|0003)
RP --- 10:051349 18:135447 --:------ 3220 005 00601B0FFF << AssertionError(OpenTherm: Invalid msg-type|data-value: Data-Invalid|0FFF)
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/", line 354, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/", line 116, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/", line 1580, in parser_3220
    assert (
AssertionError: OpenTherm: Invalid msg-type|data-value: Data-Invalid|0003

This could be just a simple corrupt packet.

It looks like the faking has been causing my boiler some issues. Over the last few days, the temperature has dropped so my boiler has been firing up, but not getting my rooms up to temperature. I’ve sat and watched the flame light and call demand on the boiler and it’s been all over the shop. With all rooms demanding 100% I’m getting the call light on but the flame is only on for around a minute at a time and then off for around 2 minutes, sometimes the call demand goes to 0 and then straight to call again. Which means the radiators never get hot.

I unplugged my SSM(R) and the boiler call for heat came on and the flame light stayed on until the radiators got so hot you couldn’t touch them! I then plugged back in my SSM(R) and reset home assistant and as soon as it started up it went back to the flame on-off all the time.

At the minute I’ve disabled the faking and everything seem as it should be.


It may not be the faking as it didn’t work correctly for long with the faking removed. SSM(R) unplugged and within a minute the boiler is doing what it should.

I doubt faking is to blame. The boiler relay will only do what the controller asks of it. Have a look at the zone temperatures / setpoint schedule, and especially the return CV temp…

This could be anything. You simply haven’t provided enough evidence to support your hypothesis.

Have a look at a graph like the following (13_237335 is my boiler relay):

type: history-graph
  - entity: binary_sensor.13_237335_active
  - entity: sensor.01_145038_heat_demand
hours_to_show: 8

This graph will connect heat demand with TPI (on/off of relay) (assuming you don’t have an OTB)…

Also, seek to understand what your boiler will do when a call for heat is made (assuming you have a boiler)… For example, it may cut off if the return CV temp is too high (so that condensing is assured).

I understand how my boiler works and it’s opentherm so shouldn’t be cycling on and off. All zones set to 30 and rooms around 20, boiler set to highest temperature and I can hold my hands on flow and return pipe work, as soon as I unplug the ssm usb stick the boiler acts like it should and heats up and stops the cycling.

Ah! - I am open to the idea that there is an issue with OpenTherm - could you kindly send me a packet log?

Are you able to try this and see if it makes any difference?

    disable_discovery: true

For clarity… Whatever is going on, it won’t be the fault of the faking.

I’ve not worked out how to set the packet logs up yet.

I’ve added the other part to my configuration.

Just in case anyone’s interested, I have put together a template for the button-card custom component that displays Evohome entities in clear tiles. It’s for my own personal use but I figured I’d share it in case anyone else found it helpful. Specifically I designed it to be quick and easy to read on a mobile screen, making it obvious which zones are calling for heat and any other useful information. It pulls together the various entities that make up a zone.


I’ve added the below to my configuration file and now seem to have lots of messages in my home assistant logs, is that where I find what your looking for?

  default: warn  # prefer warn over info, avoid debug
    # homeassistant.core: debug  # to see: Event state_changed, or not
    # homeassistant.loader: info  # You are using a custom integration for evohome_cc...
    # homeassistant.setup: info  # Setting up evohome_cc

    # custom_components.evohome_cc: info  # use info for Schema =

    # ramses_rf: debug  # for engine state
    ramses_rf.message: info   # for MSGs received (incl. sent & subsequently echo'd)
    # ramses_rf.protocol: warn
    # ramses_rf.protocol.protocol: info  # for PKTs sent (excl. retries) & received
    # ramses_rf.protocol.transport: info   # for RF Tx & Rx

    # ramses_rf.devices: debug
    # debug
    # ramses_rf.zones: debug

The file I am looking fro is this one:

  packet_log: /home/dbonnes/home-assistant/.config/packet.log

How you get a copy of it to me depends upon what “Installation Type” of HA you are running. For example, for “Home Assistant OS”, I use the VS code add-on.

Thanks, I’ll try and work it out.

At the minute rebooting home assistant solves the problem for a while.

I understand some people are using ser2net - just be aware that support for this is somewhat experimental.


  serial_port: rfc2217://localhost:5001


# HGI80-like ser2net connection that allows multiple connections
connection: &con00
  accepter: telnet(rfc2217),tcp,5001
  timeout: 0
  connector: serialdev,/dev/ttyUSB0,115200n81,local
    max-connections: 3

There are known issues with other versions of ser2net, but it does work for me.

Someone asked:

Either way, my 2nd problem, the head demand for TRVs and the Controller frequently shows “unavailable” and a bit later they again turn to normal. This is for ALL my TRVs as well as the Controller, no matter the distrance to my nanocul. Correspondingly, their graphs shows gaps, see pictures. And funny enough, all temperatures from all the STAs never show “unavailable”, their graphs have no gaps

Do you have any idea why is going on? Is there something I’m doing wrong in the configuration?

The answer is…

I have implemented ‘timeouts’ for packets, so that stale data is ignored.

An evohome system will spontaneously send I packets for all sorts of state data, and ramses_rf will augment that by sending RQ packets - the corresponding RP packets become part of the state data too.

If you stop ramses_rf from sending these RQ packets, or if there is another reason why they are not sent, then it is more likely that that state data will expire - you will see that sensor will become unavailable.

I’ve got the packet logs working but it’s too big to send to you?

dropped packets are a normal thing (RAMSES II has no QoS) - and worse, the controller can pick up a packet that ramses_rf doesn’t, and vice-versa

Here is an example:

~/c/ramses_rf (master) [0|1]> cat packet_2021010-08.log | grep '069003.* 3150 ' | python parse


00:40:59.030 || TRV:069003 | CTL:197498 |  I | heat_demand      |  07  || {'zone_idx': '07', 'heat_demand': 0.0}
01:20:57.995  I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (200%)
01:20:57.995 || TRV:069003 | CTL:197498 |  I | heat_demand      |  07  || {'zone_idx': '07', 'heat_demand': 0.0}
02:20:57.473  I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (300%)
02:20:57.473 || TRV:069003 | CTL:197498 |  I | heat_demand      |  07  || {'zone_idx': '07', 'heat_demand': 0.0}
02:40:57.574 || TRV:069003 | CTL:197498 |  I | heat_demand      |  07  || {'zone_idx': '07', 'heat_demand': 0.0}
03:00:56.158 || TRV:069003 | CTL:197498 |  I | heat_demand      |  07  || {'zone_idx': '07', 'heat_demand': 0.0}

These 3150 packets should be sent at least every 20 minutes.

After the first packet was received at 00:40:59, the next packet was never received at approx 01:00:00), so the first packet expired before the 3rd packet was received at 01:20:57

Note (things have been simplified, above), the actual expiry of the packet would be as follows:

01:03:15.718  I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (111%)

That is, packets are expired at 110%, not 200% and so this particular heat demand would be unavailable from 01:03:15 to 01:20:57.

Place into file share website somewhere, and PM me the link.