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

[cvenn (Conrad Venn)]

@zxdavb

it isn’t a HCE80 without an antenna?

No, it is an HCE80 with an internal antenna.

@zxdavb

the UFC was bound to the CTL at some stage: i.e. it can’t be ‘deaf’

Quite so.

I am wondering whether my configuration may be affecting its behaviour. I am using an undocumented feature to bind two circuits to a single zone. Maybe I’ll try a hard reset on the HCC and reconfigure as separate zones to see if anything changes.

The only 10E0 packets I have seen are when I was first setting up ramses_cc and I got some from a device type 31 to device type 63, e.g.

I --- 31:199125 63:262142 --:------ 10E0 038 000002FF1F02FFFFFFFFFFFFFFFF040807E04A61737065722053746174205458585800000000

but I presumed these were from a neighbour’s house as I didn’t recognise the types. Maybe this was wrong?

[zxdavb (David Bonnes)]

@cvenn

it is an HCE80 with an internal antenna

isn’t that HCC80?

@cvenn

I am using an undocumented feature to bind two circuits to a single zone

If that is what I have seen before - it shouldn’t cause issues.

@cvenn

Maybe I’ll try a hard reset on the HCC and reconfigure as separate zones to see if anything changes.

If you’re going to do that - have HA running, so we can see the packet log - it can be instructive.

In fact, I am not sure that I have a log of such, so may be very useful…

[cvenn (Conrad Venn)]

@zxdavb

isn’t that HCC80?

Yes, what I meant was, our HCC80R is effectively an HCE80R with an internal antenna instead of an external one.

[cvenn (Conrad Venn)]

@zxdavb

If you’re going to do that - have HA running, so we can see the packet log - it can be instructive.

In fact, I am not sure that I have a log of such, so may be very useful…

OK, I’ll do that when I get a chance.

Should I disable enforce_known_list and/or enable_eavesdrop when doing it ?

[zxdavb (David Bonnes)]

I would have:

ramses_cc:
  ramses_rf:
    disable_sending: true

Once you’re done, just have (for now):

ramses_cc:
  ramses_rf:
    enforce_known_list: true

Obviously, you have to reboot HA after changing the configuration.

[cvenn (Conrad Venn)]

I did all that but I’m not seeing any difference.
I am thinking that I may have a faulty HCC80R.

Sending packet log by PM.

[dcorfan (David)]

Hi - I’ve reinstalled several times, but I’m still getting this error and I’ve no idea why. I’m happy to believe that I’m doing something wrong, but can’t see what it might be, although as I’m not a HA expert it’s probably something very simple and obvious.
HA version is 2023.3.1, HA OS is 9.5 Ramses_CC 0.21.40

Do I also need to install the ramses_RF library separately? The instructions on the Ramses_CC GitHub page don’t say so but if I click on the Ramses_CC page in HACS it takes me to a page that implies that I have to do that? Do I do that from the HA OS prompt?

Thanks in anticipation

Logger: homeassistant.setup
Source: setup.py:344
First occurred: 17:30:36 (4 occurrences)
Last logged: 17:30:54

Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name ‘TEMP_CELSIUS’ from ‘homeassistant.components.sensor’ (/usr/src/homeassistant/homeassistant/components/sensor/init.py)).
Unable to prepare setup for platform ramses_cc.climate: Platform not found (cannot import name ‘TEMP_CELSIUS’ from ‘homeassistant.components.climate’ (/usr/src/homeassistant/homeassistant/components/climate/init.py)).

[zxdavb (David Bonnes)]

@dcorfan

HA version is 2023.3.1, HA OS is 9.5 Ramses_CC 0.21.40

You have a corrupt installation of ramses_cc: version 0.21.40 of ramses_cc does not include the code:

from ... import TEMP_CELSIUS

… and it hasn’t done so since later versions of 0.20.22, see commit 8f99381d6d.

@dcorfan

Do I also need to install the ramses_RF library separately?

No. You install ramses_cc via HACS, and that should pull down ramses_rf from PyPi when it is next started.

First:

• If you installed via HACS, try upgrading to 0.22.40 - that may override the corrupted custom component.
• If not, completely remove the custom component, and the library manually and then install via HACS.

Please be more specific, so that people can help. For example:

• did you follow these specific instructions?

@dcorfan

if I click on the Ramses_CC page in HACS it takes me to a page that implies that I have to do that? Do I do that from the HA OS prompt?

Please include a screenshot of this.

There should be no CLI used to install ramses_cc - if you needed to do so, you did something wrong. For example, you may have the wrong files in the right place, and they can’t be replaced with the correct version because the file permission are wrong.

[zxdavb (David Bonnes)]

All,

I would be grateful if someone could confirm that they have very recently followed the latest version of the installation instructions and that it was OK for them?

Or perhaps someone has the capacity to do a quick check now?

[dcorfan (David)]

Thank you for your detailed response and patience. I’m sorry to say that I’ve done all that and it’s not changed - still got the error as soon as I reboot after adding Ramses_cc into Configuration.yaml.

I removed Ramses_cc from HACS and also removed it and Evohome from configuration.yaml. I’ve checked and it’s definitely gone from custom_components.

Where would I find the library to manually remove it?

I’ve gone back into HACS, installed again. When I find it in HACS and select it, there’s a part in the description that talks about Ramses_RF which if followed gives installation instructions, hence that question.

