zxdavb / ramses_cc Goto Github PK

View Code? Open in Web Editor NEW

68.0 6.0 15.0 963 KB

HA integration for CH/DHW and HVAC systems that use the RAMSES II RF protocol

License: GNU General Public License v3.0

Python 100.00%

homeassistant evohome sundial hometronics ramses rf chronotherm itho orcon resideo

ramses_cc's People

Contributors

Stargazers

Watchers

Forkers

lustasag martynwendon phdelodder btscroggs sockhamster joepwi lebeno gazoodle janvkem davids tomkooij jbsdm pcr20 muddyrock trvrnrth

ramses_cc's Issues

FAN bypass_mode state not maintained as expected

When using the Orcon RF15 display for controlling the bypass_mode this is reflected in HA correctly,

When instructing the remote to set bypass_open, bypass_close or bypass_auto the status remains unchanged.

In the packet.log I can see the messages. What could be wrong?

cannot import name 'UnitOfTime' from 'homeassistant.const'

I connected an Arduino with a CC1101 and evofw3 on the Raspberry on which I run home assistant (2022.12.4).
Since I just started I only configured it as follows:

ramses_cc: serial_port: /dev/ttyACM0 # or some other serial port name

But on restart I got:
Logger: homeassistant.setup Source: setup.py:338 First occurred: 15:20:59 (1 occurrences) Last logged: 15:20:59 Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'UnitOfTime' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)).

Any help?

Change `ignore_list` to `allow_list`

Just a suggestion, instead of opting out (e.g. blacklist way), it might be a idea to change this to a white-list way; e.g. add option allow_list which would mean only those controllers would be connected to.

Manual preset change - changes back to None, before then updating a minute later to 'temporary'

Version 0.5.20

If I make a manual Preset change to a heating zone - for example, None -> Temporary - the UI will flick back to 'None', the original state, before updating to the new state (Temporary) around a minute later. I don't think this used to happen on earlier releases, such as 0.5.10, although I will roll-back to check.

Video demo attached:

https://www.dropbox.com/s/hvr6x9ag0y6gb1k/Screen%20Recording%202021-03-08%20at%2012.04.24.mov?dl=0

Invalid config for [evohome_cc]: required key not provided

I encounter an issue with this cc for a few days.
I tried re-install of the cc via HACS, HAOS is up to date (5.11), and last releases.

The full error message : Invalid config for [evohome_cc]: required key not provided @ data['evohome_cc']['config']. Got None.

Extract of my configuration.yaml :

evohome_cc:
scan_interval: 60
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
schema:
controller: 01:xxxxxx

If I add the packet_log attribute, i got this error : Invalid config for [evohome_cc]: [packet_log] is an invalid option for [evohome_cc]. Check: evohome_cc->evohome_cc->packet_log.

allow_list: or block_list: don't appear to being processed from the configuration.yaml correctly

Logger: custom_components.evohome_cc
Source: custom_components/evohome_cc/__init__.py:62
Integration: Honeywell RF (RAMSES II protocol) (documentation, issues)
First occurred: 4:31:51 PM (1 occurrences)
Last logged: 4:31:51 PM

evohome_cc v0.7.1, using evohome_rf v0.7.1 - versions match (this is good)

Even if allow_list is specified, I get a message

Logger: evohome_rf.transport
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/transport.py:323
First occurred: 4:15:47 PM (1 occurrences)
Last logged: 4:15:47 PM
Not Using an device filter (an allow_list is recommended)

If block_list is specified, I get a message

Logger: evohome_rf.schema
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/schema.py:263
First occurred: 4:15:47 PM (1 occurrences)
Last logged: 4:15:47 PM
An empty blocklist was configured, so will be ignored

If both a specified, then I get a correct message that both cannot be specified. But nothing in my allow_list of block_list appears to being processed.
Here is my configuration.yaml

evohome_cc:
  scan_interval: 60
  serial_port: rfc2217://localhost:5001
  config:
    packet_log: evohome/packet.log
  schema:
    controller: 01:078710
  allow_list:
    - 10:067219
    - 07:017494
    - 13:109598
    - 04:133277
    - 04:057586
    - 22:032844
    - 22:060293
    - 13:114333
    - 04:061731
    - 34:103601
    - 04:061402
    - 04:187989
    - 34:147397
    - 04:061760
    - 34:103839
    - 04:098464
    - 04:098306
    - 04:098474
    - 04:098449
    - 04:098455
#  block_list:
#    - 12:106131
#    - 13:031200
#    - 13:050361
#    - 13:031208
#    - 13:101853
#    - 13:125302
#    - 13:144830
#    - 13:133379
#    - 22:055075
#    - 22:068154
#    - 22:006688
#    - 22:054901
#    - 22:068254
#    - 31:118732
#    - 31:011364

0.30.0 - options not supported (e.g. enforce_known_list)

See: https://community.home-assistant.io/t/honeywell-ch-dhw-via-rf-evohome-sundial-hometronics-chronotherm/151584/3593

Config changed as logs warned about options that not supported
Commented Out:

enforce_known_list: true
disable_sending: false

Cannot simulate a BDR91T

With the BDR91T now functionaly is added to the controller.
To only difference between the BDR91 and BDR91T is sotware..
But still at the controller there will be different settings.
The ID is accoording to overview identically, so how does the controller know it is the T version ?

Would like to simulate this to play with this, and potentially let HA steer a relay instead of the BDR91T.
Since the BDR91T setting are still not so OK for a HeatPump..

Do not allow HA to change a zone's friendly_name

Instead, through an error, asking the user to rename teh zone in teh controller UI - this is to keep teh friendly name and teh zone name in sync.

Problem with config.yaml

I despair. For hours I've been trying to get my configuration to work under HA. I keep getting the following error message.

