You define each TRV, HGI80 and OTB in the know list.
You can find the info in the sensor schema
ok so where do i find the sensor schema?
you have to talk to me like i have absolutely no idea because i dont
everything just popped up in domoticz and just worked
Go to: /developer-tools/state and filter on “schema”. You would find something like binary_sensor.01_223036_schema, in the attribute list you can find the stuff to add to you known list.
The issue is that the RF comms are relatively unreliable with very poor error detection / correction.
Thus, corrupted but valid packets are common, and many of these have ‘ghost’ device IDs.
Using a known_list (we once used the phrase ‘whitelist’) allows ramses_rf to discard these corrupted packets (and provide for other benefits, such as faking).
I can’t recall how Domoticz did it, but if they’re not using the same technology, either they’re missing out on features (such as auto discovery), or ghost devices are popping up.
I can see that 2. configuration.yaml · zxdavb/ramses_cc Wiki (github.com) needs a bit of tweaking - could someone have a go at it?
Actually, the above is not optimal: instead go to the **18:xxxxxx status binary sensor - the known_list is in there.
NOTE: I am shortly to investigate reports where the above sensor does not appears unless you first list the gateway in teh known list, along with its type:
ramses_cc:
known_list:
18:xxxxxx: class: HGI # or: gateway_interface
No.
WHen I do this:
cat .secrets-0.14.x/themystery/2021-06-25_11-30-55.log | grep 000C | python client.py -k parse
I get this:
Schema[01:155341 (evohome)] = {
"system": {
"appliance_control": "13:189740"
},
...
I dunno why it is not working for you. Please PM me a packet log that includes a restart of HA.
I have a regular BDR (13: device) I don’t specify this as appliance_control, nor do I add 18: to known_list in configuration.yaml.
The 18: status sensor is there,but no appliance_control. It all seems to be working as intended.
schema:
'01:201047':
system:
appliance_control: null
zones:
'00':
sensor: '01:201047'
config:
enforce_known_list: true
known_list:
- '01:201047':
class: controller
- '04:xxxxxx': bunch of them
class: radiator_valve
- '13:259021':
class: electrical_relay
- '18:070162':
class: gateway_interface
- '22:xxxxxx': bunch of them
class: thermostat
- '13:032522':
class: electrical_relay
- '30:173916':
class: rf_gateway
- '34:046925':
class: thermostat
block_list: []
other_list: []
_is_evofw3: true
device_class: problem
friendly_name: 18:070162 status
Also, the last 3 are specified as orphans_heat: [13:032522, 30:173916, 34:046925] in configuration.yaml, but don’t show up in the 01: schema sensor:
schema:
system:
appliance_control: null
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':...
Well, that two people with the same problem…
I will have to have a look at it.
It woudl be useful if you PM me a packet log that is recorded during a restart of HA.
I’m currently running the latest release at the time of this writing that is 0.20.22g with the configuration from the 0.19.2. My configuration indeed is the one with evohome_cc. Here listed the configuration:
evohome_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
restore_cache: true
ramses_rf:
enforce_known_list: true
max_zones: 8
schema:
controller: 01:214354
known_list:
- "01:214354": { "alias": "--controller--" }
- "18:066327": { "alias": "HGI:evofw3" }
- "07:053519": { "alias": "hotwater_sensor" }
- "13:101655": { "alias": "hotwater_valve" }
- "13:000281": { "alias": "heating_valve" }
- "13:054730": { "alias": "zone_valve zone 00" }
- "04:208553": { "alias": "radiator_valve zone 01" }
- "04:208539": { "alias": "radiator_valve zone 02" }
- "04:208531": { "alias": "radiator_valve zone 03" }
- "04:000673": { "alias": "radiator_valve zone 04" }
- "34:036056": { "alias": "sensor zone 05" }
- "13:004596": { "alias": "actuator zone 05" }
- "04:000667": { "alias": "radiator_valve zone 06" }
- "04:002409": { "alias": "radiator_valve zone 07" }
block_list:
- "18:000703"
- "18:000073"
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
I got updates into HACS throughout the summer and I haven’t put much attention to the CHANGELOG. Then I got into this state.
Now I’m asking whether the process to follow to migrate successfully is the one from the release 0.20.15a.
I did send you my logging for half an hour after a restart of HA
It is now called ramses_cc.
This is now:
ramses_cc:
01:214354:
You don’t need such a block list if your enforcing the known list (anyway, the above list is invalid).
This is now a dict (remove the -) of dicts (include a :).
known_list:
"01:214354": { "alias": "--controller--" }
"18:066327": { "alias": "HGI:evofw3" }
...
block_list:
"18:000703":
"18:000073":
The rotate_bytes: null can be omitted.
Thank you for the fast reaction. This is my configuration after the migration changes
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
restore_cache: true
ramses_rf:
enforce_known_list: true
max_zones: 8
"01:214354":
known_list:
"01:214354": { "alias": "--controller--" }
"18:066327": { "alias": "HGI:evofw3" }
"07:053519": { "alias": "hotwater_sensor" }
"13:101655": { "alias": "hotwater_valve" }
"13:000281": { "alias": "heating_valve" }
"13:054730": { "alias": "zone_valve zone 00" }
"04:208553": { "alias": "radiator_valve zone 01" }
"04:208539": { "alias": "radiator_valve zone 02" }
"04:208531": { "alias": "radiator_valve zone 03" }
"04:000673": { "alias": "radiator_valve zone 04" }
"34:036056": { "alias": "sensor zone 05" }
"13:004596": { "alias": "actuator zone 05" }
"04:000667": { "alias": "radiator_valve zone 06" }
"04:002409": { "alias": "radiator_valve zone 07" }
packet_log:
file_name: packet.log
rotate_backups: 7
am I wondering. is it enough to change and restart HA or should I go through the steps explained here Release New Release [BREAKING CHANGES] · zxdavb/ramses_cc · GitHub?
I think the instructions in the Wiki are pretty complete - just follow the process in Basic Steps.
If there is a problem with that, ask here.
Hi
I appreciate that you have been putting huge amounts of effort into this project recently, but was wondering if you think this issue is resolvable, or whether I need to rework by dashboards ?
think im getting this a bit more
'binary_sensor.01_090653_schema
schema:
system:
appliance_control: null
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Living room
class: radiator_valve
sensor: null
actuators:
- '04:238893'
'01':
_name: Dining room
class: radiator_valve
sensor: '04:238891'
actuators:
- '04:238891'
'02':
_name: Kitchen
class: radiator_valve
sensor: '34:031243'
actuators:
- '04:014748'
- '04:238895'
'03':
_name: Bedroom 1
class: radiator_valve
sensor: '22:119329'
actuators:
- '04:007937'
'04':
_name: Bedroom 2
class: radiator_valve
sensor: '22:066254'
actuators:
- '04:238899'
'05':
_name: Bed 3
class: radiator_valve
sensor: '22:030523'
actuators:
- '04:007929'
'06':
_name: Bed 4
class: radiator_valve
sensor: '22:172287'
actuators:
- '04:007939'
friendly_name: 01:090653 schema
then
[binary_sensor.18_002637_status]
schema:
'01:090653':
system:
appliance_control: null
config:
enforce_known_list: false
known_list:
- '18:002637':
class: gateway_interface
- '10:070498':
class: opentherm_bridge
- '01:090653':
class: controller
- '04:238893':
class: radiator_valve
- '04:238891':
class: radiator_valve
- '04:238895':
class: radiator_valve
- '04:014748':
class: radiator_valve
- '34:031243':
class: thermostat
- '04:007937':
class: radiator_valve
- '04:238899':
class: radiator_valve
- '22:119329':
class: thermostat
- '22:066254':
class: thermostat
- '04:007929':
class: radiator_valve
- '04:007939':
class: radiator_valve
- '22:030523':
class: thermostat
- '22:172287':
class: thermostat
- '12:214942':
class: thermostat
- '13:120980':
class: electrical_relay
- '13:057516':
class: electrical_relay
- '12:083953':
class: thermostat
- '12:261156':
class: thermostat
- '12:100764':
class: thermostat
- '12:256246':
class: thermostat
- '12:206468':
class: thermostat
- '12:212888':
class: thermostat
- '13:225210':
class: electrical_relay
- '13:059944':
class: electrical_relay
block_list:
other_list:
_is_evofw3: null
device_class: problem
friendly_name: 18:002637 status
my config.yaml
ramses_cc:
restore_cache: false
serial_port:
port_name: /dev/ttyUSB0
packet_log:
file_name: /config/packet.log
rotate_backups: 3
ramses_rf:
enforce_known_list: true
max_zones: 7
"01:090653":
system:
appliance_control: 10:070498
known_list:
"04:238893": { "alias": "Living_room_valve" }
"04:238891": { "alias": "Utility room_valve" }
"34:031243": { "alias": "Kitchen_sensor" }
"04:014748": { "alias": "Kitchen_valve1" }
"04:238895": { "alias": "Kitchen_valve2" }
"22:119329": { "alias": "Bedroom1_sensor" }
"04:007937": { "alias": "Bedroom1_valve" }
"22:066254": { "alias": "Bedroom2_sensor" }
"04:238899": { "alias": "Bedroom2_valve" }
"22:030523": { "alias": "Bedroom3_sensor" }
"04:007929": { "alias": "Bedroom3_valve" }
"22:172287": { "alias": "Bedroom4_sensor" }
"04:007939": { "alias": "Bedroom4_valve" }
is this anywhere near right at all ?
I’m not an expert, but some of your indentation does not look right to me, and you don’t need the quotes around the devices. For reference this is mine.
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
baudrate: 115200
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
restore_cache: true
scan_interval: 10
01:185426: {}
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
known_list:
01:185426:
04:003278:
04:003222:
04:003192:
04:003224:
04:003154:
04:003434:
04:003286:
04:003202:
04:003276:
04:003288:
04:026298:
04:026296:
07:046786:
13:164839:
13:197705:
18:136212:
22:220612:
I am afraid I have lost the context… Help me: what version are you running, what issue do you have, etc.
No problem. I see you are dealing with a lot at the moment. Currently running 0.20.22g.
If I have a zone set up as multi-room, I do not get a temperature value for that zone via the climate entity
This was your response before:
OK, here is your answer:
version 0.20.x of ramses_rf is much more efficient with the number of packets it send per unit time - it sent way to many, previously
because of 1., the system does not send a RQ to learn the zone temp, it simply leverages the temperature packet of the periodic sync_cycle set (see below) that are sent every 3-5 minutes:
2022-07-28T10:29:14.453783 || CTL:123456 | | I | system_sync | || {'remaining_seconds': 176.0, '_next_sync': '10:32:10'}
2022-07-28T10:29:14.478621 || CTL:123456 | | I | setpoint | [..] || [{'zone_idx': '00', 'setpoint': 5.0}, {'zone_idx': '01', 'setpoint': 5.0}, {'zone_idx': '02', 'setpoint': 5.0}, {'zone_idx': '03', 'setpoint': 5.0}, {'zone_idx': '04', 'setpoint': 5.0}, {'zone_idx': '05', 'setpoint': 5.0}, {'zone_idx': '06', 'setpoint': 5.0}, {'zone_idx': '07', 'setpoint': 5.0}]
2022-07-28T10:29:14.496550 || CTL:123456 | | I | temperature | [..] || [{'zone_idx': '00', 'temperature': 22.12}, {'zone_idx': '01', 'temperature': 19.89}, {'zone_idx': '02', 'temperature': 19.91}, {'zone_idx': '03', 'temperature': 19.49}, {'zone_idx': '06', 'temperature': 20.59}, {'zone_idx': '07', 'temperature': 20.17}]
You’ll see that this packet does not include a temperature for zones 4 & 5.
But you used to, with an earlier version, right? And the controller shows a value too?
Let me see if I have an old packet log for you, I have an idea.
@Lloyd PM me a packet log taken when HA is restarted. I think I can create a solution - I also want the answers to the above two questions.
I also have this issue, One zone with two HR92s, I get the temprature value for that zone, but other with 3 HR92s, I don’t get the Temprature value. Occationally, it does shows up, gegerally, after a reboot but disapear randomly. Worked befoe the upgrade to ramses_cc format. Schema shows all devices correctly
zones:
'00':
_name: Living-Dining
class: radiator_valve
sensor: '04:112342'
actuators:
- '04:112342'
- '04:112622'
'01':
_name: Bathrooms
class: radiator_valve
sensor: '04:256582'
actuators:
- '04:112616'
- '04:256354'
- '04:256582'