In this page, clicking evohome_rf takes me to GitHub - zxdavb/ramses_rf: An interface for the RAMSES RF protocol, as used by Honeywell-compatible HVAC & CH/DHW systems..

In the instructions is uses the word ‘install’ rather than ‘download’ - is this just from prior HA versions?

I’ve installed 0.22.40 as you suggest but it’s no different. Same error. I’m loath to do so, but perhaps I’ll just completely reinstall HA, or else just give up

Thanks again. Apart from manually searching for and removing a library I’ve followed the instructions many times and it’s just not working for me.

On the plus side, the card is working and I’ve got a log full of interesting things and HA entities for battery low and window open from my TRVs. So near and yet so far…
Thanks again for your help and patience.

[Lloyd (Lloyd Adams)]

It’s been a while since I needed the instructions, but I wonder if the line I’ve bolded below is misleading? Should it not be Ramses CC?

Add ramses_cc as an Integration via HACS

• select HACS (side panel), Integrations
• click the Explore & Add Repositories button
• search for ‘ramses’
• click on Ramses RF (or similar)…
• click on Install this Repository in HACS, then Install
• restart HA (the HA Core)

[Lloyd (Lloyd Adams)]

Have you followed the instructions in the WiKi ? - 1. Installation · zxdavb/ramses_cc Wiki · GitHub

[dcorfan (David)]

I’ve reinstalled HA and am delighted that all is working well. One question I can’t find answered in the wiki is how to match the room name to the device id, so I can group all the sensors by room. I’ve got the schema in the 18: device, a list of TRVs (04:) and a list of room climate temps, but I can’t find a way to join the TRVs to the room. Thank you and apologies if I’ve missed this in the docs.

[zxdavb (David Bonnes)]

@dcorfan Your question doesn’t make sense to me in the way that you have posed it - maybe this is is an XY problem?

For example:

@dcorfan

so I can group all the sensors by room

Each ‘room’ (i.e. zone) can only have one (or none) sensor (which may be one of the TRV sensors).

Each TRV does have a sensor, but if you want to display all of them by room in HA’s web UI, you have to do so manually (if you wanted, you can create sensor templates that are an average of each rooms sensors, but I am truly unsure of the utility of this).

However, knowing the sensor value for each TRV may allow you to change to a different sensor that more accurately reflects the true room temperature (e.g. if you don’t have a DTS92 or similar).

@dcorfan

I’ve got the schema in the 18: device, a list of TRVs (04:) and a list of room climate temps, but I can’t find a way to join the TRVs to the room.

If the schema is correct, then the TRVs are already ‘joined’ (bound) to the ‘room’ (zone).

If I haven’t satisfied your query, perhaps you could post your schema, along with a clearer explanation of what you’re looking for / expecting?

[dcorfan (David)]

Thanks again for the prompt response. I’ve attached a couple of screen shots.

This shows all the TRVs - what I’m trying to understand is which room these are in.

Each zone is listed like this.

I’m trying to work out which of the 04:xxxxx TRVs is located in which room.

Hopefully that makes more sense. Thank you

[zxdavb (David Bonnes)]

@dcorfan

I’ve attached a couple of screen shots.

Please copy/paste the complete text, rather than provide an incomplete screenshot.

You should see a binary sensor called 01:217908 schema - have a look at it’s extra attributes. It should look something like this (edited):

system:
  appliance_control: '10:048122'
  zones:
    '01':
      _name: Main Room
      class: radiator_valve
      sensor: '01:123456'
      actuators:
        - '04:056057'
...

Above, you can see 04:056057 is in zone 1.

[dcorfan (David)]

Got it - thank you. That’s exactly what I was looking for, but I didn’t know where to find it. If that’s already in your documentation I must have missed it. Thanks again for your patience and help and the software and documentation.

[zxdavb (David Bonnes)]

All,

If people are wondering why the ramses_cc integration does not support HA devices (which would be 1-1 with the physical evohome devices), the reason is because HA requires integrations to use config flow (rather than the configuration.yaml file) for that feature.

However, ramses_cc is heavily reliant upon yaml, and I cannot see a way to remove this need.

[trailro]

Hi all,

I have been watching this thread for a long time and using Ramses_cc for a while now and it is such a powerful tool for Evohome. I do seem to have a rather strange behavior and I am wondering if anyone else is having the same issues: from time to time, some of the related entities (in particular heat demand both for individual trv’s and for the equivalent zone of the controller) become unavailable. They update every now and then, doesn’t seem to be a pattern tbh.

I understand that most of these are battery devices and that they communicate so often; but what is strange is that I have over 15 such devices paired and, of these, all but randomly 3-4 work perfectly and update every 5-10 minutes.

What is more surprising is that these 3 devices (all HR92’s and sometimes a thermostat) are situated some very (4m) from the controller and the usb sniffer stick, one is a bit further like 7m. So distance does not seem to be an issue here.

When one of the TRV’s does not report how much it’s open in %, the zone heat demand is unavailable, but the controller (looking at the stats) shows 0% heat demand. So, something might be broken somewhere.

Thanks.

[neeu2]

I had the same issue, and occurances of this dropped down considerably when I moved the Pi and usb device to the same room that my evo controller is (assuimg that room has better reception from all the devices around the home), but I still have one of the BDR91 demand (out of the two) becoming unavailable frequently,