Invalid config for [ramses_cc]: expected a list for dictionary value @ data['ramses_cc']['known_list']. Got OrderedDict([('32:123456', OrderedDict([('class', 'FAN'), ('_note', 'Orcon HRC 400')])), ('29:123456', OrderedDict([('class', 'REM'), ('faked', True), ('commands', OrderedDict([('away', ' I --- 29:123456 32:123456 --:------ 22F1 003 000007'), ('low', ' I --- 29:123456 32:123456 --:------ 22F1 003 000107'), ('medium', ' I --- 29:123456 32:123456 --:------ 22F1 003 000207'), ('high', ' I --- 29:123456 32:123456 --:------ 22F1 003 000307'), ('auto', ' I --- 29:123456 32:123456 --:------ 22F1 003.... (See /config/configuration.yaml, line 18).

Here my Config from line 18

 ramses_cc:
   serial_port: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
   known_list:
     32:123456 : { class: FAN, _note: Orcon HRC 400 } 
     29:123456:
       class: REM
       faked: True
       commands:
         away:         ' I --- 29:123456 32:123456 --:------ 22F1 003 000007'
         low:          ' I --- 29:123456 32:123456 --:------ 22F1 003 000107'
         medium:       ' I --- 29:123456 32:123456 --:------ 22F1 003 000207'
         high:         ' I --- 29:123456 32:123456 --:------ 22F1 003 000307'
         auto:         ' I --- 29:123456 32:123456 --:------ 22F1 003 000407'
         auto2:        ' I --- 29:123456 32:123456 --:------ 22F1 003 000507'
         boost:        ' I --- 29:123456 32:123456 --:------ 22F1 003 000607'
         disable:      ' I --- 29:123456 32:123456 --:------ 22F1 003 000707'
         bypass_open:  ' W --- 29:123456 32:123456 --:------ 22F7 003 00C8EF'
         bypass_close: ' W --- 29:123456 32:123456 --:------ 22F7 003 0000EF'
         bypass_auto:  ' W --- 29:123456 32:123456 --:------ 22F7 003 00FFEF'
         reset_filter: ' W --- 29:123456 32:123456 --:------ 10D0 002 00FF'
       _note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)`

Difference between hvac_mode and set_temperature

I'm going through the code and detect that hvac_mode: uses self._evo_device.mode["setpoint"] and target_temperature: uses self._evo_device.setpoint. In case of an open window the target remains at eg 18 but the state is off, although the set point according to evohome is set to 5°c. So I guess the target _tempature should also be using self._evo_device.mode["setpoint"]?

Preset default should be AUTO and not AWAY

https://github.com/zxdavb/evohome_cc/blob/6686f9b6368b95f0e134701bffcb451500dd9097/custom_components/evohome_cc/climate.py#L383

Temperature Entity not being created

I have a strange situation where it looks like the temperature entity for a TRV is not being created, but the demand, window status and battery entities are. This is only happening for one TRV, all others are OK. From the log, I'm seeing this:

2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery_low), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (window_open), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat_demand), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temperature), id=04:026298

but all searches for that entity are failing.

This is an extract from the packet.log, searching on that id.

2021-11-02T08:19:05.774571 059  I --- 04:026298 --:------ 01:185426 3150 002 063A
2021-11-02T08:19:15.540739 059  I --- 04:026298 --:------ 04:026298 30C9 003 0005BF
2021-11-02T08:20:08.411651 ...  I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T08:20:08.416771 ...  I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T08:20:08.558479 ...  I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T08:20:08.922698 ...  I --- 04:026298 --:------ 01:185426 3150 002 06A6 # 3150| I|04:026298|06 (06)
2021-11-02T08:20:08.925061 ...  I --- 04:026298 --:------ 04:026298 30C9 003 00056B # 30C9| I|04:026298
2021-11-02T08:21:17.466113 063  I --- 04:026298 --:------ 04:026298 30C9 003 0005DB
2021-11-02T08:22:08.047815 064  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T08:23:17.974858 064  I --- 04:026298 --:------ 04:026298 30C9 003 0005F3
2021-11-02T08:25:16.450908 065  I --- 04:026298 --:------ 04:026298 30C9 003 000607
2021-11-02T08:28:18.278433 065  I --- 04:026298 --:------ 04:026298 30C9 003 000621
2021-11-02T08:31:17.564646 060  I --- 04:026298 --:------ 04:026298 30C9 003 000634
2021-11-02T08:34:15.735271 060  I --- 04:026298 --:------ 04:026298 30C9 003 000647
2021-11-02T08:35:15.467072 059  I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T08:35:15.481652 059  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T08:35:17.894218 060  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T08:38:18.675305 060  I --- 04:026298 --:------ 04:026298 30C9 003 00065A
2021-11-02T08:42:08.143821 060  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T08:42:17.660345 060  I --- 04:026298 --:------ 04:026298 30C9 003 00066E
2021-11-02T08:49:17.348809 052  I --- 04:026298 --:------ 04:026298 30C9 003 000682
2021-11-02T08:52:23.192846 ...  I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T08:52:23.205490 ...  I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T08:52:23.409089 ...  I --- 04:026298 --:------ 01:185426 2309 003 0605DC # 2309| I|04:026298|06 (06)
2021-11-02T08:52:23.416607 ...  I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T08:52:23.487101 ...  I --- 04:026298 --:------ 01:185426 3150 002 0600 # 3150| I|04:026298|06 (06)
2021-11-02T08:52:23.719065 ...  I --- 04:026298 --:------ 04:026298 30C9 003 000682 # 30C9| I|04:026298
2021-11-02T08:58:15.210531 061  I --- 04:026298 --:------ 04:026298 30C9 003 000694
2021-11-02T09:02:06.909361 057  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:22:08.624545 053  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:27:16.005859 058  I --- 04:026298 --:------ 04:026298 30C9 003 000681
2021-11-02T09:33:17.221380 056  I --- 04:026298 --:------ 04:026298 30C9 003 00066E
2021-11-02T09:35:12.688809 057  I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T09:35:12.704170 057  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T09:35:13.288467 057  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T09:42:09.426030 056  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:42:16.606795 056  I --- 04:026298 --:------ 04:026298 30C9 003 00065B
2021-11-02T09:51:15.074033 052  I --- 04:026298 --:------ 04:026298 30C9 003 000648
2021-11-02T10:02:09.820152 071  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T10:11:16.689118 060  I --- 04:026298 --:------ 04:026298 30C9 003 000633
2021-11-02T10:20:27.098694 ...  I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T10:20:27.113696 ...  I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T10:20:27.311082 ...  I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T10:20:27.581447 ...  I --- 04:026298 --:------ 01:185426 3150 002 0600 # 3150| I|04:026298|06 (06)
2021-11-02T10:20:27.755137 ...  I --- 04:026298 --:------ 04:026298 30C9 003 000633 # 30C9| I|04:026298
2021-11-02T10:22:06.554402 065  I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T10:35:13.766704 060  I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T10:35:13.781870 060  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T10:35:14.163014 060  I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T10:42:09.282850 054  I --- 04:026298 --:------ 01:185426 3150 002 0600

Any suggestions on how I can debug this one?

Unknown message 2210

The Orcon RF15 control unit https://orcon.nl/product/afstandsbediening-15rf/ address 18:071957 which sends 2210 messages, do you know what they are?

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.11/site-packages/ramses_rf/protocol/message.py:350
First occurred: 25 juni 2023 om 19:56:07 (5 occurrences)
Last logged: 25 juni 2023 om 20:13:20

RP --- 32:155021 18:071957 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000020800 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/parsers.py", line 140, in wrapper
    result = fnc(payload, msg, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/parsers.py", line 1335, in parser_2210
    assert payload in (
           ^^^^^^^^^^^^
AssertionError: Support the development of ramses_rf by reporting this packet

After running 0.5.1 for a few hours the climate state became unknown

Running the 0.5.1 for about 7 hours, the state of the controller and all the zone became "unknown".

climate.controller
State: unknown
Attributes:

	hvac_modes:
	  - 'off'
	  - heat
	min_temp: null
	max_temp: null
	preset_modes:
	  - none
	  - eco
	  - away
	  - home
	  - custom
	current_temperature: 16
	temperature: 12
	preset_mode: null
	controller: '01:223036'
	heat_demand: 1
	friendly_name: Controller
	supported_features: 17

climate.controller:
state: unknown
Attributes:

	hvac_modes:
	  - heat
	  - 'off'
	min_temp: 5
	max_temp: 35
	current_temperature: 15.1
	temperature: 12
	controller: '01:223036'
	heating_type: radiator_valve
	zone_config:
	  min_temp: 5
	  max_temp: 35
	  local_override: true
	  openwindow_function: true
	  multiroom_mode: false
	heat_demand: 0
	friendly_name: Dressing
	supported_features: 1

2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Schema = {'controller': '01:223036', 'system': {'heating_control': None, 'orphans': []}, 'ufh_controllers': {}, 'stored_hotwater': None, 'zones': {'00': {'heating_type': 'radiator_valve', 'sensor': None, 'devices': ['04:231774', '04:231772', '04:231776']}, '01': {'heating_type': 'radiator_valve', 'sensor': '04:231770', 'devices': ['04:231770']}, '02': {'heating_type': 'radiator_valve', 'sensor': '04:155537', 'devices': ['04:155537', '04:155533']}, '03': {'heating_type': 'radiator_valve', 'sensor': '04:155551', 'devices': ['04:155551']}, '04': {'heating_type': 'radiator_valve', 'sensor': '04:155443', 'devices': ['04:155443']}, '05': {'heating_type': 'radiator_valve', 'sensor': '04:155445', 'devices': ['04:155445']}, '06': {'heating_type': 'radiator_valve', 'sensor': '04:155407', 'devices': ['04:155407']}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': 'radiator_valve', 'sensor': '04:050559', 'devices': ['04:050559']}, '09': {'heating_type': 'radiator_valve', 'sensor': '04:081849', 'devices': []}}}
2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Params = {'system': {'mode': {'system_mode': 'auto', 'until': None}, 'language': 'nl', 'heating_control': {}}, 'stored_hotwater': None, 'zones': {'00': {'name': 'Woonkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': False, 'openwindow_function': False, 'multiroom_mode': False}}, '01': {'name': 'Inkom', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '02': {'name': 'Speelkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '03': {'name': 'Bureau', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '04': {'name': 'Febe', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '05': {'name': 'Badkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '06': {'name': 'Margot', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '07': {'name': 'Dressing', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '08': {'name': 'Keuken', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '09': {'name': 'Slaapkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}}, 'mode': None, 'language': 'nl'}
2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Status = {'system': {}, 'devices': {'04:050559': {'temperature': 18.75, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 1.0, 'window_state': False}, '04:081849': {'temperature': 14.14, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.67, 'window_state': False}, '04:155403': {'temperature': 15.06, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155407': {'temperature': 13.85, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.69, 'window_state': False}, '04:155443': {'temperature': 14.16, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.83, 'window_state': False}, '04:155445': {'temperature': 18.45, 'setpoint': 20.0, 'battery_state': None, 'enabled': True, 'heat_demand': 1.0, 'window_state': False}, '04:155533': {'temperature': 14.73, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155537': {'temperature': 14.59, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155551': {'temperature': 15.7, 'setpoint': 12.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:231770': {'temperature': 15.71, 'setpoint': 15.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': False}, '04:231772': {'temperature': 28.39, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '04:231774': {'temperature': 28.55, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '04:231776': {'temperature': 30.07, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '10:040239': {'actuator_cycle': {'actuator_enabled': True, 'modulation_level': 1.0, 'actuator_countdown': 60, 'cycle_countdown': None}, 'actuator_state': {'actuator_enabled': True, 'modulation_level': 0.5, 'flame_active': True, 'flame_state': '0A'}, 'enabled': True, 'boiler_setpoint': None, 'modulation_level': 0.5, 'boiler_temp': 58.0, 'ch_pressure': 1.59765625, 'dhw_flow_rate': 71.66796875, 'dwh_temp': 71.66796875, 'rel_modulation_level': 0.0, 'return_cv_temp': 57.69921875}}, 'heat_demand': 1.0, 'heat_demands': {'FC': 1.0}, 'relay_demands': {'FC': 1.0}, 'fault_log': {0: ['0021-01-19T14:08:33', 'unknown_c0', 'sensor_error', 'sensor', '02', None], 1: ['0021-01-19T14:06:06', 'unknown_c0', 'sensor_error', 'sensor', '02', None]}, 'datetime': None, 'stored_hotwater': None, 'zones': {'00': {'setpoint': 21.0, 'temperature': 21.02, 'heat_demand': 0.44, 'open_window': None}, '01': {'setpoint': 15.0, 'temperature': 15.41, 'heat_demand': 0.47, 'open_window': None}, '02': {'setpoint': 12.0, 'temperature': 14.59, 'heat_demand': 0.0, 'open_window': None}, '03': {'setpoint': 12.0, 'temperature': 15.7, 'heat_demand': 0.0, 'open_window': None}, '04': {'setpoint': 15.0, 'temperature': 13.9, 'heat_demand': 0.83, 'open_window': None}, '05': {'setpoint': 20.0, 'temperature': 17.85, 'heat_demand': 1.0, 'open_window': None}, '06': {'setpoint': 15.0, 'temperature': 13.85, 'heat_demand': 0.69, 'open_window': None}, '07': {'setpoint': 12.0, 'temperature': 15.06, 'heat_demand': 0.0, 'open_window': None}, '08': {'setpoint': 21.0, 'temperature': 18.55, 'heat_demand': 1.0, 'open_window': None}, '09': {'setpoint': 15.0, 'temperature': 14.14, 'heat_demand': None, 'open_window': None}}}

Integration fails to load afrer upgrading to Home Assistant 2023.1.0

Upgraded to Home Assistant 2023.1.0 this morning and the integration fails to load. There are two distinct errors in the logs;

Both have the same error text;

Logger: homeassistant.setup
Source: setup.py:340
First occurred: 08:49:19 (4 occurrences)
Last logged: 08:49:29

Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'TEMP_CELSIUS' from 'homeassistant.components.sensor' (/usr/src/homeassistant/homeassistant/components/sensor/__init__.py)).
Unable to prepare setup for platform ramses_cc.climate: Platform not found (cannot import name 'TEMP_CELSIUS' from 'homeassistant.components.climate' (/usr/src/homeassistant/homeassistant/components/climate/__init__.py)).

new stable version 0.20.22j is broken

I've updated this morning to the new stable version 0.20.22j released. Unfortunately it is broken

Logger: homeassistant.setup
Source: setup.py:338 
First occurred: 9:59:07 AM (1 occurrences) 
Last logged: 9:59:07 AM

Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'UnitOfTime' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)).

Strange behaviour by OTB appliance (e.g. Remeha heatpump)

Description of setup:

Evohome controller, connected to Remeha Elga Ace heatpump with R8810A1018 (Opentherm module)
Firmware version: WiFi module: 02.00.17.00, Application module: 02.00.19.33

ramses_cc ver: 0.21.0

Home Assistant config:

ramses_cc:
  serial_port: 
    port_name: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
    baudrate: 57600  #  default: 115200
  packet_log: 
    file_name: packet.log
    rotate_backups: 30

Nanocul from this supplier: https://schlauhaus.biz/en/product/nanocul-868/
Firmware: 0.7.1

Problem

After setup of the nanocul and software, all the sensors and entities became visible in Home Assistant. However, the heatpump started showing strange behaviour. Even though there is a heat demand from the Evohome to the heatpump, and output/return watertemp are below set point, every 6-10 minutes the heatpump stops heating for about 2 minutes. After this, the heatpump turns back on. The display on the heatpump doesn't show anything abnormal or error codes.

As soon as I disabled the ramses_cc plugin in Home Assistant, the heatpump started operating normally again. This can be seen in the energy diagram as attached. There was constant heatdemand most of the time between 11.35 and 13.50, but the heatpump was switching on and off. The peak around 13.40 was caused by setting the Evohome to 25 degrees to force a very high setpoint, but here the heatpump also stopped way before the setpoint was reached.

I disabled the plugin at 13.50. The Evohome send heat demand between 13.50 - 14.15 and 14.40 - 15.08. Between these timestamps, there is clear correlation between heat demand and power usage. Between 14.56 and 15.08 there was heat demand, but the heatpump reached it's setpoint. Therefore only the circulation pump was active which causes the lower power usage.

Outdoor temperature is between 10-15 degrees celcius, so defreeze cycles are not relevant.

It seems like the nanocul is interfering the messages between the Evohome and heatpump (connected through R8810A1018) Could this be caused by active probing?

cannot import name 'UnitOfTime' from 'homeassistant.const'

I connected an Arduino with a CC1101 and evofw3 on the Raspberry on which I run home assistant (2022.12.4).
Since I just started I only configured it as follows:

ramses_cc: serial_port: /dev/ttyACM0 # or some other serial port name

Any help?

Nuaire Drimaster PIV feature enhancement wishlist

The Nuaire Drimaster PIV is supported by ramses_cc but provides limited functionality and in my setup, the sensor entities don't provide any data/change values. That said, Faking the wireless remote works brilliantly. The following commands are supported through faking;

Nuaire 4-way switch:

Fan normal
Fan boost (purge)
Heater auto
Heater off

I am suggesting some feature enhancement ideas for consideration, not all may be technically possible due to Nuaire's implementation. Unfortunately I am unable to help with coding but could help with the packet data collection and software testing!

Sensors:

Fan mode (Fan normal, Fan boost (purge), Heater auto, Heater off)
Fan speed status - speed 0 (low) through to 6 (high)
Heater status (on/off)
Filter status (clean/dirty)
Runtime hours

Commands:

Filter change reset
Fan speed change (0 through to 6)
Standby mode (speed 0 turns fan "off")

The Nuaire Remote Monitoring Device confirms that runtime hours and filter status is reported by the Drimaster.

set_zone_setpoint() takes 3 positional arguments but 4 were given

unable to set the setpoint of a zone

using version 0.5.16a

2021-03-07 13:43:33 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140328212481696] set_zone_setpoint() takes 3 positional arguments but 4 were given
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 544, in async_service_temperature_set
    await entity.async_set_temperature(**kwargs)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 404, in async_set_temperature
    await self.hass.async_add_executor_job(
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/evohome_cc/climate.py", line 243, in set_temperature
    self._evo_device.setpoint = setpoint
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 769, in setpoint
    cmd = Command.set_zone_setpoint(self._ctl.id, self.idx, value)
TypeError: set_zone_setpoint() takes 3 positional arguments but 4 were given

Vasco issue

Kindly ask for support with controlling Vasco D500 ventilation unit with RF (4 buttons) remote.
I successfully configured ramses_cc with faking. I see packets from original RF transmitter:

058 I --- 29:083043 32:024669 --:------ 22F1 003 000206
060 I --- 29:083043 32:024669 --:------ 22F1 003 000306
060 I --- 29:083043 32:024669 --:------ 22F1 003 000406

in configuration.yaml i got faking device:

known_list:
18:070952: {class: HGI}
29:083043: {class: REM, faked: true}
32:024669: {class: FAN, _note: D500}
29:073042:
class: REM
faked: True
commands:
low: ' I --- 29:073042 32:024669 --:------ 22F1 003 000206'
medium: ' I --- 29:073042 32:024669 --:------ 22F1 003 000306'
high: ' I --- 29:073042 32:024669 --:------ 22F1 003 000406'

and using the command:

service: remote.send_command
data:
command: max
target:
entity_id: remote.29_083043

i see packet beeing transmited that exactly match that what were sniffed:

000 I --- 29:083043 32:024669 --:------ 22F1 003 000406

but ventilation unit is not reacting on any command.
Could you please support, and advice what would be the potential root cause, and how it can be improved ?

Thanks!

Update ramses_cc for HVAC (e.g. Itho Daalderop) & integrate breaking changes

@tomkooij has been the source of a many recent improvements to the library, particularly the HVAC parsers. Thanks!

In addition, the latest master of ramses_rf has many other (albeit beneficial) changes, some deep within the codebase. And there is a significant bug in ramses_rf's to-do list, that will be included in this next release.

Unfortunately, there are breaking changes that I will find difficult to test/debug (i.e. I have no access to live HVAC systems via RF).

One example is:

{"setpoint_low": 19.5, "setpoint_high": 21.0}

... being changed to:

{"setpoint_bounds": [19.5, 21.0]}

The prudent action is to recruit selected users who have the right HVAC systems and involve them in this test/debug cycle, with a dev/test platform.

Specifically, their existing HA systems will not be used for this function; rather: they will have a second HA instance for test/debug. Ideally, they will have two USB dongles (at least one running evofw3), although it is likely that ser2net will be used instead.

Note: the second instance can still 'influence' with the first, as they'll share the same RF space.

First step, is to set up a development environment and clone the master branch of the:

ramses_rf,
ramses_cc repos

... and get ser2net working.

Once a dev/test environment is established, start HA and any report bugs; then update the repos and repeat the cycle.

home assistant complains about deprecated `device_state_attributes`

When starting the custom component, home assistant complains about deprecated device_state_attributes:

2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc] Schema = {}
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc] Devices = ['13:003246', '12:158468', '12:165258', '12:155287', '18:198161']
2021-12-10 16:49:48 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.evohome_cc
2021-12-10 16:49:48 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.evohome_cc
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (active) for 13:003246
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:158468
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:165258
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:155287
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Gateway (config), id=18:198161
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (relay_demand) for 13:003246
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:158468
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:165258
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:155287
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.13_003246_active (<class 'custom_components.evohome_cc.binary_sensor.EvoActuator'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.18_198161_config (<class 'custom_components.evohome_cc.binary_sensor.EvoGateway'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity sensor.13_003246_relay_demand (<class 'custom_components.evohome_cc.sensor.EvoRelayDemand'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:53 INFO (MainThread) [ramses_rf] ENGINE: Saving schema/state...

my manifest.json:

{
    "domain": "evohome_cc",
    "name": "RAMSES RF",
    "documentation": "https://github.com/zxdavb/evohome_cc",
    "requirements": [
      "ramses-rf==0.16.24",
      "pyserial-asyncio==0.5"
    ],
    "dependencies": [],
    "issue_tracker": "https://github.com/zxdavb/evohome_cc/issues",
    "codeowners": ["@zxdavb"],
    "version": "0.0.1"
  }

I'm running Home Assistant 2021.12.0b1:

System Health

version	core-2021.12.0b1
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.9.7
os_name	Linux
os_version	5.10.63-v8
arch	aarch64
timezone	Europe/London

Home Assistant Community Store

GitHub API	ok
Github API Calls Remaining	4820
Installed Version	1.18.0
Stage	running
Available Repositories	911
Installed Repositories	6

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 7.0
update_channel	beta
supervisor_version	supervisor-2021.12.1
docker_version	20.10.9
disk_total	116.5 GB
disk_used	3.9 GB
healthy	true
supported	true
board	rpi4-64
supervisor_api	ok
version_api	ok
installed_addons	Terminal & SSH (9.2.1), Studio Code Server (3.7.0), Log Viewer (0.12.1)

Lovelace

dashboards	3
resources	2
views	8
mode	storage

Getting "Failed to restart Home AssistantCore. string indices must be integers" due to config

Since I have added my new evohome_cc configuation to my configuation.yaml file I get a "Failed to restart Home AssistantCore. string indices must be integers" error when I try to restart core. Also when I do a "Check Configuration" it hangs for ever.

If I comment-out some of the evohome_cc configuation then all is good. This is the corresponding error in the logs:

File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 817, in validate_callable return schema(data) File "/usr/src/homeassistant/homeassistant/helpers/config_validation.py", line 797, in validator value = config[key] TypeError: string indices must be integers

Extract of my configuration.yaml file:

evohome_cc:
  serial_port:
    port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
    baudrate: 115200
    timeout: 0
    dsrdtr: false
    rtscts: false
    xonxoff: true
  restore_state: true
  config:
    enforce_allowlist: true
    max_zones: 0B
  schema:
    controller: 01:145378
  allow_list:
    - 01:145378
    - 04:005496
    - 04:002363
    - 04:023049
    - 04:096551
    - 13:198335
    - 18:209827
  packet_log:
    file_name: evohome_packet.log
    rotate_bytes: null
    rotate_backups: 7

If I comment-out the restore_state, config, schema, allow_list sections then all is good.
Then if I un-comment just the restore_state I get the issue (as an example).

Cannot set preset_mode to 'permanent': For permanent_override, setpoint/active cant be None

Hi,

I'm having some issues with setting the zones to 'permanent'. When there is nobody home I want to set the temperature to 10°C and preset mode to permanent. I cannot use the climate.turn_off function because several zones need to remain on.

It doesn't work from the UI (via the thermostat card) and doesn't work in automations.

Is this a known issue?

Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/ramses_cc/__init__.py:190
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 13:04:16 (17 occurrences)
Last logged: 15:49:57

[281472772568784] Invalid args: For temporary_override, setpoint/active cant be None
[281472711079536] Invalid args: For temporary_override, setpoint/active cant be None
[281473355301696] Error handling message: Unknown error (unknown_error)
[281472729897696] Invalid args: For temporary_override, setpoint/active cant be None
[281472647221536] Error handling message: Unknown error (unknown_error)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 202, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 207, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 513, in async_set_preset_mode
    await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/ramses_cc/climate_heat.py", line 348, in set_preset_mode
    self.svc_set_zone_mode(mode=ZoneMode.TEMPORARY)
  File "/config/custom_components/ramses_cc/climate_heat.py", line 390, in svc_set_zone_mode
    self._call_client_api(
  File "/config/custom_components/ramses_cc/__init__.py", line 190, in _call_client_api
    func(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/zones.py", line 748, in set_mode
    cmd = Command.set_zone_mode(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 27, in wrapper
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 193, in wrapper
    return _wrapper(fcn, cls, ctl_id, zone_idx, *args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 158, in _wrapper
    return fcn(cls, *args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 1083, in set_zone_mode
    mode = _normalise_mode(mode, setpoint, until, duration)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 223, in _normalise_mode
    raise ValueError(
ValueError: Invalid args: For temporary_override, setpoint/active cant be None

I'm using Ramses CC version 0.21.5

Any ideas?

Regards,
Jasper

When the preset mode is away, heat_demand is ignored

When the preset mode of the controller is set to away and a zone is showing heat demand because the temperature is lower then the setpoint, this isn't visible in the climate entity.

The state of that entity(zone) should not be "auto" but should be "head", as there is heat demand.
As for the state of the controller is also showing "heat_demand" > 0 , so the state should also reflect that
home-assistant.log

Spelling mistage in the description

Says "(WIP) HA custom component for ehohome_rf" instead of "(WIP) HA custom component for evohome_rf"

Unable to install latest beta version using HACS as a fresh install

When selecting a beta version, it can’t be installed. I believe this is caused by the rename of evohome_cc to ramses_cc. As you can see from the log below, HACS still tries to use the old name.

Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.hacs
Source: custom_components/hacs/websocket.py:286 
Integration: HACS (documentation, issues) 
First occurred: 07:53:10 (6 occurrences) 
Last logged: 09:36:45

No manifest.json file found 'custom_components/evohome_cc/manifest.json'

Cannot set system mode with period or duration

I am unable to use the set_system_mode service with any of the addition options the service defines with my evohome system.
If I provide duration or period, I receive an error and the service call fails.
Additionally I can only get it working for eco_boost, all the other modes do nothing.

HA version: 2023.10.3
Ramses_cc version: 0.21.40

I can use the standard climate.set_preset_mode service but this does not allow you to set non default periods/durations.

Using the native set_system_mode like so...
eg,

tap_action:
  action: call-service
  service: ramses_cc.set_system_mode
  data:
    mode: eco_boost
    duration: 120
    entity_id: climate.controller

This returns an error

If omit duration, it will set the system mode to eco for the rest of the day.
But other modes don't seems to be settable, for example:

action: call-service
  service: ramses_cc.set_system_mode
  data:
    mode: away
    period: 2
    entity_id: climate.controller

This does nothing, no error, system mode remains in current mode

OTB Water Temps need rounding

Round temperatures reported by the OTB to 2 decimal places.

Migrate from 0.19.2 to 0.20.22g

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.

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. Could you confirm please @zxdavb?

unable to combine mode: temporary_override and until in evohome_cc.set_zone_mode

Using the service call evohome_cc.set_zone_mode I can't combine until with mode 'temporary_override' -> returns an error:

Kan service evohome_cc/set_zone_mode niet aanroepen value must be one of ['follow_schedule'] for dictionary value @ data['mode']

service: evohome_cc.set_zone_mode
data:
  entity_id: climate.bureau
  mode: temporary_override
  setpoint: 5
  until: '22:00:00'

Error: Inconsistent schema: ... cant change parent

I managed to fully add evohome_cc to HA, however when I set 'restore_cache' to 'true', it gives an error in HA. Leaving 'restore_cache' to 'false' works fine, however load times are long.

Any ideas how to fix this?
I would like to use the cache option to improve performance

Version Key in manifest

From log:
2021-03-23 20:01:53 WARNING (MainThread) [homeassistant.loader] No 'version' key in the manifest file for custom integration 'evohome_cc'. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of 'evohome_cc'

Failed to call service climate/set_preset_mode

Running: 0.5.16a

When trying to change the Preset for a zone in HA, the below is shown and no change is performed:

Failed to call service climate/set_preset_mode set_zone_mode() takes 3 positional arguments but 6 were given.

Rolling back to 0.5.10 resolves the issue.

hvac_mode remains off after window open detection has timed out.

I have noticed that it could happen when an open window was detected, and after X min the state returns to normal but the
entity isn't fully updated:

If I would restart HA it is fixed, so there must be small glitch some where.

Here are the logs:

Logs.zip

I'm thinking it's related to https://github.com/zxdavb/evohome_cc/blob/b119afafc5e5ab33fa29a903cec39d80d71010d8/custom_components/evohome_cc/climate.py#L151

ramses_rf.send_command fails with TypeError: must be exactly one command to learn

-- EDIT BEGINS --
The solution for v0.20.x and v0.21.x is to use: ramses_rf.send_command instead.
-- EDIT ENDS --

Hi,
Have

Nuaire Drimaster PIV
Nuaire DRI-ECO-4S (4-way switch)
nanoCul 868 Mhz dongle with latest evofw3 based on P chip ( not u4)
Home Assistant Supervised v11.1 Fresh install

The packet flew in and out, so nanocul with HA is working.
Tried impersonate and faking, etc., seven days 12+ hours reading miles-long topics but no signs that anything is working.

This is what shows in HA Logs when using all buttons on the remote and PIV unit's response

This is my HA nanocull config

When trying to use commands via services like below
Service call

Debug output

Tried to send a packet ( boost)

Debug

and the outcome is - nothing happens

Some errors time after time appears, I have no idea what is about

Lovelace some strange things as well

I have 0 idea how people managed to make it work with Nuaire Drimaster and at least fake a remote.
Tried anything, 0 success., I assume that ramses_cc has bugs with the newest home assistant

Set preset mode to none

2021-03-07 13:48:38 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140170447772976] isinstance() arg 2 must be a type or tuple of types
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 446, in async_set_preset_mode
    await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/evohome_cc/climate.py", line 255, in set_preset_mode
    self._evo_device.reset_mode()
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 824, in reset_mode
    return self.set_mode(mode="follow_schedule")
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 815, in set_mode
    cmd = Command.set_zone_mode(self._ctl.id, self.idx, mode, setpoint, until)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/command.py", line 512, in set_zone_mode
    elif not isinstance(setpoint, (None, float)):
TypeError: isinstance() arg 2 must be a type or tuple of types

Orcon Fan: 10D0 filter change in logs but no attribute/entity in HA

I have on orcon fan (32:134446) in Home Assistant, all 31DA messages are present as entities.
However "filter change" (days_remaining) from 10D0 message class does not show up. The entity simply does not exist. When I set restore_cache to false, no change.

I see the 10D0 messages in packet.log. It is actively polled by ramses_cc:

Yesterday

2023-03-24T16:21:48.729835 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-03-24T16:21:48.747136 074 RP --- 32:134446 18:203011 --:------ 10D0 006 0008B4090000

Today

2023-03-25T07:29:50.228353 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-03-25T07:29:50.258392 073 RP --- 32:134446 18:203011 --:------ 10D0 006 0007B4080000

The latter is succesfully parsed by ramses_rf:

07:29:50.258 || HVC:134446 | HGI:203011 | RP | filter_change    |      || {'days_remaining': 7, 'days_lifetime': 180, 'percent_remaining': 0.04}

days_remaining seems to be the correct entity: https://github.com/zxdavb/ramses_rf/blob/master/ramses_rf/device/hvac.py#L198

I have no clue why the entity is not in HA. And no clue how to debug this either.

configuration.yaml:

ramses_cc:
  serial_port: /dev/ttyACM0 # SSM-D2
  #serial_port: /dev/ttyUSB.HIG80
  #serial_port: /dev/ttyUSB.nanocul
  orphans_hvac: [32:134446, 37:123456, 32:132403, 37:005302, 37:005608, 37:171685, 29:162275, 18:203011, 02:250708]
  restore_cache: true

  packet_log:
    file_name: packet.log
    rotate_backups: 100

  known_list:
    32:134446: {class: FAN}               # WTW HRC400
    32:132403: {class: HVC}               # zone valve unit
    37:005302: {class: CO2}               # CO2 woonkamer
    37:005608: {class: CO2}               # CO2 slaapkamer
    37:171685: {class: DIS}               # RF15 display
    02:250704: {class: UFC}               # autotemp master beneden
    02:250708: {class: UFC}               # autotemp master BUREN
    02:250984: {class: UFC}               # autotemp slave boven
    21:033160: {class: THM}               # Itho spider livingroom
    21:043468: {class: THM}
    21:043352: {class: THM}
    21:043436: {class: THM}
    21:043273: {class: THM}
    18:203011:
      class: HGI
      _note: SSM-D2
    29:162275:  # RF15 switch bathroom
      class: REM
      faked: True  # real RF15 but not operational, fake it...
      _note: Orcon 15RF
      commands:
        request31DA:  'RQ --- 29:162275 32:134446 --:------ 31DA 001 00'
        request10D0:  'RQ --- 29:162275 32:134446 --:------ 10D0 001 00' # filter
        low:          ' I --- 29:162275 32:134446 --:------ 22F1 003 000107'
        high:         ' I --- 29:162275 32:134446 --:------ 22F1 003 000307'
        away:         ' I --- 29:162275 32:134446 --:------ 22F1 003 000007'
        low:          ' I --- 29:162275 32:134446 --:------ 22F1 003 000107'
        medium:       ' I --- 29:162275 32:134446 --:------ 22F1 003 000207'
        high:         ' I --- 29:162275 32:134446 --:------ 22F1 003 000307'
        auto:         ' I --- 29:162275 32:134446 --:------ 22F1 003 000407'
        auto2:        ' I --- 29:162275 32:134446 --:------ 22F1 003 000507'
        boost:        ' I --- 29:162275 32:134446 --:------ 22F1 003 000607'
        disable:      ' I --- 29:162275 32:134446 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 29:162275 32:134446 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 29:162275 32:134446 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 29:162275 32:134446 --:------ 22F7 003 00FFEF'
        high_60:      ' I --- 29:162275 32:134446 --:------ 22F3 007 00123C03040404'
        high_30:      ' I --- 29:162275 32:134446 --:------ 22F3 007 00121E03040404'
        high_15:      ' I --- 29:162275 32:134446 --:------ 22F3 007 00120F03040404'
        reset_filter: ' W --- 29:162275 32:134446 --:------ 10D0 002 00FF'
    37:123456:
      # let op deze fake remote is niet meer gepaired!!!
      class: REM
      faked: True
      commands:
        away:         ' I --- 37:123456 32:134446 --:------ 22F1 003 000007'
        low:          ' I --- 37:123456 32:134446 --:------ 22F1 003 000107'
        medium:       ' I --- 37:123456 32:134446 --:------ 22F1 003 000207'
        high:         ' I --- 37:123456 32:134446 --:------ 22F1 003 000307'
        auto:         ' I --- 37:123456 32:134446 --:------ 22F1 003 000407'
        auto2:        ' I --- 37:123456 32:134446 --:------ 22F1 003 000507'
        boost:        ' I --- 37:123456 32:134446 --:------ 22F1 003 000607'
        disable:      ' I --- 37:123456 32:134446 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 37:123456 32:134446 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 37:123456 32:134446 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 37:123456 32:134446 --:------ 22F7 003 00FFEF'
        reset_filter: ' W --- 37:123456 32:134446 --:------ 10D0 002 00FF'
      _note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)

  scan_interval: 180

  block_list:
    18:111262: {}  # identified as HGI. Neighbours?

  advanced_features:
    message_events: None
    send_packet: true

  ramses_rf:
    enforce_known_list: true
    #enable_eavesdrop: false

OTB Relative Modulation Level

The relative_modulation_level sensor appears to be reporting its percentage incorrectly. Looking at the values reported the % appears to be incorrectly multiplied by 1000.

Examples include: 4,900%, 5,300% etc...

Thanks

KeyError: 'client_state'

Logger: homeassistant.setup
Source: custom_components/evohome_cc/init.py:188
First occurred: 7:50:34 (1 occurrences)
Last logged: 7:50:34

Error during setup of component evohome_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component
result = await task
File "/config/custom_components/evohome_cc/init.py", line 100, in async_setup
await broker.async_restore_client_state()
File "/config/custom_components/evohome_cc/init.py", line 188, in async_restore_client_state
await self.client._set_state(**app_storage["client_state"])
KeyError: 'client_state'

Missing OTB sensors

With evohome_cc I have the sensors below:

boiler_setpoint
modulation_level

With Domoticz I also had these OTB sensors:

boiler_water_temp
ch_water_pressure
dhw_flow_rate
dhw_temp
return_cv_temp

AttributeError: 'Evohome' object has no attribute 'devices'

When using evohome_rf 0.5.0, I get the following error at startup:

05': {'heating_type': 'radiator_valve', 'sensor': '04:155445', 'devices': ['04:155445']}, '06': {'heating_type': 'radiator_valve', 'sensor': '04:155407', 'devices': ['04:155407']}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': 'radiator_valve', 'sensor': '04:050559', 'devices': ['04:050559']}, '09': {'heating_type': 'radiator_valve', 'sensor': '04:081849', 'devices': []}}}
2021-01-24 18:06:36 ERROR (MainThread) [custom_components.evohome_cc.evohome_rf] handle_exception(): Caught: Task exception was never retrieved
2021-01-24 18:06:36 ERROR (MainThread) [asyncio] Unhandled error in exception handler
context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'Evohome' object has no attribute 'devices'"), 'future': <Task finished name='Task-11943' coro=<EvoBroker.update() done, defined at /config/custom_components/evohome_cc/__init__.py:167> exception=AttributeError("'Evohome' object has no attribute 'devices'")>}
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1744, in call_exception_handler
    self._exception_handler(self, context)
  File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 118, in handle_exception
    raise exc
  File "/config/custom_components/evohome_cc/__init__.py", line 192, in update
    if new_sensors(self):
  File "/config/custom_components/evohome_cc/__init__.py", line 76, in new_sensors
    for d in broker.client.evo.devices
AttributeError: 'Evohome' object has no attribute 'devices'

State unknow when heat demand for zone is 0

Version evohome_rf: 0.5.0

When the heat_demand = 0, the state of climate is unknown. In the previous version the state was heat and the attribute was: hvac_action: idle

hvac_modes:
  - heat
  - 'off'
min_temp: 5
max_temp: 35
current_temperature: 19.2
temperature: 16
controller: '01:223036'
heating_type: radiator_valve
zone_config:
  min_temp: 5
  max_temp: 35
  local_override: true
  openwindow_function: true
  multiroom_mode: false
heat_demand: 0
friendly_name: Bureau
supported_features: 1

2021-01-25 19:34:55 DEBUG (MainThread) [custom_components.evohome_cc] Params = {'system': {'mode': None, 'language': None, 'heating_control': {}}, 'stored_hotwater': None, 'zones': {'00': {'name': 'Woonkamer', 'mode': {'zone_idx': '00', 'mode': 'follow_schedule', 'setpoint': 22.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': False, 'openwindow_function': False, 'multiroom_mode': False}}, '01': {'name': 'Inkom', 'mode': {'zone_idx': '01', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '02': {'name': 'Speelkamer', 'mode': {'zone_idx': '02', 'mode': 'temporary_override', 'setpoint': 18.0, 'until': '2021-01-25 20:30:00'}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '03': {'name': 'Bureau', 'mode': {'zone_idx': '03', 'mode': 'temporary_override', 'setpoint': 19.5, 'until': '2021-01-25 20:30:00'}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '04': {'name': 'Febe', 'mode': {'zone_idx': '04', 'mode': 'follow_schedule', 'setpoint': 12.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '05': {'name': 'Badkamer', 'mode': {'zone_idx': '05', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '06': {'name': 'Margot', 'mode': {'zone_idx': '06', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '07': {'name': 'Dressing', 'mode': {'zone_idx': '07', 'mode': 'follow_schedule', 'setpoint': 15.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '08': {'name': 'Keuken', 'mode': {'zone_idx': '08', 'mode': 'follow_schedule', 'setpoint': 21.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '09': {'name': 'Slaapkamer', 'mode': {'zone_idx': '09', 'mode': 'follow_schedule', 'setpoint': 12.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}}, 'mode': None, 'language': None}
2021-01-25 19:34:55 DEBUG (MainThread) [custom_components.evohome_cc] Status = {'system': {}, 'devices': {'04:050559': {'temperature': 20.6, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.71, 'window_state': None}, '04:081849': {'temperature': 18.38, 'setpoint': 12.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155403': {'temperature': None, 'setpoint': 15.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155407': {'temperature': 17.32, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.58, 'window_state': None}, '04:155443': {'temperature': 18.14, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155445': {'temperature': 18.03, 'setpoint': 18.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.27, 'window_state': False}, '04:155533': {'temperature': 17.67, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155537': {'temperature': 17.3, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155551': {'temperature': None, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:231770': {'temperature': 18.15, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:231772': {'temperature': 26.03, 'setpoint': 22.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': False}, '04:231774': {'temperature': 25.0, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': None}, '04:231776': {'temperature': 27.12, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': None}, '10:040239': {'actuator_cycle': None, 'actuator_state': None, 'enabled': None, 'boiler_setpoint': None, 'modulation_level': 0.0, 'boiler_temp': 32.59765625, 'ch_pressure': 1.59765625, 'dhw_flow_rate': 71.66796875, 'dwh_temp': 71.66796875, 'rel_modulation_level': 0.0, 'return_cv_temp': 32.3984375}}, 'heat_demand': None, 'heat_demands': None, 'relay_demands': None, 'fault_log': {0: ['0021-01-19T14:08:33', 'unknown_c0', 'sensor_error', 'sensor', '02', None], 1: ['0021-01-19T14:06:06', 'unknown_c0', 'sensor_error', 'sensor', '02', None]}, 'datetime': None, 'stored_hotwater': None, 'zones': {'00': {'setpoint': 22.0, 'temperature': 21.69, 'heat_demand': 0.47, 'open_window': None}, '01': {'setpoint': 18.0, 'temperature': 18.15, 'heat_demand': 0.0, 'open_window': None}, '02': {'setpoint': 15.0, 'temperature': 17.3, 'heat_demand': 0.0, 'open_window': None}, '03': {'setpoint': 16.0, 'temperature': 19.21, 'heat_demand': 0.0, 'open_window': None}, '04': {'setpoint': 12.0, 'temperature': 18.14, 'heat_demand': 0.0, 'open_window': None}, '05': {'setpoint': 18.0, 'temperature': 18.03, 'heat_demand': 0.27, 'open_window': None}, '06': {'setpoint': 18.0, 'temperature': 17.32, 'heat_demand': 0.58, 'open_window': None}, '07': {'setpoint': 15.0, 'temperature': 16.21, 'heat_demand': 0.0, 'open_window': None}, '08': {'setpoint': 21.0, 'temperature': 20.6, 'heat_demand': 0.71, 'open_window': None}, '09': {'setpoint': 12.0, 'temperature': 18.38, 'heat_demand': None, 'open_window': None}}}

`climate.set_preset_mode` with `preset_mode: none` sets target temp to 35C

Executing the climate.set_preset_mode service call sets the target temperature to 35 degrees.

service: climate.set_preset_mode
data:
  preset_mode: None
  entity_id: climate.speelkamer

This is on release 0.22.3. I don’t know when it started to happen, just notice it.

Adding cooling support for evohome

Hi, i think i have a new feature request. I have an evohome setup with a heatpump that supports heating and cooling. Basically my heatpump is controlled by 2 BRD91T1004. One for the normal demand, and one for sending that demand to the heating input or to the cooling input. From my evohome, i can set the system modus in cooling or heating. this is the support article of my setup.

When i switch from heat to cold, i see the following errors.

[ramses_rf.protocol.message]  I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message]  I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message]  I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message]  I --- 01:172368 13:040439 --:------ 1100 008 FC042814007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC042814007FFF00
[ramses_rf.protocol.message]  I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message]  I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00

Package log of today.
packet.log

'01:172368': {}

config: 
enforce_known_list: false

known_list: 
- '01:172368':
    class: controller
- '04:197921':
    class: radiator_valve
- '04:197927':
    class: radiator_valve
- '04:197901':
    class: radiator_valve
- '34:239834':
    class: thermostat
- '13:075359':
    class: electrical_relay
- '12:235249':
    class: thermostat
- '13:040441':
    class: electrical_relay
- '18:009876':
    class: gateway_interface
- '13:040439':
    class: electrical_relay

block_list: 
other_list: 
_is_evofw3: null
device_class: problem
friendly_name: 18:009876 status

My feature request will be, can we make it support cooling?

Heating BDR sensor not consistently updating

Looking at the sensor for my heating relay (binary_sensor.13_197705_active), it does not seem to be getting updated consistently, and sometimes not at all.

Having observed the packets, I expected this (filtered) set of packets would have been the ones that updated the sensor, but that does not seem to be the case. Are you using something else?

2021-11-16 13:00:14 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:00:39 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 1.0, '_flags_0': 'FF'}
2021-11-16 13:02:15 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:02:19 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:10:43 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 1.0, '_flags_0': 'FF'}
2021-11-16 13:12:19 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:12:24 INFO (MainThread) [ramses_rf.message] || BDR:197705 |            |  I | actuator_state   |      || {'modulation_level': 0.0, '_flags_0': 'FF'}

Add additional attributes to actuator binary sensor

Can the attributes listed below be add to the actuator binary sensor?

OTB:040239         | CTL:223036         | RP | actuator_state   | 00001... || {'actuator_enabled': False, 'modulation_level': 0.0, '_unknown_0': '10', 'flame_active': False, 'flame_state': '00', '_unknown_1': '00FF020A64'}

With:

'10:040239': {'actuator_cycle': None, 'actuator_state': None, 'boiler_setpoint': None, 'modulation_level': 0.0, 'opentherm_status': {'boiler_temp': None, 'ch_pressure': None, 'dhw_flow_rate': None, 'dhw_temp': None, 'rel_modulation_level': None, 'return_cv_temp': None}}}

Issue with window sensors - always showing unavailable in recent releases:

I was chatting with @phdelodder about a few things, he also noted the issue/fix with window sensors:

For the window open state you need to change line 23 of
https://github.com/zxdavb/evohome_cc/blob/93622024ae852f233d75ec8b1a774e76de1fb1a7/custom_components/evohome_cc/const.py and the reason you can see zxdavb/ramses_rf@2e7e138 on file evohome_rf/devices.py at line 1018 and line 1026

Depends whether you want to fix it in evohome_cc, or evohome_rf? :)