There is a fix coming, where you should no longer need to add your TRVs to the schema.
Neighbour? Use a device ID filter, preferably a white list.
Ive just downgraded from 17.2 to 17.1. HA kept on complaining about there was something wrong with the evohome_cc configuration yaml file. Kept on excluding but could not fix it until the downgrade after that the problem was gone⌠Indeed the known_list AND the enforce_known_list.
Running 17.1 now but man I am struggeling to understand this indention of these YAML files. Below does not seem to be accepted by HA⌠Just want to try one thing I see now to remove the - in front of below device identifiersâŚ
schema:
controller: 01:059885
system:
heating_control: 10:030670
zones:
00:
devices:
- 04:126354
- 04:126368
- 04:126378
- 34:177047
01:
devices:
- 03:075455
- 04:126322
02:
devices:
- 34:176627
- 04:126376
03:
devices:
- 04:126366
04:
devices:
- 34:155573
- 04:126382
05:
devices:
- 34:162993
- 04:126374
Was working with 17.1
schema:
controller: 01:059885
system:
heating_control: 10:030670
Upgraded to 17.2 and HA warned there was a problem with above config
2022-01-02 20:31:30 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 229, in _async_setup_component
result = await task
File "/config/custom_components/evohome_cc/__init__.py", line 105, in async_setup
register_service_functions(hass, broker)
File "/config/custom_components/evohome_cc/__init__.py", line 190, in register_service_functions
if not broker.config[ADVANCED_FEATURES].get(SVC_SEND_PACKET):
KeyError: 'advanced_features'
2022-01-02 20:31:30 INFO (MainThread) [ramses_rf.message] || HGI:010642 | NUL:262142 | I | puzzle_packet | || {'datetime': '2022-01-02T20:31:30.429', 'engine': 'v0.17.1', 'parser': 'v0.17.1'}
2022-01-02 20:31:30 DEBUG (MainThread) [ramses_rf.devices] Creating a Device: 18:010642 (<class 'ramses_rf.devices.HgiGateway'>)
2022-01-02 20:31:30 INFO (MainThread) [ramses_rf.message] || HGI:010642 | NUL:262142 | I | puzzle_packet | || {'datetime': '2022-01-02T20:31:30.429', 'engine': 'v0.17.1', 'parser': 'v0.17.1'}
2022-01-02 20:31:31 INFO (MainThread) [custom_components.hacs] Loaded 11 tasks
Will check again tomorrowâŚ
Yes - the issue is that evohome_cc isnât loading the right version of ramses_rf.
Fix shortly.
Try 0.17.3 (a beta) with this (no zones):
schema:
controller: 01:059885
system:
heating_control: 10:030670
re: 0.17.4:
@stevieb12345 The zone demands should be correct now: they should match that displayed on the controller UI - let me know if that isnât the case.
@MDIGIT1971 You should not need a zones: section any more: the actuators should be discovered automatically - let me know if that isnât the case.
@BuSab You should not need to specify the heating relay in the schema: it should be discovered automatically - let me know if that is not the case (NB: this feature will not work for OpenTherm relays, only BDR91s).
Just installed 7.3⌠I see errors ⌠Want to be sure so i will check and upgrade to the 7.4 I just saw⌠
Oh I am runing latest and greatest release 2021.12.7 .
2022-01-03 10:47:20 DEBUG (MainThread) [ramses_rf.devices] Creating a Device: 10:030670 (<class 'ramses_rf.devices.OtbGateway'>)
2022-01-03 10:47:20 DEBUG (MainThread) [ramses_rf.devices] 10:030670 (OTB): controller now set to 01:059885 (CTL)
2022-01-03 10:47:20 DEBUG (MainThread) [ramses_rf.devices] Device 10:030670 (OTB): parent now set to 01:059885 (evohome)
2022-01-03 10:47:20 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 229, in _async_setup_component
result = await task
File "/config/custom_components/evohome_cc/__init__.py", line 105, in async_setup
register_service_functions(hass, broker)
File "/config/custom_components/evohome_cc/__init__.py", line 190, in register_service_functions
if not broker.config[ADVANCED_FEATURES].get(SVC_SEND_PACKET):
KeyError: 'advanced_features'
2022-01-03 10:47:20 INFO (MainThread) [ramses_rf.message] || HGI:010642 | NUL:262142 | I | puzzle_packet | || {'datetime': '2022-01-03T10:47:20.485', 'engine': 'v0.17.3', 'parser': 'v0.17.3'}
2022-01-03 10:47:20 DEBUG (MainThread) [ramses_rf.devices] Creating a Device: 18:010642 (<class 'ramses_rf.devices.HgiGateway'>)
2022-01-03 10:47:20 INFO (MainThread) [ramses_rf.message] || CTL:059885 | HGI:010642 | RP | device_info | || {'unknown_0': '0002FF0119FFFFFFFF', 'date_2': '2014-11-27', 'date_1': '2014-01-16', 'description': 'EvoTouch Colour', '_unknown_1': '00000000'}
2022-01-03 10:47:20 INFO (MainThread) [custom_components.hacs]
Can you see the release notes in HACS?
0.17.4 - Bugfix only
- evohome_cc:
e1f8f17 bugfix advanced_features
Looking promissing! I will let it run for a while⌠No schema defined, the OT bridge for heating demand is defined in the configuration. First thing I notice that the proces (without restoring the previous state!) is pretty quick. Within 5 minutes someting is happening.
Had a funny situation after removing the custom integration (to remove the old entities) after I had reinstalled it it would not let me restart the core 
integration not found. But when I restarted my VM (I am in charge) I was suprised to see that the integration was renamed in RAMSES RF (again?) instead of evohome_cc. Will guardâŚ
{
"version": 1,
"minor_version": 1,
"key": "evohome_cc",
"data": {
"client_state": {
"schema": {
"main_controller": "01:059885",
"01:059885": {
"system": {
"heating_control": "10:030670"
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {
"00": {
"_name": "Woonkamer",
"zone_type": "radiator_valve",
"zone_sensor": "34:177047",
"sensor_alt": "34:177047",
"devices": [
"04:126378",
"04:126354",
"34:177047"
],
"actuators": [
"04:126378",
"04:126354"
]
It hasnât made any difference for me.
This is my configuration.
evohome_cc:
serial_port: /dev/ttyACM2
packet_log: /config/packet_logs
restore_state: true
advanced_features:
send_packet: false
message_events: true
ramses_rf:
disable_sending: false
enforce_known_list: true
# enable_eavesdrop: true
schema:
controller: 01:169176
system:
heating_control: 10:051349
known_list:
# - 10:051349
- 01:169176
- 18:135447 # Config Sensor
- 04:190691 # Harry's Room
- 04:198483 # Bedroom
- 04:198487 # Spare Room
- 04:112546 # Living Room 1
- 04:198485 # Living Room 2
- 04:038015 # Utility Room
- 04:090189 # Kitchen
# - 32:166025 # Co2 Sensor
# - 30:079129 #?
# - 32:168240 #?
- 03:000001 # kitchen
- 03:000002 # Living Room 1
- 03:000003 # Living Room 2
- 03:000004 # Harry's Room
- 03:000005 # Master Bedroom
- 03:000006 # Utility Room
- 03:000007 # Spare Room
Just send you via message a link to the first data I recorder with beta 7.4
- The python message I had before are completely gone.
- It recognizes all the devices, but fails to add one actuator to the âWoonkamerâ group
- With the manual configured the OpenTherm R8810A it recognizes all the rest
- Had this funny thing with the integration name that seems to be changed but the link in my configuration.yaml file seems to work. So how this works is a bit of a mystery to me. Could have to do with my still growing knowledge of the HA system.
- See below messages appear regarding the OpenTherm bridge
Line 287: 2022-01-03 11:17:54 WARNING (MainThread) [ramses_rf.devices] RP --- 10:030670 30:051821 --:------ 3220 005 00C01A47AB < OpenTherm: deprecating msg_id 0x1A: it appears unsupported
Line 303: 2022-01-03 11:18:11 WARNING (MainThread) [ramses_rf.devices] RP --- 10:030670 18:010642 --:------ 3220 005 00401247AB < OpenTherm: deprecating msg_id 0x12: it appears unsupported
Line 305: 2022-01-03 11:18:11 WARNING (MainThread) [ramses_rf.devices] RP --- 10:030670 18:010642 --:------ 3220 005 00C01347AB < OpenTherm: deprecating msg_id 0x13: it appears unsupported
Line 308: 2022-01-03 11:18:11 WARNING (MainThread) [ramses_rf.devices] RP --- 10:030670 18:010642 --:------ 3220 005 00401B47AB < OpenTherm: deprecating msg_id 0x1B: it appears unsupported
- In 2 hours running time I see only two messages regarding the payload (picked it up futher back in this forum) I consider this that single bad package or so (but can be wrong)
- See some expired messages coming trough (did not yet investigate these messages) but my first impression is that it is not influencing the system
- I see a few items it declares as Unavailable from the OpenTherm bridge which apparantly are not in the data. But think this has to do with my setup of data that is -or is not- available.
My opinion is this definately is an improvement!
Here is what the controller is saying about the âWoonkamerâ zone:
11:17:04.841 || CTL:059885 | HGI:010642 | RP | zone_devices | 0008 || {'zone_idx': '00', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:126378', '04:126354']}
11:17:06.998 || CTL:059885 | HGI:010642 | RP | zone_devices | 0000 || {'zone_idx': '00', '_device_class': '00', 'device_class': 'zone_actuators', 'devices': ['04:126378', '04:126354']}
Your missing device appears to be 04:126368 - it certainly beleives itself to be in zone 00!
Rebind the TRV that is missing to the Woonkamer zone & let me know if that doesnât fix the problem
RAMSES RF is the friendly name for evohome_cc.
The above is simply telling you that your OTB is not providing a sensible response to the requests for this data, despite saying that the responses are âvalidâ (e.g. a CV pressure of 71.6 bar, which should be 1.5-2.5 bar, or so).
Here are 3 examples from your RFG100 talking to your OTB:
12:50:27.719 || OTB:030670 | RFG:051821 | RP | opentherm_msg | 12 || {'msg_id': 18, 'msg_type': 'Read-Ack', 'msg_name': 'CHWaterPressure', 'value': 71.6, 'description': 'Central heating water pressure (bar)'}
12:50:27.924 || OTB:030670 | RFG:051821 | RP | opentherm_msg | 13 || {'msg_id': 19, 'msg_type': 'Read-Ack', 'msg_name': 'DHWFlowRate', 'value': 71.66, 'description': 'DHW flow rate (litres/minute)'}
12:50:28.318 || OTB:030670 | RFG:051821 | RP | opentherm_msg | 1A || {'msg_id': 26, 'msg_type': 'Read-Ack', 'msg_name': 'DHWTemperature', 'value': 71.66, 'description': 'DHW temperature'}
The more of these you have, the more unreliable your RF comms are.
The system is showing you all available sensors - some will not have valid values.
I presume weâre talking about zone heat demands?
On my production system, I am now getting the correct values for these - I wasnât before.
Can you confirm youâre using 0.17.44 - search for âramses_rfâ in your packet log - the version number will be there.
Yeah, the zone hating demands.
I found this in the packet logs, which I assume is the wrong one. I downloaded version 0.17.4 from HACS and restarted, so not sure why it is showing that.
2022-01-03T13:46:58.930709 # ramses_rf 0.17.3
Sorry, I was a little lazy - evohome_cc 0.17.4 is using ramses_rf 0.17.3, so that is OK.
Thanks for the checkup⌠Learn something every day this way!
- The rebinding I think I will do with some reset actions on forehand. It looks like the problem holder seems to be the controller. Will check definately (hmm⌠to bad Ive got no TRV on spareâŚ) Will be somewhere later this week i guessâŚ
- Looks like my comms arenât to bad.
- The Unavailable sensors, could this be because the OpenTherm bridge does not receiver those values from the boiler⌠Looking in the examples indeed those values seem a little bit odd to be the same. Sounds indeed that these values are not reported by the Remeha boiler.
- Regarding the Ramses RF and evohome_cc naming. I suspect that since in my configuration.yaml file the evohome_cc is called this triggers the configuration invalid? If I reboot the VM by hand it does not report any errors and all is fine. But via the config check â reboot option it does not want to reboot. Must I rename evohome_cc in ramses_rf below?
evohome_cc: !include evohomevh.yaml
I wouldnât do any reset - just add the TRV in the usual way. If you donât know which of the three it is, just re-add all three - this will be fine.
One of two things:
- The boiler tells the OTB that the particular piece of data is not available
- The boiler says the data is available, but provides invalid data (like a CV pressure of 71.6 bar)
The example I gave you was #2, but there are plenty of #1.
No. Itâs name (identifier) is evohome_cc, itâs friendly name (alias) is âRAMSES RFâ
I have updated to 0.17.4 and heating_control does get populated with my BDR91 relay by discovery. Some of my TRVs took some time to show temperature data but they all seem to be OK now; Iâll report back if there are problems (never had issues with my TRV data before.)
I have some new sensors which Iâve never seen before, e.g. binary_sensor.13_076092_bit_3_7 and binary_sensor.13_076092_bit_6_6, which are unavailable. I guess these result from heating_control but are not applicable to all configurations?
Regarding the new accurate heat demand reporting, thatâs a nice feature. I was not aware that this mapping is deterministic without access to the âlearnedâ zone data. Does this mean that the âlearningâ algorithms are all done locally inside the HR91/HR92, and affect the demand vs pin position function, rather than in the controller affecting the pin position vs heat demand function?