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'
@Lloyd 's issue is caused by a zone in multiroom mode (and a change in the way the system retrieves zone temps) - it does not sound like your problem, which is intermittent?
Have a look at your packet log. Or PM it to me, if you like.
Packet log sent.
Yes, this did used to work, and temperatures are displayed correctly on controller.
OK, I have a working solution for multiroom zones, so that their HA entities now have a temperature again.
It is a relatively simple change, so that |I’m happy to push it to the stable branch.
That’s great. I’ll install it as soon as it is available.
