There are reports that restore_cache: false isn’t behaving as expected - I am investigating.
You are right, I just noticed I have updated to the “latest” version in HACS without checking that it was 0.17.6 
I have now re-updated properly to 0.17.7 and the most regex errors have disappeared. Sorry for the trouble.
In 0.17.7 I have now the following logs:
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:391
First occurred: 5:18:39 PM (18 occurrences)
Last logged: 6:18:39 PM
I --- 32:132125 --:------ 32:132125 31DA 030 00EF007FFF2F280366062C07740493F00100587C7C0000EF0026A0253700 < AssertionError(28)
I --- 32:132125 --:------ 32:132125 31DA 030 00EF007FFF2F280366062C0773049CF001005854540000EF001B731D6700 < AssertionError(28)
I --- 32:132125 --:------ 32:132125 31DA 030 00EF007FFF2F28035C0636077304A6F001005850500000EF00157C15B300 < AssertionError(28)
I --- 32:132125 --:------ 32:132125 31DA 030 00EF007FFF2F25037A069A078004D2F001005850500000EF00159715B300 < AssertionError(25)
I --- 32:132125 --:------ 32:132125 31DA 030 00EF007FFF2F25038406AE078504D9F001005850500000EF0015B315B300 < AssertionError(25)
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 382, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 151, in wrapper
result = fnc(payload, msg, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 1774, in parser_31da
assert payload[12:14] == "EF", payload[12:14]
AssertionError: 25
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:398
First occurred: 5:18:39 PM (6 occurrences)
Last logged: 6:18:39 PM
I 151 32:132125 --:------ 32:132125 31D9 017 002A040020202020202020202020202008 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}([02]{28})?$': 002A040020202020202020202020202008
I 152 32:132125 --:------ 32:132125 31D9 017 002A030020202020202020202020202008 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}([02]{28})?$': 002A030020202020202020202020202008
I 153 32:132125 --:------ 32:132125 31D9 017 002A030020202020202020202020202008 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}([02]{28})?$': 002A030020202020202020202020202008
I 154 32:132125 --:------ 32:132125 31D9 017 002A030020202020202020202020202008 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}([02]{28})?$': 002A030020202020202020202020202008
I 155 32:132125 --:------ 32:132125 31D9 017 002A040020202020202020202020202008 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}([02]{28})?$': 002A040020202020202020202020202008
(and still the one that you told me you’ve already fixed and I can ignore for the time being)
Concerning the outdoor_humidity, I think my ventillation measures this. My ventillation is a black box and I am not sure which data are coming out of it the moment so I am looking forward to see what can be obtained. It’s a ventillation with heat recovery and automatic bypass so maybe the outdoor temperature is somehow measured as part of the logic to decide if the bypass should be opened or closed.
From what I can see on the manufacturer documentation, the following data should be somehow provided by the ventilation:
Software version
Home relative humidity (%)
Supply air relative humidity (%)
Exhaust air temperature to outside (°C)
Supply air temperature
Supply air temperature to the dwelling (°C)
Pre-heating actuation (%)
Temperature outside the dwelling (°C)
Current supply air volume flow (m3 /h)
External temperature (°C)
Current exhaust air volume flow (m3 /h)
Bypass position
Extract fan speed (%)
Supply air fan speed (%)
Time remaining in minute after running humidity scenario (min.)
So I currently getting a few of these msgs:
AssertionError: RP --- 10:040239 18:005567 --:------ 2401 004 00000102 < Please support the development of ramses_rf by reporting this packet
AssertionError: RP --- 10:040239 18:005567 --:------ 2401 004 000004C8 < Please support the development of ramses_rf by reporting this packet
AssertionError: RP --- 10:040239 18:005567 --:------ 2401 004 000005C8 < Please support the development of ramses_rf by reporting this packet
AssertionError: RP --- 10:040239 18:005567 --:------ 2401 004 000003C8 < Please support the development of ramses_rf by reporting this packet
running 0.17.6
Please keep up - I have just released 0.17.7a 
This has been added as a value in versions from/after 0.17.7 (called value, and percent).
The latest version of Evohome_CC works very stable ! very happy with it.
Was trying to get the thermostate from the wiki working… but seems somehow i miss something…
When i try to change the temperature i get :
2022-01-11 22:29:07 ERROR (MainThread) [homeassistant.components.script.1635889893515] Evohome simple thermostat temporary: Error executing script. Invalid data for call_service at pos 2: extra keys not allowed @ data['setpoint']
2022-01-11 22:29:07 ERROR (MainThread) [homeassistant.components.script.evohome_simple_thermostat] Evohome simple thermostat: Error executing script. Invalid data for call_service at pos 1: extra keys not allowed @ data['setpoint
My evohome simple thermostat script :
alias: Evohome simple thermostat
sequence:
- service: script.1635889893515
data:
entity_id: '{{entity_id}}'
temperature: '{{temperature}}'
- condition: template
value_template: '{{states(''input_text.evohome_preset_mode'') ==''permanent'' }}'
- service: evohome_cc.set_zone_mode
data:
entity_id: '{{entity_id}}'
setpoint: '{{temperature}}'
mode: |-
{% if states('input_text.evohome_preset_mode') =='permanent' %}
permanent_override
{% else %}
temporary_override
{% endif %}
mode: single
My simple thermostat temporary (script.1635889893515) :
alias: Evohome simple thermostat temporary
sequence:
- condition: template
value_template: '{{states(''input_text.evohome_preset_mode'') ==''temporary'' }}'
- service: evohome_cc.set_zone_mode
data:
entity_id: '{{entity_id}}'
setpoint: '{{temperature }}'
mode: temporary_override
duration: '{{states(''input_number.evohome_duration_slider'') | int}}'
mode: single
My thermostat code :
type: vertical-stack
cards:
- type: custom:simple-thermostat
entity: climate.evohome_cc_01_085674_02
header:
name: Charlotte
sensors:
- entity: binary_sensor.04_130039_battery_low_2
name: TRV battery
- entity: binary_sensor.34_065038_battery_low_2
name: Thermosat Battery
- entity: binary_sensor.04_130039_window_open_2
name: Window open
- entity: sensor.04_130039_heat_demand
name: heat demand
service:
domain: script
service: evohome_simple_thermostat
control:
- hvac: false
- preset: false
- type: horizontal-stack
cards:
- type: custom:button-card
color: '#dff4fd'
color_type: card
icon: mdi:cancel
name: Cancel override
entity: input_text.evohome_preset_mode
state:
- operator: template
value: >-
[[[ return
((states['climate.evohome_cc_01_085674_02'].attributes.preset_mode
== 'permanent') ||
(states['climate.evohome_cc_01_085674_02'].attributes.preset_mode
== 'temporary')) ]]]
color: '#03a9f4'
styles:
icon:
- color: white
name:
- color: white
tap_action:
action: call-service
service: evohome_cc.reset_zone_mode
service_data:
entity_id: climate.evohome_cc_01_085674_02
styles:
card:
- height: 60px
- border-radius: 4px
- color: '#03a9f4'
name:
- font-size: 14px
- padding-bottom: 3px
- type: custom:button-card
color: '#dff4fd'
color_type: card
icon: mdi:timer-off-outline
name: Permanently override
entity: input_text.evohome_preset_mode
state:
- value: permanent
color: '#03a9f4'
styles:
icon:
- color: white
name:
- color: white
tap_action:
action: call-service
service: input_text.set_value
service_data:
entity_id: input_text.evohome_preset_mode
value: permanent
styles:
card:
- height: 60px
- border-radius: 4px
- color: '#03a9f4'
name:
- font-size: 14px
- padding-bottom: 3px
- type: custom:button-card
color: '#dff4fd'
color_type: card
icon: mdi:timer-outline
name: Temporarily override
entity: input_text.evohome_preset_mode
state:
- value: temporary
color: '#03a9f4'
styles:
icon:
- color: white
name:
- color: white
tap_action:
action: call-service
service: input_text.set_value
service_data:
entity_id: input_text.evohome_preset_mode
value: temporary
styles:
card:
- height: 60px
- border-radius: 4px
- color: '#03a9f4'
name:
- font-size: 14px
- padding-bottom: 3px
- type: custom:slider-entity-row
name: Duration
entity: input_number.evohome_duration_slider
Any suggestion…
Not that I use it very often, but I don’t seem to be able to set a Permanent nor Temporary override? Does this work for others?
In some examples you seem to have:
'{{temperature }}'
Then others:
'{{temperature}}'
… not sure off hand if this would/does impact things, however. But the error to me says something extra is being provided for the ‘setpoint’ when it needs to just be a number without anything else?
If I run this, in the Developer Tools:
service: evohome_cc.set_zone_mode
data:
entity_id: climate.ed_office
mode: temporary_override
setpoint: 21
It works. If I run this:
service: evohome_cc.set_zone_mode
data:
entity_id: climate.ed_office
mode: temporary_override
setpoint: 21 c
I get an error about not being allowed extra keys @ setpoint
setpoint has a value (currently) of 24
The evohome_cc works also when i run it.
But with your code you can set change the temperature / you don’t get an error ?
It would be very useful if anyone with a OpenTherm bridge (an R8810A, R8820A) send me a packet log.
If anyone is using the (rather secret) use_regex feature, please let me know - I’m about to deprecate it.
However, I am first wanting to confirm if it is no longer needed.
I was going to use it but we never got round to it.
I tried it and it doesn’t work for me either
According to the log it looks like the value of setpoint/active is missing
set_zone_mode('01:024170', 0, 'temporary_override', None, None, {}): Invalid args: For temporary_override, setpoint/active cant be None
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 148, in _wrapper
return fcn(cls, *args, **kwargs)
File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 736, in set_zone_mode
mode = _normalise_mode(mode, setpoint, until, duration)
File "/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 221, in _normalise_mode
raise ValueError(
ValueError: Invalid args: For temporary_override, setpoint/active cant be None
Clear, then can focus on debugging code instate of the scripts…
I have just pushed a new release, 0.17.10.
The main change from 0.17.7x is the addition of another fault sensor, which will be ‘on’ when the USB dongle hasn’t been heard from for 3 minutes - this would indicate something has gone wrong (although maybe it should be 5, 10 minutes?).
- this
gatewaysensor replaces the correspondingconfigurationsensor (which was always true)
Can as meany people as possible move to this release, please, and report back any issues - I would like to spend some time ironing out any bugs, and making it into a stable release.
I need to completely refactor polling, and packet expiry, and add in callbacks for state change - I won’t start that until we have a stable release.
updated, was running 0.17.7a, very stable, no issues.
Only isseu i have is with the thermostat from the wiki as described.
Will do some more experiments and testing to see if can find something else.
Thanks for your great work !
This is a bug - you’ll get this if your logbook is empty.
It should not cause too many other issues, and a fix is coming.
FWIW on my mini system, I’ve upgraded to 0.17.10, changed to restore_cache and (finally) added a known_list:
evohome_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: packet.log
restore_cache: true
ramses_rf:
enforce_known_list: true
known_list:
- "13:003246": { "alias": "Boiler Relay" }
- "12:158468": { "alias": "Thermostat Remote" }
- "18:198161": { "alias": "Gateway" }
and everything seems to be working just fine after a bit of struggling during the upgrade (see below).
The only thing I note is a number of sensors that are marked as “unavailable” (which is correct, I wouldn’t think the BDR91 is reporting back e.g. DHW status. It would be nice to have those sensors at all in that case, to avoid clutter and confusion.
Regarding the Upgrade struggle I went through: for some reason after the upgrade evohome_cc decided to recreate some of the entities as _2 variants, instead of re-using the entities I already had from before. I uninstalled it from HACS, restarted HA, manually deleted all relevant entities, reinstalled the extension in HACS, restarted again, re-added the config (now with the known_list and enforce_known_list) and restarted a third time. Now the extension recreated all entities with the original IDs and all my references in Lovelace worked again.
Overall, great success I’d say.
PS: for completeness and reference, also my evohome_cc state cache file:
{
"version": 1,
"minor_version": 1,
"key": "evohome_cc",
"data": {
"client_state": {
"schema": {
"main_controller": null,
"orphans": [
"13:003246",
"12:158468"
],
"device_hints": {}
},
"packets": {
"2022-01-14T19:30:06.774272": "... I --- 13:003246 --:------ 13:003246 1100 008 00180404007FFF01 # 1100| I|13:003246",
"2022-01-15T04:04:25.658558": "... I --- --:------ --:------ 12:158468 1100 005 0018040400 # 1100| I|12:158468",
"2022-01-15T17:53:16.032367": "... RP --- 13:003246 18:198161 --:------ 1100 008 00180404007FFF01 # 1100|RP|13:003246",
"2022-01-15T17:55:34.013059": "... I --- --:------ --:------ 12:158468 2309 003 010834 # 2309| I|12:158468|01 (01)",
"2022-01-15T18:05:38.719569": "... I --- 13:003246 --:------ 13:003246 3EF0 003 0000FF # 3EF0| I|13:003246",
"2022-01-15T18:05:39.062602": "... I --- --:------ --:------ 12:158468 0008 002 0000 # 0008| I|12:158468|00 (00)",
"2022-01-15T18:07:17.188978": "... RP --- 13:003246 18:198161 --:------ 0008 002 0000 # 0008|RP|13:003246",
"2022-01-15T18:07:17.237615": "... RP --- 13:003246 18:198161 --:------ 3EF1 007 0001F601F600FF # 3EF1|RP|13:003246"
}
}
}
}
@zxdavb: When i use UFH there is no hvac_action as attribute of the climate entity. Can i help you to fix it?
Is that a new issue? Or has it always been like that? PM me.