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

[zxdavb (David Bonnes)]

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…

@stevieb12345

but the flame is only on for around a minute at a time and then off for around 2 minutes

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

[stevieb12345]

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.

[zxdavb (David Bonnes)]

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?

evohome_cc:
  config:
    disable_discovery: true

[zxdavb (David Bonnes)]

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

[stevieb12345]

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

I’ve added the other part to my configuration.

[sOckhamSter]

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.

Custom Button-Card Template for EVOHOME_CC / RAMSES_RF

I’ve put together a template for displaying Evohome heating zones from entities created by the evohome_cc / RAMSES_RF custom component integration. It’s easy to tweak and reasonably compact, whilst displaying a lot of information. It’s designed to be used in a Lovelace grid of two columns for optimum mobile viewing, but will work in a single column too. [61CC0A47-E471-4CBA-9401-A9E23552D710] Firstly, make sure you have the evohome_cc and the button-card components installed. HACS is the easie…

[stevieb12345]

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?

logger:
  default: warn  # prefer warn over info, avoid debug
  logs:
    # 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
    # ramses_rf.systems: debug
    # ramses_rf.zones: debug

[zxdavb (David Bonnes)]

The file I am looking fro is this one:

evohome_cc:
  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.

[stevieb12345]

Thanks, I’ll try and work it out.

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

[zxdavb (David Bonnes)]

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

configuration.yaml

evohome_cc:
  serial_port: rfc2217://localhost:5001

ser2net.yaml

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

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

[zxdavb (David Bonnes)]

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.

[stevieb12345]

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

[zxdavb (David Bonnes)]

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 client.py 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.

[zxdavb (David Bonnes)]

@stevieb12345

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

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

[Cinamon]

@zxdavb i think that a fan entity the right kind of entity is for an itho fan. What are the benefits of a climate entity? What do you need for kind of logging?

[stevieb12345]

I’ve got a nuaire DRI-ECO-LINK-HC PIV with
DRI-ECO-2s switch
DRI-ECO-RH sensor
DRI-ECO-C02 sensor

Would like to be able to use the boost function through automation.

[zxdavb (David Bonnes)]

@Cinamon

@zxdavb i think that a fan entity the right kind of entity is for an itho fan. What are the benefits of a climate entity?

TBH, I think an Itho ventilation system is more Climate than Fan - have a look at these two links:

Would you expect it to be implemented as a Fan, or Climate entity, or both?

For example, Climate includes humidity, and temperature, whereas a Fan does not.

However, a Climate entity doesn’t really have fan speed like the Fan entity does.

@Cinamon

What do you need for kind of logging?

For now, just a packet log where the Itho devices are not filtered out. It will help if you use the switch a few times.

@stevieb12345 See the above for you - the log you sent me has the PIV in it, but neither sensor, nor the switch.

[Mahmoud-Eid]

what am I missing
the controls get greyed out
this is the log message

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:306
First occurred: October 9, 2021, 10:55:49 PM (463 occurrences)
Last logged: 1:20:50 PM

I --- 01:062035 --:------ 01:062035 0009 003 FC00FF # has expired (187%)
I --- 04:024680 --:------ 01:062035 2309 003 000320 # has expired (127%)
I --- 04:258712 --:------ 01:062035 2309 003 057EFF # has expired (135%)
I --- 01:062035 --:------ 01:062035 0009 003 FC00FF # has expired (196%)
RP --- 10:032432 01:062035 --:------ 3220 005 0040130000 # has expired (167%)

I have PMed you the packet.log
It gets fixed with a restart but comes back again

Many Thanks

[zxdavb (David Bonnes)]

@Mahmoud-Eid

this is the log message

Generally, you can ignore these expired messages. Do you have any other errors elsewhere?

[zxdavb (David Bonnes)]

@Mahmoud-Eid Please use:

evohome_cc:
  enforce_known_list: true

I cannot recommend strongly enough for people to do this.

See: 4. Config (reliability) · zxdavb/evohome_cc Wiki (github.com)