I don’t think anyone would want to be using this feature - it will break a lot of stuff.
The known list is not a whitelist unless you have enforce_known_list: true. Enforcing is strongly recommended, once you have a complete known list.
Neither does it cause devices to be instantiated (created) - it merely tells ramses_rf what to do with the device when it is instantiated for whatever reason (like being in the schema somewhere).
I’m looking for some advice. I’m having a new boiler fitted this week, which will include an OTB. What is the best way to migrate from a system without an OTB to one with?
@Lloyd Your question could be more specific… As it is, I am not sure I can provide a useful answer.
You disconnect the BDR (BDR91A/T), you add the OTB (R8810A/20A), and you bind it to / re-configure the evohome controller - it is remarkably straight-forward.
In your case, you’re replacing the boiler, so just bind the OTB on top of the BDR at the controller.
From the schema’s point of view - you add the OTB as per many examples above this post.
Anything tricky is likely an idiosyncrasy of the boiler.
@zxdavb sorry for not reporting earlier, I did not have the time…
I upgraded to newest master and I finally see 2x available schemas !!
Im using enforce_known_list and all IDs added from status entity (though most of the times randomly status entity is unavailable with no changes to config).
There are still lots of errors in log and few other things (missing actuators for a zone in schema). I will do a comprehensive report on whats working and whats not later today or tommorow.
Apologies, should have been clearer. My questions were around changes to ramses_cc config.
I presume I can get the OTB id from packet.log, but do I have to set enforce_known_list to false for it to appear in the log?
And after adding the OTB as the controller, and adding it to the known_list, do I need to set restore_cache to false, or will it add to the cache?
Every packet seen by ramses_rf, valid or not, ends up in the packet log.
The device id filtering, if any, simply determines which valid packets are processed.
( Due to the poor/absent ECC of the underlying protocol, there are a lot of invalid packets that look valid - a common problem is corrupted device IDs. This is why I strongly recommend the enforcement of the known list: it prevents the system from accumulating a never-ending list of ghost devices. )
So, if there is an OTB which is visible to the gateway, it will end up in the packet log, regardless of the configuration, schema, and device lists.
Thus far, OTBs have a device id that starts 10:.
There is no way for ramses_rf to discover which OTB is yours so, if it is to be in the schema, then it needs to be hard coded in your configuration.yaml.
Yes.
No.
No. To be clear what you’re asking is: will it add it to the cached schema (as opposed to the cached packets).
During start-up the system will merge the configured schema into the cached schema and use the result. If it’s not happy with the merged schema, will automatically discard the cached schema and start with a new schema (that it will evolve into a the working (cached) schema over time via discovery, etc).
You will see this in the HA log.
It should.
@zxdavb Running master now (commit 1444634), my faked remote is unavailable, which means I can’t send any commands:
Logger: homeassistant.helpers.service
Source: helpers/service.py:635
First occurred: 1 oktober 2022 21:09:52 (4 occurrences)
Last logged: 15:46:14
Unable to find referenced entities remote.37_123456 or it is/they are currently not available
Same with 0.21.5.
Edit: after adding it to orphans_hvac it’s back, and I can do service calls again.
I have spent some time tweaking the wiki.
Please have a read of it before asking for help - the answer may be in there!
Note: faked remotes need to be in orphans_hvac, but faked CH/DHW sensors need to be in their controller’s system schema.
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
ramses_rf:
# disable_discovery: true
# disable_sending: true
# enable_eavesdrop: true
enforce_known_list: true
scan_interval: 60
restore_cache: false
01:xxxxxx:
zones:
"00": {sensor: 01:xxxxxx}
01:yyyyyy:
zones:
"01": {sensor: 01:yyyyyy}
known_list:
01:xxxxxx: # CONTROLLER Jedilnica
01:yyyyyy: # CONTROLLER Ucilnica
18:dddddd: # USB NanoCUL
13:zzzzzz: # BDR91
# 00 HR92 Jedilnica (Jedilnica
04:kkkkkk: # 01 HR92 Kuhinja (Jedilnica)
34:kkkkkk: # 01 T87RF Kuhinja (Jedilnica)
04:kkkkkk: # 02 HR92 Sp Kopalnica (Jedilnica)
04:kkkkkk: # 03 HR92 Likalnica (Jedilnica)
04:kkkkkk: # 04 HR92 Plava (Jedilnica)
34:kkkkkk: # 04 T87RF Plava (Jedilnica)
04:kkkkkk: # 05 HR92 Zg Kopalnica (Jedilnica)
04:kkkkkk: # 06 HR92 Miha Ucilnica (Jedilnica)
34:kkkkkk: # 06 T87RF Miha Ucilnica (Jedilnica)
04:kkkkkk: # 07 HR92 Veranda (Jedilnica)
04:kkkk74: # 08 HR92 Pralnica (Jedilnica)
04:kkkk94: # 08 HR92 Pralnica (Jedilnica)
# 09 HR92 Veza (Jedilnica)
04:kkkkkk: # 0A/10 HR92 Luka Pisarna (Jedilnica)
04:kkkkkk: # 0B/11 HR92 Dnevna (Jedilnica)
04:kkkkkk: # 00 HR92 Mama Spalnica (Ucilnica)
34:kkkkkk: # 00 T87RF Mama Spalnica (Ucilnica)
04:kkkkkk: # 01 HR92 Ucilnica_1 (Ucilnica)
04:kkkkkk: # 01 HR92 Ucilnica_2 (Ucilnica)
04:kkkkkk: # 02 HR92 Pisarna (Ucilnica)
04:kkkk14: # 03 HR92 Kopalnica (Ucilnica)
04:kkkk22: # 03 HR92 Kopalnica (Ucilnica)
# 04 HR92 Kuhinja (Ucilnica)
04:kkkkkk: # 05 HR92 Vhod (Ucilnica)
04:kkkkkk: # 06 HR92 Miha Spalnica (Ucilnica)
04:kkkkkk: # 07 HR92 Luka Spalnica (Ucilnica)
04:kkkkkk: # 08 HR92 Miha Predsoba (Ucilnica)
04:kkkkkk: # 09 HR92 Miha WC (Ucilnica)
Schema
system:
appliance_control: '13:zzzzzz'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Jedilnica
class: radiator_valve
sensor: '01:xxxxxx'
actuators: [] <--- missing
'01':
_name: Kuhinja
class: radiator_valve
sensor: '34:kkkkkk'
actuators:
- '04:kkkkkk'
'02':
_name: Sp Kopalnica
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'03':
_name: Likalnica
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'04':
_name: Plava
class: radiator_valve
sensor: '34:kkkkkk'
actuators:
- '04:kkkkkk'
'05':
_name: Zg Kopalnica
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'06':
_name: Miha Ucilnica
class: radiator_valve
sensor: '34:kkkkkk'
actuators:
- '04:kkkkkk'
'07':
_name: Veranda
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'08':
_name: Pralnica
class: radiator_valve
sensor: '04:kkkk74'
actuators:
- '04:kkkk74' <--- one is fake/missing
- '04:kkkk94' <--- one is fake/missing, probably this one because it isnt in sensor
'09':
_name: Veza
class: radiator_valve
sensor: null <--- missing
actuators: [] <--- missing
0A:
_name: Luka Pisarna
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
0B:
_name: Dnevna
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
Schema
system:
appliance_control: null <--- missing BDR (check under 5. Errors)
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Mama Spalnica
class: radiator_valve
sensor: '34:kkkkkk'
actuators:
- '04:kkkkkk'
'01':
_name: Ucilnica
class: radiator_valve
sensor: '01:yyyyyy'
actuators:
- '04:kkkkkk'
- '04:kkkkkk'
'02':
_name: Pisarna
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'03':
_name: Kopalnica
class: radiator_valve
sensor: '04:kkkk22'
actuators:
- '04:kkkk14' <--- one is fake/missing, probably this one because it isnt in sensor
- '04:kkkk22' <--- one is fake/missing
'04':
_name: Kuhinja
class: radiator_valve
sensor: null <--- missing
actuators: [] <--- missing
'05':
_name: Vhod
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'06':
_name: Miha Spalnica
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'07':
_name: Luka Spalnica
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'08':
_name: Miha Predsoba
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
'09':
_name: Miha WC
class: radiator_valve
sensor: '04:kkkkkk'
actuators:
- '04:kkkkkk'
Schema <--- missing yyyyyy controller (Ucilnica)
'01:xxxxxx':
zones:
'00':
sensor: '01:xxxxxx'
Config
enforce_known_list: true
Known list
- '01:xxxxxx':
class: controller
- '01:yyyyyy': <--- here it is listed, maybe not needed above?
class: controller
- '18:dddddd':
class: gateway_interface
- '13:zzzzzz':
class: electrical_relay
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '34:kkkkkk':
class: thermostat
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '34:kkkkkk':
class: thermostat
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '34:kkkkkk':
class: thermostat
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '34:kkkkkk':
class: thermostat
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
- '04:kkkkkk':
class: radiator_valve
Block list
Other list
is evofw3
true
4.1. yyyyyy Controller (Ucilnica) has missing appliance_control: in schema
4.2. zone 04 in yyyyyy has missing sensor: + actuators: + unavailable heat_demand (it has only 1x HR92 for both sensor+actuator)
4.3. zone 02 in yyyyyy has unavailable heat_demand entity (forget this one for now, because I removed HR92 and its battery, maybe thats why.)
4.4. zone 03 in yyyyyy has two actuators: and both are unique IDs (it should have only 1x HR92 for both sensor+actuator)
4.5. zone 00 in xxxxxx has missing actuator: + unavaiable heat_demand, when in reality this is the main room of the house and its HR92 is working flawlessly (Controller is sensor)
4.6. zone 09 in xxxxxx has missing sensor: + actuators: + unavailable heat_demand (it has only 1x HR92 for both sensor+actuator)
4.7. zone 08 in xxxxxx has two actuators: and both are unique IDs (it should have only 1x HR92 for both sensor+actuator)
This is logical: So I believe, whenever it is missing an actuator in schema, heat_demand is missing.
2 years ago, actuator in zone 09 in xxxxxx was double binded to 07 (something very weird). I fixed it then by unbinding both zones on both sides, removing zones, recreating zones and binding both HR92 again.
Maybe this procedure of unbinding HR92 and recreating zones would fix all missing stuff in schema?
2022-10-02 05:46:50.083 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 01:yyyyyy 18:dddddd --:------ 000C 006 000F0037D388 < CorruptStateError(Inconsistent schema: 13:zzzzzz (BDR): None cant change parent (01:xxxxxx (evohome)_FC to 01:yyyyyy (evohome)_FC)(try restarting the client library))
^^ I believe this one is a bug: need to allow duplication of BDR91 between two controllers
2022-10-02 05:48:24.436 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 01:xxxxxx 18:dddddd --:------ 000C 006 09080010BF62 < CorruptStateError(Inconsistent schema: ***04:kkkk94*** (TRV): 0.0 cant change parent (01:xxxxxx_08 (RAD)_08 to 01:xxxxxx_09 (RAD)_09)(try restarting the client library))
2022-10-02 05:48:24.844 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 01:xxxxxx 18:dddddd --:------ 000C 006 09040010BF62 < CorruptStateError(Inconsistent schema: ***04:kkkk94*** (TRV): 0.0 cant change parent (01:xxxxxx_08 (RAD)_08 to 01:xxxxxx_09 (RAD)_09)(try restarting the client library))
^^ maybe 4.7. - 04:kkkk94 is the 2nd in actuators, which is not in sensor
2022-10-02 05:48:26.658 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 01:yyyyyy 18:dddddd --:------ 000C 012 04080011BBD604080011BBCE < CorruptStateError(Inconsistent schema: ***04:kkkk22*** (TRV): None cant change parent (01:yyyyyy_03 (RAD)_03 to 01:yyyyyy_04 (RAD)_04)(try restarting the client library))
^^ maybe 4.4. - 04:kkkk22 is the 2nd in actuators, which it is in sensor
2022-10-02 05:48:27.089 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 01:yyyyyy 18:dddddd --:------ 000C 006 04040011BBCE < CorruptStateError(Inconsistent schema: ***04:kkkk14*** (TRV): None cant change parent (01:yyyyyy_03 (RAD)_03 to 01:yyyyyy_04 (RAD)_04)(try restarting the client library))
^^ maybe 4.4. - 04:kkkk14 is the 1st in actuators, which is not in sensor
2022-10-02 05:50:17.962 WARNING (MainThread) [ramses_rf.entity_base] No response for task(0008|RP|13:zzzzzz): throttling to 1/24h
2022-10-02 05:50:23.209 WARNING (MainThread) [ramses_rf.entity_base] No response for task(1100|RP|13:zzzzzz): throttling to 1/24h
2022-10-02 05:50:36.117 WARNING (MainThread) [ramses_rf.entity_base] No response for task(3EF1|RP|13:zzzzzz): throttling to 1/24h
^^ Ignore this, BDR91 is off power atm, probably thats why.
2022-10-02 06:58:57.343 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.012, avg: 0.012, lower: 0.012, upper: 0.012, times: ['0.012']```
2022-10-02 09:18:52.039 WARNING (MainThread) [ramses_rf.protocol.message] RQ --- 18:dddddd 01:xxxxxx --:------ 2349 002 0040 < Corrupt payload: Payload doesn't match '^0[0-9A-F](00|[0-9A-F]{12})?$': 0040
2022-10-02 10:18:54.170 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.065, avg: 0.038, lower: 0.012, upper: 0.065, times: ['0.012', '0.065']
2022-10-02 16:54:03.186 WARNING (MainThread) [ramses_rf.protocol.message] RQ --- 18:dddddd 01:xxxxxx --:------ 2349 002 00B0 < Corrupt payload: Payload doesn't match '^0[0-9A-F](00|[0-9A-F]{12})?$': 00B0
2022-10-02 17:34:27.030 WARNING (MainThread) [ramses_rf.protocol.message] RQ --- 18:dddddd 01:xxxxxx --:------ 2349 002 4000 < Corrupt payload: Payload doesn't match '^0[0-9A-F](00|[0-9A-F]{12})?$': 4000
2022-10-02 17:34:27.042 WARNING (MainThread) [ramses_rf.protocol.message] RP --- 01:xxxxxx 18:dddddd --:------ 2349 007 407FFF02FFFFFF < Corrupt payload: Payload doesn't match '^0[0-9A-F]{5}0[0-4][0-9A-F]{6}([0-9A-F]{12})?$': 407FFF02FFFFFF
2022-10-02 18:48:04.220 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.088, avg: 0.055, lower: 0.012, upper: 0.088, times: ['0.012', '0.065', '0.088']
2022-10-02 20:09:42.833 WARNING (MainThread) [ramses_rf.protocol.message] RQ --- 18:dddddd 01:yyyyyy --:------ 2394 002 0200 < Corrupt packet: Unknown code: 2394
2022-10-02 23:34:42.354 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.045, avg: 0.052, lower: 0.012, upper: 0.088, times: ['0.012', '0.065', '0.088', '0.045']
2022-10-02 23:59:36.948 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.011, avg: 0.044, lower: 0.011, upper: 0.088, times: ['0.012', '0.065', '0.088', '0.045', '0.011']
2022-10-03 00:48:37.354 WARNING (MainThread) [ramses_rf.protocol.message] RQ --- 18:dddddd 01:yyyyyy --:------ 2E40 001 FF < Corrupt packet: Unknown code: 2E40
2022-10-03 01:53:32.352 WARNING (MainThread) [ramses_rf.protocol.transport] *** sync cycle stats: 0.087, avg: 0.051, lower: 0.011, upper: 0.088, times: ['0.012', '0.065', '0.088', '0.045', '0.011', '0.087']
EDIT:
While rereading everything, under 4.5…
I have “Jedilnica heat_demand” unavailable, but “01:xxxxxx heat_demand” is available (controller is sensor). Is that the same?
While “Ucilnica heat_demand” and “01:yyyyyy heat_demand” are both available (controller is sensor) 
So…
sensor.04_kkkkkk_heat_demand (available)
sensor.04_kkkkkk_heat_demand (available)
sensor.01_yyyyyy_01_heat_demand (available)
sensor.01_yyyyyy_heat_demand (available)
sensor.04_kkkkkk_heat_demand (skip this, missing also in schema)
sensor.01_xxxxxx_00_heat_demand (unavailable)
sensor.01_xxxxxx_heat_demand (available)
I believe its unavailable because also actuator is missing?
Thanks for your detailed post.
It appears that your issues are a combination of:
To best progress this, I will need a packet log, which includes starting up HA (and at least 24h after that) with:
ramses_cc:
restore_cache:
restore_schema: false
restore_state: true
Please do not PM me a packet log with obscured device ids - it will not be useful to me.
Please don’t start re-binding, etc. yet, before I pass judgment:
a) Your heating systems is functioning well, but
b) evhome_cc is throwing errors
Don’t break a) trying to fix b).
For example, it is OK for a BDR to be shared by two controllers, but (AFAIK) not OK for this to be the case for TRVs. Yes, I believe ramses_rf doesn’t handle this scenario (shared BDR) when it should do so.
To ‘fake’ a device, means a very specific thing for ramses_cc / ramses_rf - please don’t use that term unless the device is truly faked (currently, TRVs cannot be faked).
It appears you shoudl really be doing a stock take - for example, you can press a button on a TRV and see it appear immediately in the HA log if you:
logger:
logs:
ramses_rf.processor: info
Doing so will help you confirm that that a device is physically located in the same zone as it’s configured location.
No, they are not the same. Heat demand is by:
Other heat demands are usually copies of the above, or (0 → 0.0, >0 → 1.0).
sensor.01_xxxxxx_00_heat_demand is the HD of zone 00 of controller 01_xxxxxx.
Correct.
Has anyone found a nice way to display the zone schedule data that was recently made available? I’ve tried using the List Card however I can’t get it to work with the ramses_cc list format. I could just dump the data into a Entity or Markdown card but I was looking for a more elegant solution in a pretty table 
I must admit that I’m struggling to get my head around the best way to decode and display the schedule. I wondered if you would have more success with flex_table_card?
Good luck!
I already tried that without success. I think the difficulty is the schedule attribute output is a “list within a list” so there isn’t a standard way to create the table, i.e. time_of_day is listed within day_of_week list.
Yes. I can pull the individual elements out in dev tools, but can’t see a sensible way to do this easily within a lovelace card
Nice. Look forward to seeing the code.
Our heating is still off, but soon we will need it and if this will work I will scream like a child.
I think the first thing to do is to check / check your system configuration - there is some evidence that your system is mis-configured.
In this sense, the schema is only there to calculate zone heat demands - but it’s no use having a ‘correct’ schema, if the system configuration is otherwise.
FWIW, my instinct is - as going ‘off-grid’ with ramses_cc mostly involves talking to the controller (rather than the boiler relay) - that you will have most functionality as-is.
In short - I expect that if your system is configured correctly, you can basically ignore any errors.
… although I would always be planning to remove such problems.
Is there any specific functionality that you need/want?
