I have fixed this bug - a new release is coming.
1 Like
New release, 0.20.10 is now recommended version.
1 Like
New release, 0.20.11 is now the recommended version.
It includes the start of HVAC support - read only for now.
Note the schema has changed for RF remotes, they are now REM and not SWI (read the release notes).
When will you mark these as stable for HACS? Iâm still on version 0.18.8 and no new update is being offered.
Short answer: when I am convinced I have stopped creating breaking changes.
FYI: There will be no updates for 0.18.x, nor 0.19.x and unless you have HVAC, 0.20.x offers only a little extra in terms of day-to-day use (although Zone/DHW schedules are coming soon).
Mind you, if you are using ramses_cc for CH/DHW (evohome), then you are better off leaping now, rather than waiting fro next Winter.
You can enable the ability to download pre-releases in the HACS UI.
Alright. Iâll migrate this week to the latest beta release.
I was kind of hoping that perhaps a newer version would increase stability, but I guess this is not the case?
Every couple of days the integration crashes and I lose all entities. Only a system restart resolves it, until the next crash a couple days later.
Nothing interesting in the logs really other than occasional warning about expired packages and once in a while an error that looks like this:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py:443
First occurred: 2:00:00 PM (1 occurrences)
Last logged: 2:00:00 PM
000 I --- 03:025614 --:------ 03:256014 30C9 003 0008FC < Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 03:025614 --:------ 03:256014
But, even in these cases, the integration remains operational.
I havenât really had regular reports of persistent instability - anyone else?
It is the case that the 0.20.x version will have made much of the 0.18.x / 0.19.x codebase much more reliable - but I have reduced the safetyâs in response to that, and it it a significant refactor - YMMV - worth a go, I feel (I will address / have addressed any bugs ASAP).
I lot of this logging is of interest to me only.
hi all,
could somebody have a look at my configuration for the 0.20.11 release?
it is probably something simple with the spacing,but i do not see my error. even with my reading glasses on.
i recieve the following error: voluptuous.error.MultipleInvalid: extra keys not allowed @ data[âsystemâ][âzonesâ]
my configuration (i used the minimal schema example):
ramses_cc:
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
packet_log: packet.log
restore_cache: true
ramses_rf:
enable_eavesdrop: true
enforce_known_list: false
schema:
controller: 01:126213
system:
zones:
01:
sensor: 01:126213
known_list:
- 01:126213
- 63:262143
- 04:230305
- 04:230319
- 04:230317
- 04:231469
- 04:231485
- 04:230311
- 04:230315
- 04:230313
- 37:084440
- 12:079416
- 18:009448
I would always have enforce_known_list: true if you can. And enable_eavesdrop: true is dangerous, leave it to false when you donât need it anymore.
Try:
zones:
"01":
sensor: 01:126213
Actually: what is that!
If it is an OTB, try:
schema:
controller: 01:126213
system:
appliance_control: 63:262143
zones:
"01":
sensor: 01:126213
known_list:
- 63:262143: {class: OTB}
If it is not an OTB, let me know - let me know anyway if it changes anything for you.
Is that yours? If so, is it a fan of some type (HRU, CVE, PIV)? If so:
schema:
controller: 01:126213
system:
appliance_control: 63:262143
zones:
"01":
sensor: 01:126213
orphans_hvac:
- 37:084440
known_list:
- 63:262143: {class: OTB}
- 37:084440: {class: FAN}
Iâve started migration. Iâm stuck at step 4. Iâve changed the configuration.yaml but when I restart HA I get an error:
This error originated from a custom integration.
Logger: homeassistant.setup
Source: custom_components/ramses_cc/__init__.py:92
Integration: ramses_cc (documentation, issues)
First occurred: 9:41:36 AM (1 occurrences)
Last logged: 9:41:36 AM
Error during setup of component ramses_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 235, in _async_setup_component
result = await task
File "/config/custom_components/ramses_cc/__init__.py", line 92, in async_setup
client = ramses_rf.Gateway(serial_port, loop=hass.loop, **config, **schema)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/gateway.py", line 329, in __init__
load_schema(self, **self._schema)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/schema.py", line 369, in load_schema
[
File "/usr/local/lib/python3.10/site-packages/ramses_rf/schema.py", line 370, in <listcomp>
load_system(gwy, ctl_id, schema)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/schema.py", line 390, in load_system
ctl.tcs._update_schema(**schema) # TODO
File "/usr/local/lib/python3.10/site-packages/ramses_rf/systems.py", line 211, in _update_schema
schema = shrink(SCH_SYS(schema))
File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 595, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.10/site-packages/voluptuous/schema_builder.py", line 433, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['system']['zones']
This is my configuration:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
restore_cache: true
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
schema:
controller: 01:205114
system:
zones:
00: # Badkamer 1
class: radiator_valve
sensor: 04:164227
actuators:
- 04:164227
01: # Woonkamer
class: radiator_valve
sensor: 01:205114 # Main controller
actuators:
- 04:014708
- 04:014696
- 04:164041
02: # Badkamer 2
class: radiator_valve
sensor: 34:018143
actuators:
- 04:014712
04: # H Slaapkamer
class: radiator_valve
sensor: 03:256014 #Fake sensor for AC
actuators:
- 04:164247
05: # L Slaapkamer
class: radiator_valve
sensor: 04:122639
actuators:
- 04:122639
06: # R Slaapkamer
class: radiator_valve
sensor: 04:079671
actuators:
- 04:079671
known_list:
#Gateway
#- "18:205572"
# Controller
- "01:205114"
#Badkamer 1
- "04:164227"
#Woonkamer
- "04:014708"
- "04:014696"
- "04:164041"
# Badkamer 2
- "04:014712" #Valve
- "34:018143" #Thermostat
# H Slaapkamer
- "03:256014": { faked: true } #Fake sensor for AC
- "04:164247" #Valve
# L Slaapkamer
- "04:122639"
# R Slaapkamer
- "04:079671"
Not fully sure on the known list because it doesnât say anything about that on the breaking changes page in the example schema. I also find it weird that I have to list all the IDâs twice. Once in the schema and once in the known list (canât that known list be taken from the schema automatically?).
I tried to put the fake sensor stuff in the sensor tag in the zone but it wouldnât take that either.
PS: I know I skipped zone 03. And started from 00. No idea, I took this schema from the controller attribute before I started the migration. If you want to see it, here it is:
system:
heating_control: null
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Badkamer 1
zone_type: radiator_valve
zone_sensor: '04:164227'
sensor_alt: '04:164227'
devices:
- '04:164227'
actuators:
- '04:164227'
'01':
_name: Woonkamer
zone_type: radiator_valve
zone_sensor: null
sensor_alt: null
devices:
- '04:014708'
- '04:014696'
- '04:164041'
actuators:
- '04:014708'
- '04:014696'
- '04:164041'
'02':
_name: Badkamer 2
zone_type: radiator_valve
zone_sensor: '34:018143'
sensor_alt: '34:018143'
devices:
- '04:014712'
- '34:018143'
actuators:
- '04:014712'
'04':
_name: H Slaapkamer
zone_type: radiator_valve
zone_sensor: '03:256014'
sensor_alt: '03:256014'
devices:
- '04:164247'
- '03:256014'
actuators:
- '04:164247'
'05':
_name: L Slaapkamer
zone_type: radiator_valve
zone_sensor: '04:122639'
sensor_alt: '04:122639'
devices:
- '04:122639'
actuators:
- '04:122639'
'06':
_name: R Slaapkamer
zone_type: radiator_valve
zone_sensor: '04:079671'
sensor_alt: '04:079671'
devices:
- '04:079671'
actuators:
- '04:079671'
About 6 posts back:
.and I said:
You asked:
Sorry, no: I donât have time to go over it, but it is a bad idea. Instead:
a) have a complete known_list
b) have the smallest schema you can get away with, usually:
schema:
controller: 01:205114
âŚor, if you have an OTB:
schema:
controller: 01:126213
system:
appliance_control: 10:062143
BTW, you can do this:
known_list:
- "01:205114" # Controller
⌠or this:
known_list:
- "01:205114": {_note: Controller}
BTW, if I understand correctly, youâre asking why it goes 00-02, then 04-06, and not (say):
- 00 to 05, or
- 01 to 06
The answer is: these are not ordinals, but slot numbers (starting from slot 0x00). If you create a zone, it always uses the lowest available slot, 03 in your case, then 07 after that.
If I had created 7 zones (00 to 06), then deleted the 4th zone (03), I would see what you are seeing.
Thanks for all the help.
I did try putting the zone number between " " as per the previous post but that didnât help me.
I just removed the entire âsystemâ piece since you said:
This is now my complete configuration.yaml
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
restore_cache: true
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
schema:
controller: 01:205114
known_list:
#Gateway
#- "18:205572"
- "01:205114": {_note: Controller}
#Badkamer 1
- "04:164227"
#Woonkamer
- "04:014708"
- "04:014696"
- "04:164041"
# Badkamer 2
- "04:014712" #Valve
- "34:018143" #Thermostat
# H Slaapkamer
- "03:256014": { faked: true } #Fake sensor for AC
- "04:164247" #Valve
# L Slaapkamer
- "04:122639"
# R Slaapkamer
- "04:079671"
Restarting HA doesnât throw an error anymore. Iâll try to see if my entities etc. show up now.
Looks like everything is working fine 
Only thing I noticed is that when I call ramses_cc.put_zone_temp it immediately triggers an error in the log:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py:915
First occurred: 1:06:50 PM (3 occurrences)
Last logged: 1:06:51 PM
have seen tx_rcvd( I --- 18:205572 63:262142 --:------ 7FFF 023 00110181F73D79DA33304339204930333A323536303134), rx_rcvd=None
have seen tx_rcvd( I --- 03:256014 --:------ 03:256014 30C9 003 0007D0), rx_rcvd=None
It does work fine, however, the temperature is correctly updated.
And thatâs one example why having a minimal schema is good practice.
Many of these are for my benefit only - I lose track of what is in the Dev version & what is in the Production version (sorry) - they can usually be ignored.
1 Like
Alright, cool. I can ignore them
Iâll let you know if I see anything weird the next few days (like those random crashes I mentioned before)
i am not sure. my heating system contains of evohome (8x HR91, 1x evohome touch 1x open therm R881) and my boiler which is a Nefit/Bosch system. they use the EMS bus to communicate. to connect the open therm module to the boiler, i had to place a open therm/EMS converter inbetween. so i suppose this might be it.
i doubt it is mine. we do have a fan (Brink Renovent) and a wireless remote in the bathroom. but this is a very basic system. the remote receiver at the fan, consists of simply 2 relays and a receiver in a box. i looked in the log at the time of the messages. we would usually operate the fan around 19:30, when it is time to hose the kids down. but i see no messages around that time