zxdavb / ramses_rf Goto Github PK

An interface for the RAMSES RF protocol, as used by Honeywell-compatible HVAC & CH/DHW systems.

License: MIT License

Python 99.85% Shell 0.15%

evohome hgi80 evohome-rf chronotherm sundial hometronics ramses ramses-rf itho resideo

ramses_rf's Introduction

Overview

ramses_rf is a client library/CLI utility used to interface with some Honeywell-compatible HVAC & CH/DHW systems that use 868MHz RF, such as:

(Heat) evohome, Sundial, Hometronic, Chronotherm
(HVAC) Itho, Orcon, Nuaire

It requires a USB-to-RF device, either a Honeywell HGI80 (somewhat rare, expensive) or something running the evofw3 firmware, such as the one from here.

It does three things:

decodes RAMSES II-compatible packets and converts them into useful JSON
builds a picture (schema, config & state) of evohome-compatible CH/DHW systems - either passively (by eavesdropping), or actively (probing)
allows you to send commands to CH/DHW and HVAC systems, or monitor for state changes
allows you to emulate some hardware devices

For CH/DHW, the simplest way to know if it will work with your system is to identify the box connected to your boiler/HVAC appliance as one of:

R8810A: OpenTherm Bridge
BDR91A: Wireless Relay (also BDR91T)
HC60NG: Wireless Relay (older hardware)

Other systems may well work, such as some Itho Dallderop HVAC systems, use this protocol, YMMV.

It includes a CLI and can be used as a standalone tool, but also is used as a client library by:

ramses_cc, a Home Assistant integration
evohome-Listener, an MQTT gateway

Installation

git clone https://github.com/zxdavb/ramses_rf
cd ramses_rf
pip install -r requirements.txt

The CLI is called client.py:

python client.py monitor /dev/ttyUSB0 -o packet.log

ramses_rf's People

Contributors

Stargazers

Watchers

Forkers

gitter-badger skundrik martynwendon notbobthebuilder temizel pcr20 janvkem tomkooij dennisvbussel bheading double-dagger pdbayes bennert trvrnrth

ramses_rf's Issues

Orcon ventilation: 31D9 payload not recognized, wrong fan modes

I'm looking into using this (awesome!) software with my Orcon HRC-350 (sold to me under the brand Ventiline) through an Arduino running evofw3, and am encountering a couple of issues.

The first is a payload that isn't recognized. When I set the ventilation fan speed to respectively away, 1, 2, 3, or auto, encoded as fan modes 0 to 4, my unit responds with a 31D9 message where the payload is simply either 00000000, 00000100, 00000200, 00000300 or 00000400. That doesn't match the regex in ramses.py, which seems to expect much more data:

23:13:48.670 || HVC:150155 |  32:134044 |  I | switch_speed     |      || {'rate': 0.0, '_step_idx': 0, '_step_max': 4, 'fan_mode': 'standby'}
23:13:48.689  I --- 32:134044 --:------ 32:134044 31D9 004 00000000 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}((00|FE)(00|20){12}(00|08))?$': 00000000

23:04:28.570 || HVC:150155 | HVC:134044 |  I | switch_speed     |      || {'rate': 0.25, '_step_idx': 1, '_step_max': 4, 'fan_mode': 'auto'}
23:04:28.598  I --- 32:134044 --:------ 32:134044 31D9 004 00000100 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}((00|FE)(00|20){12}(00|08))?$': 00000100

23:04:34.219 || HVC:150155 | HVC:134044 |  I | switch_speed     |      || {'rate': 0.5, '_step_idx': 2, '_step_max': 4, 'fan_mode': 'low'}
23:04:34.251  I --- 32:134044 --:------ 32:134044 31D9 004 00000200 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}((00|FE)(00|20){12}(00|08))?$': 00000200

23:04:38.197 || HVC:150155 | HVC:134044 |  I | switch_speed     |      || {'rate': 0.75, '_step_idx': 3, '_step_max': 4, 'fan_mode': 'medium'}
23:04:38.223  I --- 32:134044 --:------ 32:134044 31D9 004 00000300 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}((00|FE)(00|20){12}(00|08))?$': 00000300

23:13:51.928 || HVC:150155 |  32:134044 |  I | switch_speed     |      || {'rate': 1.0, '_step_idx': 4, '_step_max': 4, 'fan_mode': 'high'}
23:13:51.956  I --- 32:134044 --:------ 32:134044 31D9 004 00000400 < Corrupt payload: Payload doesn't match '^(00|01|21)[0-9A-F]{4}((00|FE)(00|20){12}(00|08))?$': 00000400

This also shows that the fan modes are not mapped correctly: 0 is away, 1-3 match fan speed 1 to 3, and 4 should be auto (fan speed determined by air humidity).

The much more complicated 31DA packets are fully recognized though 🙂 The rendering in the CLI is cut off though (maybe it could drop fields that are known to be bogus for this model?):

23:13:55.251 || HVC:134044 |            |  I | vent_31da        |      || {'exhaust_fan_speed': 0.15, 'remaining_time': 0.0, 'co2_level': None, 'indoor_humidity': 0.51, 'air_quality': None, 'air_quality_b

Finally, I also encountered the following packet with a prompt to file an issue:

23:13:59.371 RP --- 32:134044 18:201242 --:------ 10E0 038 000001C87D140D67FEFFFFFFFFFF170C07E3564D442D3135524D533634000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:134044 (device type 32 not known to have signature: 0001C87D140D67FEFF)

Let me know if you need additional information.

A few things noticed ....

Apologies if this is the wrong "format" for reporting issues, but I figured as I'd spotted a few random things it best to create one post rather than many,

So I'm running evohome_rf 0.6.6 - mainly in preparation for playing with https://github.com/smar000/evohome-Listener/blob/gw_evohome_rf/

My system consists of the evo controller ATC928, evo gateway RFG100, 10 HR92 TRVs, 9 DTS92 room thermostats and a BDR91. Combi boiler, 10 zones each consisting of HR92 and DTS92 except for the hall zone, where the ATC928 is sited and used as the thermostat for that zone. I also have an HGI80 which is currently working under Domoticz, using a really old integration that IIRC is entirely passive in nature.

All been in and working for many years, to the best of my knowledge all bound correctly i.e. each room thermostat (or the ATC928) can be adjusted and the corresponding TRV will actuate.

I left evohome_rf running on a spare HGI80 for an hour or so, the output is attached as is the packet.log

The config file wiki entry mentions the schema as having "heating_control" but the output from client.py contains "heating_relay". Perhaps they are synonymous, but thought it worth mentioning.

Schema[01:073322 (evohome)] = {
"controller": "01:073322",
"system": {
"heating_relay": "13:002386"
},

I ran "python client.py -c config.json monitor" with a very simple first config.json :

> {
>     "config": {
>         "disable_sending": null,
>         "disable_discovery": false,
>         "enforce_allowlist": null,
>         "enforce_blocklist": null,
>         "evofw_flag": null,
>         "max_zones": 12,
>         "packet_log": "packet.log",
>         "reduce_processing": 0,
>         "serial_port": "/dev/ttyUSB0",
>         "use_names": null,
>         "use_schema": true
>     },
>     "schema": {
>         "controller": "01:073322",
>         "system": {
>             "heating_control": "13:002386"
>         }
>     }
> }

This resulted in:

Usage: client.py listen [OPTIONS] SERIAL_PORT
Try 'client.py listen -h' for help.

Error: Missing argument 'SERIAL_PORT'.

No drama, but presume the serial_port option should be read here.

Similarly, I had "packet_log" in the config.json set, but no packet log was created during the next run, so I ran it again a little later with "-o packet.log" appended.

I seem to get many errors like so:

> 14:44:21.740 || CTL:073322 | HGI:002179 | RP | zone_mode        | 08070... || {'zone_idx': '08', 'mode': 'follow_schedule', 'setpoint': 18.0}
> 14:44:22.724 || HGI:002179 | CTL:073322 | RQ | zone_mode        | 09       || {'zone_idx': '09'}
> 14:44:22.740 || CTL:073322 | HGI:002179 | RP | zone_mode        | 09070... || {'zone_idx': '09', 'mode': 'follow_schedule', 'setpoint': 18.0}
> 14:44:23.725 || HGI:002179 | CTL:073322 | RQ | zone_mode        | 0A       || {'zone_idx': '0A'}
> 14:44:23.740 || CTL:073322 | HGI:002179 | RP | zone_mode        | 0A7FF... || {'zone_idx': '0A', 'mode': 'follow_schedule', 'setpoint': None}
> 14:44:24.740 || CTL:073322 | HGI:002179 | RP | zone_mode        | 0B7FF... || {'zone_idx': '0B', 'mode': 'follow_schedule', 'setpoint': None}
> 2021-03-16T14:44:25.725524 045 RQ --- 18:002179 01:073322 --:------ 2349 001 0C < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 325, in wrapper
>     result = _idx(payload[:2], msg)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0C' exceeds max zone index
> 2021-03-16T14:44:25.742829 045 RP --- 01:073322 18:002179 --:------ 2349 007 0C7FFF02FFFFFF < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 292, in wrapper
>     result = func(*args, **kwargs)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 1405, in parser_2349
>     **_idx(payload[:2], msg),
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0C' exceeds max zone index
> 2021-03-16T14:44:27.725678 045 RQ --- 18:002179 01:073322 --:------ 2349 001 0E < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 325, in wrapper
>     result = _idx(payload[:2], msg)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0E' exceeds max zone index
> 2021-03-16T14:44:27.741794 045 RP --- 01:073322 18:002179 --:------ 2349 007 0E7FFF02FFFFFF < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 292, in wrapper
>     result = func(*args, **kwargs)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 1405, in parser_2349
>     **_idx(payload[:2], msg),
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0E' exceeds max zone index
> 2021-03-16T14:44:28.725868 045 RQ --- 18:002179 01:073322 --:------ 2349 001 0F < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 325, in wrapper
>     result = _idx(payload[:2], msg)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0F' exceeds max zone index
> 2021-03-16T14:44:28.741749 045 RP --- 01:073322 18:002179 --:------ 2349 007 0F7FFF02FFFFFF < Validation error 
> Traceback (most recent call last):
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/message.py", line 324, in is_valid
>     self._payload = payload_parser(self.raw_payload, self)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 292, in wrapper
>     result = func(*args, **kwargs)
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 1405, in parser_2349
>     **_idx(payload[:2], msg),
>   File "/usr/src/evohome_rf/evohome_rf/evohome_rf/parsers.py", line 163, in _idx
>     assert (
> AssertionError: '0F' exceeds max zone index

Not sure if that's a bad / invalid packet, or is it simply because max_zones in the config.json is set at 12 .... although I only have 10 zones?

There seems to be quite a few orphans on the "gateway". Assuming that this is the RFG100, I'm not sure what the devices are as I don't believe the RFG100 is something you can impact setup wise? Also I see there's a device type "63" which I see in const.py is a "special" NULL device?
The bedroom 2 zone is missing a TRV, it's listed as orphan "04:139374". It's definitely there :-) It actuates correctly when adjusting that rooms thermostat so I assume that it's bound correctly!
Any idea what device type "30" is? I couldn't see it in the const,py but it's convinced that I have one!
The hall zone is missing the sensor, this should be the ATC928 evohome controller itself. I believe that it's correctly bound as it does cause the hall TRV to actuate when the setpoint is adjusted, I think I read somewhere that it's not possible to discover the sensor for a zone where the evohome controller itself is the sensor, but that reference eludes me now ..... there's a lot of info across github and the HA forum!

Should the discovery be accurate? I can obviously create a schema that suits the system how I believe it is is configured. But equally so, I did set this system up nearly 6 years ago, so it could be wrong ... although all evidence points that it is working correctly.

packet.log
output.txt

0.30.0: 3EF1 007 0000AA00A63FF9 < AssertionError(byte 1: 00AA)

11:13:48.056 RP --- 13:107116 18:201230 --:------ 3EF1 007 0000AA00A63FF9 < AssertionError(byte 1: 00AA)
Traceback (most recent call last):
  File "/home/supervisor/Scrivania/ramses_rf-0.22.40 mod/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/home/supervisor/Scrivania/ramses_rf-0.22.40 mod/ramses_rf/protocol/parsers.py", line 141, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/home/supervisor/Scrivania/ramses_rf-0.22.40 mod/ramses_rf/protocol/parsers.py", line 2582, in parser_3ef1
    assert payload[2:6] == "7FFF", f"byte 1: {payload[2:6]}"
AssertionError: byte 1: 00AA

Running as per README on windows fails

Windows 10, Python 3.8, NanoCUL with latest evofw3

running the install as per README.md

git clone https://github.com/zxdavb/evohome_rf
cd evohome_rf
pip install -r requirements.txt

and then the client

python client.py monitor COM4

produces the follow error output

config {'schema': {}, 'allowlist': {}, 'blocklist': {}, 'evofw_flag': None, 'disable_discovery': True, 'use_schema': True, 'enforce_allowlist': False, 'disable_sending': False, 'max_zones': 12, 'packet_log': 'packet.log', 'enforce_blocklist': True, 'reduce_processing': 0, 'debug_mode': 0, 'serial_port': 'COM4', 'execute_cmd': None, 'poll_devices': [], 'probe_devices': []}
Starting evohome_rf...
23:48:50.371 Starting evohome_rf, **config = {'schema': {}, 'allowlist': {}, 'blocklist': {}, 'evofw_flag': None, 'disable_discovery': True, 'use_schema': True, 'enforce_allowlist': False, 'disable_sending': False, 'max_zones': 12, 'packet_log': 'packet.log', 'enforce_blocklist': True, 'reduce_processing': 0, 'debug_mode': 0, 'execute_cmd': None, 'poll_devices': [], 'probe_devices': []}
Traceback (most recent call last):
  File "client.py", line 173, in <module>
    cli()
 File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\core.py", line 782, in main
    rv = self.invoke(ctx)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\click\decorators.py", line 33, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "client.py", line 85, in monitor
    debug_wrapper(**obj, **kwargs)
  File "client.py", line 121, in debug_wrapper
    asyncio.run(main(serial_port, **config))
  File "[...shortened python 3.8 path...]\lib\asyncio\runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "[...shortened python 3.8 path...]\lib\asyncio\base_events.py", line 616, in run_until_complete
    return future.result()
  File "client.py", line 136, in main
    gwy = Gateway(serial_port, loop=loop, **config)
  File "C:\Users\Jonathan\source\repos\evohome_rf\evohome_rf\__init__.py", line 131, in __init__
    load_schema(self, self._schema) if self.config["use_schema"] else {}
  File "C:\Users\Jonathan\source\repos\evohome_rf\evohome_rf\schema.py", line 232, in load_schema
    schema = SYSTEM_SCHEMA(schema)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\voluptuous\schema_builder.py", line 272, in __call__
    return self._compiled([], data)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\voluptuous\schema_builder.py", line 594, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "[...shortened python 3.8 path...]\LocalCache\local-packages\Python38\site-packages\voluptuous\schema_builder.py", line 432, in validate_mapping
    raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: required key not provided @ data['controller']```

Invalid code for 32:161205 (FAN) to Rx/Tx: 22E0

In the home-assistant.log:

2023-09-26 20:36:31.637 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22F4 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22F4

I have a lot of issues with the SSM-D2 from Peter Price. Maybe this is the cause of it...

Retrieving data with a a almost empty configuration:

ramses_cc:
  serial_port:
    port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  scan_interval: 30
  packet_log:
    file_name: packet.log
    rotate_backups: 7
  restore_cache:
    restore_state: false
    restore_schema: false
  advanced_features:
    send_packet: true

is working without any issues. Getting all kind of logs in de packet.log file.

After adding configuration to retrieve (and send) command my system hangs after a while. No log captured anymore and also my other 868MHz devices aren't working anymore. Seems that the SSM-D2 keeps sending packages.

Current config is:

ramses_cc:
  restore_cache: false
  ramses_rf:
    enforce_known_list: true
  serial_port: /dev/ttyACM0 #/dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log:
    file_name: packet.log
    rotate_backups: 7  
  advanced_features:
    send_packet: false  
  orphans_hvac: [18:070670,32:161205,29:179059]
  known_list:
    32:161205: {class: FAN}
    18:070670: {class: HGI}
    29:179059: {class: REM}

With this configuration I'm getting data (after resetting HomeAssistant and the SSM serveral times).

Adding configuration like commands:, faked: etc. or enabling send_package is causing issues.

Also enabled extra logging with:

logger:
  logs:
    custom_components.ramses_cc: debug  # show ramses_cc/ramses_rf state
    ramses_rf.dispatcher: debug         # show packet payloads
    homeassistant.components.serial: debug

Log after last reboot (only Ramses lines):

2023-09-26 20:31:45.498 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration ramses_cc which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-09-26 20:32:16.476 INFO (MainThread) [custom_components.ramses_cc] ramses_cc v0.22.40, is using ramses_rf v0.22.40
2023-09-26 20:32:16.476 DEBUG (MainThread) [custom_components.ramses_cc] 

Config = {'restore_cache': {'restore_schema': False, 'restore_state': False}, 'ramses_rf': {'enforce_known_list': True, 'max_zones': 12, 'use_aliases': False, 'disable_sending': False, 'disable_discovery': False, 'use_native_ot': 'prefer', 'enable_eavesdrop': False, 'reduce_processing': 0}, 'serial_port': {'port_name': '/dev/ttyACM0', 'timeout': 0, 'baudrate': 115200, 'xonxoff': True, 'rtscts': False, 'dsrdtr': False}, 'packet_log': {'file_name': 'packet.log', 'rotate_backups': 7}, 'advanced_features': {'send_packet': False, 'message_events': None}, 'orphans_hvac': ['18:070670', '32:161205', '29:179059'], 'known_list': {'32:161205': {'class': 'FAN', 'faked': None, 'alias': None, '_domain': 'hvac'}, '18:070670': {'class': 'HGI', 'faked': None, 'alias': None, '_domain': 'heat'}, '29:179059': {'class': 'REM', 'faked': None, 'alias': None, '_domain': 'hvac'}}, 'scan_interval': datetime.timedelta(seconds=60), 'block_list': {}}

2023-09-26 20:32:16.485 DEBUG (MainThread) [custom_components.ramses_cc.schemas] A cached schema was not enabled (not recommended)
2023-09-26 20:32:16.485 DEBUG (MainThread) [custom_components.ramses_cc.schemas] Loaded a config schema: {'orphans_hvac': ['18:070670', '32:161205', '29:179059']}
2023-09-26 20:32:16.485 INFO (MainThread) [custom_components.ramses_cc.schemas] Using the config schema (cached schema is not enabled / is invalid), consider using 'restore_cache: restore_schema: true'
2023-09-26 20:32:16.492 INFO (MainThread) [custom_components.ramses_cc.coordinator] Success initialising with the config schema: {'orphans_hvac': ['18:070670', '32:161205', '29:179059']}
2023-09-26 20:32:16.492 INFO (MainThread) [custom_components.ramses_cc.coordinator] Not restoring any cached state (disabled), consider using 'restore_cache: restore_state: true
2023-09-26 20:32:16.492 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Starting the RF monitor...
2023-09-26 20:32:16.517 DEBUG (MainThread) [custom_components.ramses_cc] 

Store = {'client_state': {'schema': {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}, 'packets': {}}, 'remotes': {'29:179059': {}}}

2023-09-26 20:32:16.518 DEBUG (MainThread) [custom_components.ramses_cc] Finished fetching ramses_cc data in 0.000 seconds (success: True)
2023-09-26 20:32:16.804 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 |  63:262142 |  I | puzzle_packet    |      || {'datetime': '2023-09-26T20:32:16.497', 'engine': 'v0.22.40', 'parser': 'v0.22.40'}
2023-09-26 20:32:17.032 INFO (MainThread) [custom_components.ramses_cc.binary_sensor] Found a Binary Sensor for 32:161205: bypass_position
2023-09-26 20:32:17.032 INFO (MainThread) [custom_components.ramses_cc.binary_sensor] Found a Binary Sensor for 29:179059: battery_low
2023-09-26 20:32:17.038 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: air_quality
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: air_quality_base
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: co2_level
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: exhaust_fan_speed
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: exhaust_flow
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: exhaust_temperature
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: fan_info
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: indoor_humidity
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: indoor_temperature
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: outdoor_humidity
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: outdoor_temperature
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: post_heat
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: pre_heat
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: remaining_time
2023-09-26 20:32:17.039 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: speed_cap
2023-09-26 20:32:17.040 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: supply_fan_speed
2023-09-26 20:32:17.040 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: supply_flow
2023-09-26 20:32:17.040 INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:161205: supply_temperature
2023-09-26 20:32:19.351 INFO (MainThread) [custom_components.ramses_cc.remote] Found a Remote: 29:179059 (REM)
2023-09-26 20:32:20.124 INFO (MainThread) [custom_components.ramses_cc.climate_hvac] Found a HVAC system: 32:161205 (FAN)
2023-09-26 20:32:21.519 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2023-09-26 20:32:31.613 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 | FAN:161205 | RQ | unknown_22e0     |      || {}
2023-09-26 20:32:31.615 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22E0 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22E0
2023-09-26 20:32:34.129 INFO (MainThread) [custom_components.ramses_cc.binary_sensor] Found a Binary Sensor for 18:070670: status
2023-09-26 20:32:39.112 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2023-09-26 20:33:32.283 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 | FAN:161205 | RQ | unknown_22e5     |      || {}
2023-09-26 20:33:32.285 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22E5 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22E5
2023-09-26 20:34:32.173 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 | FAN:161205 | RQ | unknown_22e9     |      || {}
2023-09-26 20:34:32.174 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22E9 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22E9
2023-09-26 20:34:42.348 INFO (MainThread) [ramses_rf.dispatcher] || REM:179059 | FAN:161205 |  I | fan_mode         |      || {'fan_mode': 'medium', '_scheme': 'orcon', '_mode_idx': '02', '_mode_max': '04'}
2023-09-26 20:34:42.377 INFO (MainThread) [ramses_rf.dispatcher] || FAN:161205 |            |  I | fan_state        |  00  || {'exhaust_fan_speed': 0.01, 'fan_mode': '02', 'passive': False, 'damper_only': False, 'filter_dirty': False, 'frost_cycle': False, 'has_fault': False, '_flags': [0, 0, 0, 0, 0, 0, 0, 0], '_unknown_3': '00'}
2023-09-26 20:35:31.630 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 | FAN:161205 | RQ | unknown_22f2     |      || {}
2023-09-26 20:35:31.630 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22F2 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22F2
2023-09-26 20:36:31.636 INFO (MainThread) [ramses_rf.dispatcher] || HGI:070670 | FAN:161205 | RQ | unknown_22f4     |      || {}
2023-09-26 20:36:31.637 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:070670 32:161205 --:------ 22F4 001 00 < Invalid code for 32:161205 (FAN) to Rx/Tx: 22F4
2023-09-26 20:37:16.493 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2023-09-26 20:42:16.493 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...

22C9 Corrupt payload

Itho devices: Spider, Autotemp, WPU

21:31:14.530 || Spider | AutotempslaveA |  W | ufh_setpoint     |  05  || {'ufh_idx': '05', 'temp_low': 21.0, 'temp_high': 22.0, '_unknown_0': '01'}
21:31:14.633  I --- AutotempslaveA Spider --:------ 22C9 008 0508347FFF010103 < Corrupt payload: Payload doesn't match '^(0[0-9A-F][0-9A-F]{8}0[12]){1,4}(0203)?$': 0508347FFF010103
21:31:14.776 || Spider | AutotempslaveA |  W | ufh_setpoint     |  05  || {'ufh_idx': '05', 'temp_low': 21.0, 'temp_high': 22.0, '_unknown_0': '01'}
21:31:14.847  I --- AutotempslaveA Spider --:------ 22C9 008 0508347FFF010103 < Corrupt payload: Payload doesn't match '^(0[0-9A-F][0-9A-F]{8}0[12]){1,4}(0203)?$': 0508347FFF010103
21:31:14.977 || Spider | AutotempslaveA |  W | ufh_setpoint     |  05  || {'ufh_idx': '05', 'temp_low': 21.0, 'temp_high': 22.0, '_unknown_0': '01'}
21:31:15.042  I --- AutotempslaveA Spider --:------ 22C9 008 0508347FFF010103 < Corrupt payload: Payload doesn't match '^(0[0-9A-F][0-9A-F]{8}0[12]){1,4}(0203)?$': 0508347FFF010103

packetlog

2022-11-30T21:31:14.530262 000  W --- 21:044797 02:242981 --:------ 22C9 006 050834089801
2022-11-30T21:31:14.633291 054  I --- 02:242981 21:044797 --:------ 22C9 008 0508347FFF010103
2022-11-30T21:31:14.776232 000  W --- 21:044797 02:242981 --:------ 22C9 006 050834089801
2022-11-30T21:31:14.847527 053  I --- 02:242981 21:044797 --:------ 22C9 008 0508347FFF010103
2022-11-30T21:31:14.977377 000  W --- 21:044797 02:242981 --:------ 22C9 006 050834089801
2022-11-30T21:31:15.042668 054  I --- 02:242981 21:044797 --:------ 22C9 008 0508347FFF010103

AssertionError for 22D0

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py:350 
First occurred: 13:25:17 (222 occurrences) 
Last logged: 14:49:19

W --- 21:041873 02:246902 --:------ 22D0 008 0312001E14030020 < AssertionError(Support the development of ramses_rf by reporting this packet)
I --- 02:246902 21:041873 --:------ 22D0 004 03120000 < AssertionError(Support the development of ramses_rf by reporting this packet)
W --- 21:034832 02:248294 --:------ 22D0 008 0304001E14030020 < AssertionError(Support the development of ramses_rf by reporting this packet)
I --- 02:248294 21:034832 --:------ 22D0 004 03010000 < AssertionError(Support the development of ramses_rf by reporting this packet)
I --- 02:248294 --:------ 02:248294 22D0 004 00010000 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 140, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 1425, in parser_22d0
    assert payload in (
AssertionError: Support the development of ramses_rf by reporting this packet

DT4R always reports battery level as 0

I have a couple of Honeywell Home DT4R wireless thermostats that appear to always report their battery level as 0:

2023-12-01T12:35:26.260222 043  I --- 22:014503 --:------ 22:014503 1060 003 000001
2023-12-01T12:46:31.899891 048  I --- 22:014583 --:------ 22:014583 1060 003 000001

As this can never be the case, would it be possible to add a condition for this in parser_1060 and return the level as None? I presume this would then map through to Home Assistant via ramses_cc as a battery level attribute of Unknown which is preferable to the erroneous data.

Running on MacOS

Just wanted to let you know that I got this working on MacOS, however I had to make a few changes.

Installed click library manually using pip - not sure if this can be added to the requirements.txt (python is not my strength)
Received the following error: NotImplementedError: Low latency not supported on this platform - worked around by commenting out the ser_instance.set_low_latency_mode(True) # only for FTDI? block.

Thanks for the great project!

AssertionError: Unknown verb for 10:040239: I/3EF0

2021-01-25 19:18:17 ERROR (MainThread) [evohome_rf.message] 050  I --- 10:040239 --:------ 10:040239 3EF0 009 0002100A00FF032264 < AssertionError
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 519, in process_msg
    update_entities(msg, msg._gwy._prev_msg)  # update the state database
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 466, in update_entities
    this._gwy.device_by_id[this.src.id]._handle_msg(this)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 733, in _handle_msg
    super()._handle_msg(msg)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 226, in _handle_msg
    super()._handle_msg(msg)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 380, in _handle_msg
    assert (
AssertionError: Unknown verb for 10:040239:  I/3EF0

device type 32 not known to have signature 0001C87D130D67FEFF

Getting this in the home-assistant.log after restarting my Orcon HRC-300-EcoMax

2023-09-20 19:10:55.977 WARNING (MainThread) [ramses_rf.protocol.parsers]  I --- 32:161205 63:262142 --:------ 10E0 038 000001C87D130D67FEFFFFFFFFFF1C0207E3564D442D3135524D533634000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:161205 (device type 32 not known to have signature: 0001C87D130D67FEFF)

Retested @ 20:12 to be sure it's from the restart.

2023-09-20 20:12:43.056 WARNING (MainThread) [ramses_rf.protocol.parsers]  I --- 32:161205 63:262142 --:------ 10E0 038 000001C87D130D67FEFFFFFFFFFF1C0207E3564D442D3135524D533634000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:161205 (device type 32 not known to have signature: 0001C87D130D67FEFF)

object of type 'int' has no len()

Logger: ramses_rf.protocol.command
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py:151
First occurred: November 27, 2021, 9:16:36 AM (120 occurrences)
Last logged: 12:01:36 AM

validate_command(): object of type 'int' has no len()
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 143, in _wrapper
    return fcn(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 505, in get_relay_demand
    return cls(RQ, _0008, zone_idx, dev_id, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 267, in __init__
    self._validate(
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 336, in _validate
    self._len = int(len(self.payload) / 2)
TypeError: object of type 'int' has no len()

I'm quite spammed by this error. running 0.16.20 of evohome_cc on Hassio

Reduced support for non-evohome controllers

Hi zxdavb,

Maybe you can help me with this. I am getting some good decoded data, but also very many error messages (mainly "coding error" and "validation error"). Could this be something in my configuration/hardware, or is it code-related and the decoding of these specific messages is not fully implemented yet?

Here are a few examples:

2021-05-27T08:35:15.785452 090  I 108 --:------ --:------ 12:126457 2309 006 0107D0020708 < Validation error: expecting length 3
Traceback (most recent call last):
  File "/home/pi/ramses_rf/ramses_rf/message.py", line 402, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 265, in wrapper
    result = func(*args, **kwargs)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 1441, in parser_2309
    assert msg.len == 3, "expecting length 3"
AssertionError: expecting length 3

2021-05-27T08:35:15.816891 087  I 110 --:------ --:------ 12:126457 000A 012 010001F40BB8020001F40BB8 < Validation error: expecting length 6
Traceback (most recent call last):
  File "/home/pi/ramses_rf/ramses_rf/message.py", line 402, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 265, in wrapper
    result = func(*args, **kwargs)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 611, in parser_000a
    assert msg.len == 6, "expecting length 6"
AssertionError: expecting length 6

2021-05-27T08:35:25.702793 064  I --- 00:034798 --:------ 12:126457 1060 003 02FF01 < Coding error
Traceback (most recent call last):
  File "/home/pi/ramses_rf/ramses_rf/message.py", line 402, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 268, in wrapper
    return {**_idx(payload[:2], msg), **result}
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 144, in _idx
    raise TypeError("result={}")
TypeError: result={}

2021-05-27T08:35:34.202872 069  I --- 04:029362 --:------ 12:126457 3150 002 0162 < Coding error
Traceback (most recent call last):
  File "/home/pi/ramses_rf/ramses_rf/message.py", line 402, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 265, in wrapper
    result = func(*args, **kwargs)
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 1640, in parser_3150
    return _parser(payload)  # TODO: check UFC/FC is == CTL/FC
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 1634, in _parser
    return {**_idx(seqx[:2], msg), "heat_demand": _percent(seqx[2:])}
  File "/home/pi/ramses_rf/ramses_rf/parsers.py", line 144, in _idx
    raise TypeError("result={}")
TypeError: result={}

Note this device sends a 1F09 packet:

08:35:15.771 ||            | THm:126457 |  I | system_sync      | 000BC2   || {'remaining_seconds': 301.0, '_next_sync': '08:40:16'}

Thanks for checking! :-)

reset_system_mode error

Calling ramses_cc.reset_system_mode from HA is not working in v0.22.1

Example HA automation:

- id: '1607967971509'
  alias: Reset schedule on Sunday
  description: Resets the heating system to follow schedule at 13:30 each Sunday
  trigger:
  - platform: time
    at: '13:20'
  condition:
  - condition: time
    weekday:
    - sun
  - condition: state
    entity_id: climate.controller
    attribute: system_mode
    state: Auto
  action:
  - service: ramses_cc.reset_system_mode
    data:
      entity_id: climate.controller
  mode: single

Error in HA log:

2022-11-14 15:52:58.809 ERROR (MainThread) [homeassistant.components.automation.reset_schedule_on_sunday] While executing automation automation.reset_schedule_on_sunday
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 551, in async_trigger
    await self.action_script.async_run(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1524, in async_run
    await asyncio.shield(run.async_run())
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 409, in async_run
    await self._async_step(log_exceptions=False)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 453, in _async_step
    self._handle_exception(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 476, in _handle_exception
    raise exception
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1744, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1781, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 770, 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 943, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 709, in _handle_entity_call
    result = hass.async_run_job(partial(getattr(entity, func), **data))  # type: ignore[arg-type]
  File "/usr/src/homeassistant/homeassistant/core.py", line 621, in async_run_job
    return self.async_run_hass_job(HassJob(target), *args)
  File "/usr/src/homeassistant/homeassistant/core.py", line 573, in async_run_hass_job
    hassjob.target(*args)
  File "/config/custom_components/ramses_cc/climate_heat.py", line 215, in svc_reset_system_mode
    self._call_client_api(self._device.reset_mode)
  File "/config/custom_components/ramses_cc/__init__.py", line 216, in _call_client_api
    func(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 944, in reset_mode
    return self.set_mode(SYS_MODE_MAP.AUTO_WITH_RESET)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 935, in set_mode
    Command.set_system_mode(self.id, system_mode, until=until)
  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 186, in wrapper
    return _wrapper(fcn, cls, dst_id, *args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 163, in _wrapper
    return fcn(cls, *args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 900, in set_system_mode
    system_mode = SYS_MODE_MAP._hex(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/const.py", line 172, in _hex
    raise KeyError(key)
KeyError: '06'

regex not valid for Opentherm RQ commands

When testing an Opentherm command to set the DHW temperature, ramses_rf didn't like it.

09:52:36.445 RQ --- 18:056026 10:133866 --:------ 3220 005 0010383C00 < Corrupt payload: Payload doesn't match '^00[0-9A-F]{4}0{4}$': 0010383C00
2022-09-05T09:52:36.444430 || HGI:056026 | 10:133866 | RQ | opentherm_msg | 38 || {'msg_id': 56, 'msg_type': 'Write-Data', 'msg_name': 'DHWSetpoint', 'value': 60.0, 'description': 'DHW setpoint'}
2022-09-05T09:52:36.849322 || OTB:133866 | HGI:056026 | RP | opentherm_msg | 38 || {'msg_id': 56, 'msg_type': 'Write-Ack', 'msg_name': 'DHWSetpoint', 'value': 60.0, 'description': 'DHW setpoint'}

I'm fairly new to ramses_cc so I hope I'm not misunderstanding the design, but it looks quite appropriate that the two bytes at the end of the RQ packet would be non-zero.

The parser_3220 code looks like it only supports RQ and RP messages, doesn't allow for ' W', so I guessed it must be appropriate to use RQ to do a write operation. And it did seem to work.

Validation error, payload[6:8] 0x03

2021-05-14T13:48:21.306620 087 RP --- 30:253184 34:010943 --:------ 2349 013 00064000FFFFFF00110E0507E5 < Validation error: 00 (0x03) 

Traceback (most recent call last):
  File "/home/amorsen/src/ramses_rf/ramses_rf/message.py", line 400, in is_valid
    self._payload = payload_parser(self.raw_payload, self)
  File "/home/amorsen/src/ramses_rf/ramses_rf/parsers.py", line 264, in wrapper
    result = func(*args, **kwargs)
  File "/home/amorsen/src/ramses_rf/ramses_rf/parsers.py", line 1411, in parser_2349
    assert payload[6:8] not in ("00", "02"), f"{payload[6:8]} (0x03)"
AssertionError: 00 (0x03)

I believe that the problem is not due to a receiver problem, as the same exact message is received every 30 minutes.

cannot start client.py in monitor mode: getting a TypeError

I can run:

pi@raspberrypi:~/ramses_rf $ python client.py listen /dev/ttyUSB0 -o packet.log

but if i run:

pi@raspberrypi:~/ramses_rf $ python client.py monitor /dev/ttyUSB0 -o packet.log

it fails,

pi@raspberrypi:~/ramses_rf $ python -V
Python 3.9.2

on Raspbian GNU/Linux 11 (bullseye)

Traceback (most recent call last):
File "/home/pi/ramses_rf/client.py", line 473, in
cli()
File "/usr/lib/python3/dist-packages/click/core.py", line 829, in call
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1257, in invoke
sub_ctx = cmd.make_context(cmd_name, args, parent=ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 700, in make_context
self.parse_args(ctx, args)
File "/usr/lib/python3/dist-packages/click/core.py", line 1048, in parse_args
value, args = param.handle_parse_result(ctx, opts, args)
File "/usr/lib/python3/dist-packages/click/core.py", line 1623, in handle_parse_result
value = self.full_process_value(ctx, value)
File "/usr/lib/python3/dist-packages/click/core.py", line 1965, in full_process_value
return Parameter.full_process_value(self, ctx, value)
File "/usr/lib/python3/dist-packages/click/core.py", line 1592, in full_process_value
value = self.get_default(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1917, in get_default
return Parameter.get_default(self, ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1534, in get_default
return self.type_cast_value(ctx, rv)
File "/usr/lib/python3/dist-packages/click/core.py", line 1561, in type_cast_value
return self.type(value or (), self, ctx)
File "/usr/lib/python3/dist-packages/click/types.py", line 46, in call
return self.convert(value, param, ctx)
File "/usr/lib/python3/dist-packages/click/types.py", line 681, in convert
raise TypeError(
TypeError: It would appear that nargs is set to conflict with the composite type arity.

Thanks for looking into this!

Marnix

cannot start client.py: TypeError

python3 client.py monitor /dev/ttyUSB0 -o packet.log

gives

Traceback (most recent call last):
  File "client.py", line 21, in <module>
    from ramses_rf import Gateway, GracefulExit, is_valid_dev_id
  File "/home/pv/ramses_rf/ramses_rf/__init__.py", line 16, in <module>
    from .const import __dev_mode__
  File "/home/pv/ramses_rf/ramses_rf/const.py", line 9, in <module>
    from .protocol.const import (  # noqa: F401
  File "/home/pv/ramses_rf/ramses_rf/protocol/__init__.py", line 9, in <module>
    from .address import Address, is_valid_dev_id
  File "/home/pv/ramses_rf/ramses_rf/protocol/address.py", line 24, in <module>
    DEVICE_LOOKUP |= {"NUL": "63", "---": "--"}

pip list | grep -E '(serial|click)'
click                  8.1.3               
pyserial               3.4                 
pyserial-asyncio       0.6

python3 -V
Python 3.8.10

Support for HCC100

Honeywell / Resideo introduced the HCC100 underfloor heating controller. I installed it as part of my Evohome setup, replacing my HCE80. Would it be possible to add support for the HCC100 in ramses_rf and ramses_cc? I would be happy to provide packet logs, etc.

I think my HCC100 is device 02:066404. The Home Assistant log includes this line:

2023-10-01 10:03:07.436 WARNING (MainThread) [ramses_rf.protocol.message] I --- 02:066404 --:------ 02:066404 3150 008 2100220023002400 < Corrupt payload: Payload doesn't match '^((0[0-9A-F])[0-9A-F]{2}|FC[0-9A-F]{2})+$': 2100220023002400

31da struct resolved

Hi,
can you help me with the following:

I found a structure (Originally it's visual basic) for the 31DA type: In this case it's from Itho Daalderop .

2021-05-23T10:19:11.077679 070  I --- 37:054619 --:------ 37:054619 31DA 029 00EF007FFFEFEF7FFF7FFF7FFF7FFFF800EF8301000000EFEF7FFF7FFF

Structure is:

data.data[0] > 200
data.data[0] 	
else
decimal num = new decimal((double)(int)data.data[0] / 2.0);
        
data_length > 0
data.data[1]

data_length > 1
int num2 = unchecked((int)data.data[2]) * 256 + unchecked((int)data.data[3]) //num2 <= 32766

data_length > 3
int num3 = data.data[4]; //num3 needs to be <=200

data_length > 4
int num4 = data.data[5]; //num4 needs to be <=200

data_length > 5
int num5 = unchecked((int)data.data[6]) * 256 + unchecked((int)data.data[7]) //num5 needs to be <= 32766

data_length > 7
int num6 = unchecked((int)data.data[8]) * 256 + unchecked((int)data.data[9]); //num6 needs to be <= 32766

data_length > 9
int num7 = unchecked((int)data.data[10]) * 256 + unchecked((int)data.data[11]); num6 needs to be <= 32766
format: (double)num7 / 100.0

data_length > 11
int num8 = unchecked((int)data.data[12]) * 256 + unchecked((int)data.data[13]); num8 needs to be <= 32766
format: (double)num8
 
data_length > 13
int val = unchecked((int)data.data[14]) * 256 + unchecked((int)data.data[15]);

data_length > 15
int num9 = data.data[16] 
format: (double)num9 / 2.0

data_length > 16
int num10 = data.data[17];
format: num10 & 0x1F //don't know

data_length > 17
int num11 = data.data[18] //num11 need to be <=200
format: (double)num11 / 2.0 

data_length > 18
int num12 = data.data[19]; need to be <=200
format: (double)num12 / 2.0

data_length > 19
int num13 = unchecked((int)data.data[20]) * 256 + unchecked((int)data.data[21]);

data_length > 21
int num14 = data.data[22]; needs to be <=200
format: (double)num14 / 2.0

data_length > 22
int num15 = data.data[23];
format: (double)num15 / 2.0

data_length > 23
int num16 = unchecked((int)data.data[24]) * 256 + unchecked((int)data.data[25]); //Need to be <=32766
format: (double)num16 / 100.0 

data_length > 25
int num17 = unchecked((int)data.data[26]) * 256 + unchecked((int)data.data[27]); //Need to be <=32766
format: (double)num17 / 100.0

Can we add this to the parser?

AssertionError for 31DA

First of all, my complements on the amount of work done in this and in the accompanying repositories.

At home I have an Itho HVAC system which I eventually want to integrate in my home automation system (homeassistant). My ventilation unit (HRU ECO 300) is rf-coupled with my thermostat (Spider). Remote control works fine and if I control the ventilation locally using a 3-way switch then the thermostat correctly updates its ventilation state. This way I know that my ventilation unit is broadcasting it's state, next step is receive and decode this information.

As hardware I use a Arduino pro Micro in combination with CC1101 868MHz Module flashed with evofw3 Version 0.7.0.

The following command is used to eavesdrop the ventilation packets:
python client.py listen COM13

The following packet contains the information I need to retrieve the status of my ventilation unit:

20:44:09.259  I --- 18:126620 --:------ 18:126620 31DA 029 00F0007FFFEFEF0443034B07A7032B4000C80100FF0000EFEF2BB62BB6 << AssertionError(F0)
Traceback (most recent call last):
  File "C:\DEV\ramses_rf\ramses_rf\protocol\message.py", line 355, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "C:\DEV\ramses_rf\ramses_rf\protocol\parsers.py", line 126, in wrapper
    return func(*args, **kwargs)
  File "C:\DEV\ramses_rf\ramses_rf\protocol\parsers.py", line 1531, in parser_31da
    assert payload[2:4] in ("00", "EF"), payload[2:4]
AssertionError: F0

Took a while to decode this message by hand:

Byte:
00 - ? -> No clue what this byte could be
F0 - Air quality -> shorted sensor
00 - Quality base -> based on outside air
7FFF - Co2 Level -> Not available
EF - Outdoor humidity -> Not available
EF - Indoor humidity -> Not available
0457 - Exhaust temperature -> Value tbd
0360 - Supply temperature -> Value tbd
079B - Indoor temperature -> Value tbd
033B - Outdoor temperature -> Value tbd
4000 - Capability flags -> Away capable?
C8 - Bypass position -> Value tbd
02 - Flags -> Speed 2
50 - Exhaust fan speed -> Value tbd
FF - Inlet fan speed	 -> Not available
0000 - Remaining time -> off
EF - Post heater -> Not available
EF - Pre heater -> Not available	
43E4 - Inlet flow -> Value tbd
43E4 - Exhaust flow	 -> Value tbd

My goal is to eventually get these values into HomeAssistant using evohome_cc. Can you help me overcome the error above and point me into the right direction getting this into HomeAssistant?

Thanks in advance!

4E02 Corrupt payload

Itho devices: Spider, Autotemp, WPU

18:06:43.916  I --- Autotempslave AutotempMaster --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF < Corrupt payload: Payload doesn't match '^00([0-9A-F]{4}){8}02([0-9A-F]{4}){8}$': 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF
18:06:44.899  I --- Autotempslave AutotempMaster --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF < Corrupt payload: Payload doesn't match '^00([0-9A-F]{4}){8}02([0-9A-F]{4}){8}$': 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF
18:06:45.881  I --- Autotempslave AutotempMaster --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF < Corrupt payload: Payload doesn't match '^00([0-9A-F]{4}){8}02([0-9A-F]{4}){8}$': 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF

packetlog:

2022-11-04T18:06:43.916064 052  I --- 02:24XXXX 02:24YYYY --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF
2022-11-04T18:06:44.899065 051  I --- 02:24XXXX 02:24YYYY  --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF
2022-11-04T18:06:45.881991 052  I --- 02:24XXXX 02:24YYYY  --:------ 4E02 034 0008667FFF7FFF7FFF7FFF7FFF7FFF7FFF0408CA7FFF7FFF7FFF7FFF7FFF7FFF7FFF

Hometronic setpoint adjustment broken in 0.11.0

Hometronic does not react to W:2349 but rather requies W:2309. This is something that used to work before but looks like some structural changes may have broken it. I was able to fix it temporarily on my system by adapting climate.py from this

    def svc_set_zone_mode(
        self, mode=None, setpoint=None, duration=None, until=None
    ) -> None:
        """Set the (native) operating mode of the Zone."""
        if until is None and duration is not None:
            until = dt.now() + duration
        self._device.set_mode(mode=mode, setpoint=setpoint, until=until)
        self._req_ha_state_update()

to this

    def svc_set_zone_mode(
        self, mode=None, setpoint=None, duration=None, until=None
    ) -> None:
        """Set the (native) operating mode of the Zone."""
        if until is None and duration is not None:
            until = dt.now() + duration
        self._device.setpoint=setpoint
        self._req_ha_state_update()

As per the comment on the forum it's not really suitable as is because it would limit functionality for others.

Packet info
In the current system when I adjusted the zone setpoint to 8.5 deg. I can see it's sending the requests to zone 5 for 0352 but getting no reply

2021-07-18T15:32:28.499339 000  W --- 18:138267 01:020766 --:------ 2349 007 05035202FFFFFF
2021-07-18T15:32:28.586291 000  W --- 18:138267 01:020766 --:------ 2349 007 05035202FFFFFF
2021-07-18T15:32:28.723146 000  W --- 18:138267 01:020766 --:------ 2349 007 05035202FFFFFF
2021-07-18T15:32:30.444316 075  I --- 00:000951 --:------ 00:000951 30C9 003 000A54
2021-07-18T15:32:35.444890 067  I --- 00:000494 --:------ 01:020766 2309 003 050320
2021-07-18T15:32:41.944937 075  I --- 00:000606 --:------ 01:020766 3150 002 0800

However after the fix the following sequence works fine and W:2309 is immediately confirmed by I:2309 and the new zone temp could be seen later on I:2309 broadcast by the controller.

2021-07-18T18:32:29.951767 000  W --- 18:138267 01:020766 --:------ 2309 003 0308FC
2021-07-18T18:32:29.994800 070  I --- 01:020766 18:138267 --:------ 2309 003 0308FC
2021-07-18T18:32:35.412075 061  I --- 00:000599 --:------ 01:020766 2309 003 0D0320
2021-07-18T18:32:37.413208 068  I --- 00:000567 --:------ 01:020766 2309 003 0A0320
2021-07-18T18:32:40.911535 065  I --- 00:000595 --:------ 01:020766 3150 002 0C00
2021-07-18T18:32:47.913285 076  I --- 00:000606 --:------ 00:000606 30C9 003 000942
2021-07-18T18:32:49.413565 076  I --- 00:000606 --:------ 01:020766 1060 003 08FF01
2021-07-18T18:32:49.425550 075  I --- 00:000606 --:------ 00:000606 1060 003 00FF01
2021-07-18T18:32:50.411372 071  I --- 04:017575 --:------ 01:020766 2309 003 060320
2021-07-18T18:32:53.414567 068  I --- 00:000498 --:------ 01:020766 1060 003 00FF01
2021-07-18T18:32:53.425560 068  I --- 00:000498 --:------ 00:000498 1060 003 00FF01
2021-07-18T18:32:58.911055 081  I --- 00:000392 --:------ 00:000392 30C9 003 000921
2021-07-18T18:33:00.411387 048  I --- 04:024117 --:------ 04:024117 30C9 003 000960
2021-07-18T18:33:02.912131 075  I --- 00:000951 --:------ 01:020766 1060 003 07FF01
2021-07-18T18:33:02.924132 075  I --- 00:000951 --:------ 00:000951 1060 003 00FF01
2021-07-18T18:33:05.912701 073  I --- 00:000606 --:------ 01:020766 3150 002 0800
2021-07-18T18:33:08.413592 062  I --- 00:000599 --:------ 01:020766 1060 003 0DFF01
2021-07-18T18:33:08.424613 061  I --- 00:000599 --:------ 00:000599 1060 003 00FF01
2021-07-18T18:33:08.912324 070  I --- 00:000567 --:------ 01:020766 3150 002 0A00
2021-07-18T18:33:09.482978 066  I --- 01:020766 --:------ 01:020766 1F09 003 FF04CE
2021-07-18T18:33:09.525971 065  I --- 01:020766 --:------ 01:020766 2309 042 0002DA0103200203200308FC0403200503200603200703200803200903200A03200B03200C03200D0320
2021-07-18T18:33:09.558959 066  I --- 01:020766 --:------ 01:020766 30C9 042 000AAA010E7C02095003085004090D0508B8060A0B0709F40809420909600A09420B09210C09140D092E

I can provide daily logs if necessary for your collection.

0.30.2: Help wanted: 4E04 (Itho Spider)

Itho devices: Spider, Autotemp, WPU

17:28:46.265  I --- AutotempslaveA AutotempMaster --:------ 4E04 003 000004 < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 000004
17:42:40.388  I --- AutotempslaveB AutotempMaster --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:43:31.603  W --- AutotempMaster AutotempslaveB --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:43:31.693  I --- AutotempslaveB AutotempMaster --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:43:32.623  I --- AutotempslaveA AutotempMaster --:------ 4E04 003 000004 < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 000004
17:54:36.088  I --- AutotempslaveB AutotempMaster --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:57:26.302  W --- AutotempMaster AutotempslaveB --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:57:26.364  I --- AutotempslaveB AutotempMaster --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:58:17.529  W --- AutotempMaster AutotempslaveB --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:58:17.603  I --- AutotempslaveB AutotempMaster --:------ 4E04 003 00000E < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 00000E
17:58:18.472  W --- AutotempMaster AutotempslaveA --:------ 4E04 003 000005 < Corrupt payload: Payload doesn't match '^00(00FF|01FE)$': 000005

packetlog:

2022-11-04T17:28:46.265250 078  I --- 02:24AAAA 02:24MMMM --:------ 4E04 003 000004
2022-11-04T17:42:40.388694 052  I --- 02:24BBBB 02:24MMMM --:------ 4E04 003 00000E
2022-11-04T17:43:31.603633 079  W --- 02:24MMMM 02:24BBBB --:------ 4E04 003 00000E
2022-11-04T17:43:31.693901 052  I --- 02:24BBBB 02:24MMMM --:------ 4E04 003 00000E
2022-11-04T17:43:32.623798 079  I --- 02:24AAAA 02:24MMMM --:------ 4E04 003 000004
2022-11-04T17:54:36.088201 052  I --- 02:24BBBB 02:24MMMM --:------ 4E04 003 00000E
2022-11-04T17:57:26.302163 076  W --- 02:24MMMM 02:24BBBB --:------ 4E04 003 00000E
2022-11-04T17:57:26.364058 052  I --- 02:24BBBB 02:24MMMM --:------ 4E04 003 00000E
2022-11-04T17:58:17.529092 076  W --- 02:24MMMM 02:24BBBB --:------ 4E04 003 00000E
2022-11-04T17:58:17.603095 052  I --- 02:24BBBB 02:24MMMM --:------ 4E04 003 00000E
2022-11-04T17:58:18.472183 077  W --- 02:24MMMM 02:24AAAA --:------ 4E04 003 000005

Received values since 4 months:

3150: demand at 101% (0xCA) is > 1

Mike Henderson
HA Community post

An HR92 went to 101% open this morning and generated this in the log file. I’ll force it to recalibrate, but thought I’d report the error anyway.

evohome_0.21.40 homeassistant_2023.1.7

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py:358
First occurred: 08:30:17 (4 occurrences)
Last logged: 09:30:17

I --- 04:133367 --:------ 01:196480 3150 002 00CA < Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 140, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 2040, in parser_3150
    return valve_demand(payload[2:])  # TODO: check UFC/FC is == CTL/FC
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 23, in wrapper
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 318, in valve_demand
    raise ValueError(f"Invalid result: {result} (0x{value}) is > 1")
ValueError: Invalid result: 1.01 (0xCA) is > 1

David Bonnes

ValueError: Invalid result: 1.01 (0xCA) is > 1

I have see this before… It is a puzzle to me why it gets to 101%, so I’ve not bothered to prevent the ValueError.

You can ignore this message.

Mike Henderson

I know it not causing me a real problem, but would that explain why some mornings in HA that actuator has reported a position of 0% when all others have shown they have opened to 100%, then that one particular actuator has then indicated a position as it starts to close?

David Bonnes

Not exactly.

Since the 101% packet isn’t processed, the actuator will continue to report it’s last %open, as long as it has a previous packet that has not expired.

The last %open could have been 0%, but could any value 0-100% (or 0.0 to 1.0).

If the packet has expired, then the value will be None.

Just search your packet log for 04:133367 --:------ 01:196480 3150 packets and see what payload was before the 00CA.

Just convert the 0xCA (hex) to decimal and divide by 100.

Mike Henderson

Yes, I can see it. This morning the actuator was at 0%, but as you say it could be another value if the temperature had dropped enough overnight. At 8.30 the schedule increases the setpoint for that zone.

2023-02-12T07:05:23.619465 050  I --- 04:133367 --:------ 01:196480 3150 002 0000  # 0%
2023-02-12T07:25:23.266373 050  I --- 04:133367 --:------ 01:196480 3150 002 0000  # 0%
2023-02-12T07:45:25.454516 050  I --- 04:133367 --:------ 01:196480 3150 002 0000  # 0%
2023-02-12T08:05:24.389512 050  I --- 04:133367 --:------ 01:196480 3150 002 0000  # 0%
2023-02-12T08:25:23.835755 050  I --- 04:133367 --:------ 01:196480 3150 002 0000  # 0%
2023-02-12T08:30:17.093217 050  I --- 04:133367 --:------ 01:196480 3150 002 00CA  # 101% # at 08:30am zone setpoint change from 14C to 18C
2023-02-12T08:50:14.104401 050  I --- 04:133367 --:------ 01:196480 3150 002 00CA  # 101%
2023-02-12T09:10:13.246284 050  I --- 04:133367 --:------ 01:196480 3150 002 00CA  # 101%
2023-02-12T09:30:17.669887 050  I --- 04:133367 --:------ 01:196480 3150 002 00CA  # 101%
2023-02-12T09:40:58.728457 050  I --- 04:133367 --:------ 01:196480 3150 002 00AC  # 86%

David Bonnes

Yes, so what you’re seeing is the actuator reporting 0%, when it should really be 100%. Not ideal.

Its zone may also report incorrectly, depending on what other actuators are involved.

I guess I need to do something about it…

Eavesdropping causes CorruptStateError

Eavesdropping enabled to have HR80's present correctly in Schema (HR80 ID's not published by controller during discovery)

It appears the HR80's (once in the schema) then contribute to zone heat demands, based on which various automations are triggered: circulation pumps on/off for specific zones, electric blinds/shutters etc.

055 RP --- 13:259021 18:070162 --:------ 3EF1 007 00012C012C00FF < Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)

Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/message.py", line 711, in process_msg
    update_entities(msg, msg._gwy._prev_msg)  # update the state database
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/message.py", line 652, in update_entities
    this._gwy.device_by_id[this.src.id]._handle_msg(this)
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 1207, in _handle_msg
    super()._handle_msg(msg)
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 328, in _handle_msg
    super()._handle_msg(msg)
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 486, in _handle_msg
    self._set_parent(self._ctl._evo._get_zone(msg.payload["parent_idx"]))
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 505, in _set_parent
    raise CorruptStateError(
ramses_rf.exceptions.CorruptStateError: Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve),  (try restarting the client library)

Assertionerror 31DA with faked remote

2022-12-06 21:03:19.834 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 32:155617 37:155617 --:------ 31DA 030 00EF007FFF363103AC05DC06CE02C9F80000182A2A0000EFEF091D091D00 < AssertionError(msg from 32:155617 (FAN) inappropriately routed to 37:155617 (REM))

[Itho CVE-S CO2 with AUTO RFT-N] Fan states incorrectly recognised

Hi,

Created an issue with evohome-Listener (smar000/evoGateway#61), but problem seems to be with ramses_rf.

I have a Itho Daalderop CVE-S CO2 and humidity sensor unit with AUTO RFT-N remote controls, with on the remote controls the following options:

Low
High
Auto
Timer

Apart from de timer option, all settings seem to be wrongly recognised.

Low: detected as medium
High: detected as auto
Auto: detected as high

In below captures, I pressed Low, High, Auto. I also have an Evohome controller, that's were the setpoint message is coming from.

These captures are from evohome-Listener as the -o packet.log option doesn't seem to work on my ramses_rf setup.

2023-11-12 19:48:17 |000| HGI evoGateway        -> NUL UNBOUND           | I| puzzle_packet   | datetime: 2023-11-12T19:48:17.729, engine: v0.22.40, parser: v0.22.40
2023-11-12 19:48:24 |044| 37:198669             -> 37:019136             | I| fan_mode        | medium
2023-11-12 19:48:24,593 [301] ----> Unknown zone for src: '37:198669 (HVC) '
2023-11-12 19:48:27 |064| TRV 04:007044         -> CTL Controller        | I| setpoint        | 15.00°C                                                                     [Zone 06 ]
2023-11-12 19:48:27,834 [804] Both 'target_zone_id' and 'src_zone_id' not found in ZONES
2023-11-12 19:48:28 |045| 37:198669             -> 37:019136             | I| fan_mode        | auto
2023-11-12 19:48:28,270 [301] ----> Unknown zone for src: '37:198669 (HVC) '
2023-11-12 19:48:31 |043| 37:198669             -> 37:019136             | I| fan_mode        | high
2023-11-12 19:48:31,789 [301] ----> Unknown zone for src: '37:198669 (HVC) '

2023-11-12T19:48:17.721425 # ramses_rf 0.22.40
2023-11-12T19:48:17.777540 000  I --- 18:003618 63:262142 --:------ 7FFF 016 0010018BC4DCF84176302E32322E3430
2023-11-12T19:48:24.587738 044  I --- 37:198669 37:019136 --:------ 22F1 003 000204
2023-11-12T19:48:27.828919 064  I --- 04:007044 --:------ 01:204708 2309 003 0605DC
2023-11-12T19:48:28.266746 045  I --- 37:198669 37:019136 --:------ 22F1 003 000404
2023-11-12T19:48:31.786152 043  I --- 37:198669 37:019136 --:------ 22F1 003 000304

Below output is from a similar test with ramses_rf v0.30.00:

2023-11-12T20:16:24.376134 ||  37:198669 |  37:019136 |  I | fan_mode         |      || {'fan_mode': 'medium', '_scheme': 'orcon', '_mode_idx': '02', '_mode_max': '04'}
2023-11-12T20:16:28.604293 ||  37:198669 |  37:019136 |  I | fan_mode         |      || {'fan_mode': 'auto', '_scheme': 'orcon', '_mode_idx': '04', '_mode_max': '04'}
2023-11-12T20:16:28.644141 ||  37:019136 |  37:198669 |  I | hvac_state       |      || {'fan_info': 'speed 3, high', '_unknown_fan_info_flags': [0, 0, 0], 'air_quality': 1.0, 'air_quality_basis': 'rel_humidity', 'co2_level': 757, 'indoor_humidity': 0.55, 'outdoor_humidity': None, 'exhaust_temp': None, 'supply_temp': None, 'indoor_temp': None, 'outdoor_temp': None, 'speed_capabilities': ['off', 'low_med_high', 'timer', 'boost', 'auto'], 'bypass_position': None, 'exhaust_fan_speed': 0.395, 'supply_fan_speed': 0.0, 'remaining_mins': None, 'post_heat': None, 'pre_heat': None, 'supply_flow': None, 'exhaust_flow': None}
2023-11-12T20:16:33.184460 ||  37:198669 |  37:019136 |  I | fan_mode         |      || {'fan_mode': 'high', '_scheme': 'orcon', '_mode_idx': '03', '_mode_max': '04'}
2023-11-12T20:16:36.879805 ||  37:198669 |  37:019136 |  I | fan_boost        |      || {'minutes': 10, 'flags': [0, 0, 0, 0, 0, 0, 0, 0], '_new_speed_mode': 'fan_boost', '_fallback_speed_mode': None}

Let me know if I can help with anything else.

Regards,

Frank

device type 30 not known to have signature: 0002FF1E02FFFFFFFF

2023-04-20 13:30:38.501 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:071715 --:------ 30:071715 10E0 038 000002FF1E02FFFFFFFF100107DF110A07DE496E7465726E6574204761746577617900000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: RFG:071715 (device type 30 not known to have signature: 0002FF1E02FFFFFFFF)

This is a Honeywell Evohome RFG100 - from an older Evohome setup

Mapping issue with Auto and Day off

This is the mapping issue with Auto resulting in Day Off

https://github.com/zxdavb/evohome_rf/blob/7ae44e5bc9f29608fe4eeb7b78afe1552bd36c4e/evohome_rf/const.py#L390

3EF0 parser: ValueError: Invalid result: ... is > 1

I see multiple times the following error:

Pretty clear whats happening as it expects 00 - 64 at that location, but there are a lot of these errors. Could it be that 64 is not the max value?

Attached logfile as well, hope this gives some info: 2023.txt

Thanks for looking into this and the great work you do on this

2023-03-21 18:19:43.768 ERROR (MainThread) [ramses_rf.protocol.message]  I --- 10:057706 --:------ 10:057706 3EF0 009 008F100A00FF032600 < Coding error: ValueError(Invalid result: 1.43 (0x8F) is > 1)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 141, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 2478, in parser_3ef0
    mod_level = percent_from_hex(payload[2:4], high_res=False)  # 00-64 (or FF)
  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/helpers.py", line 252, in percent_from_hex
    raise ValueError(f"Invalid result: {result} (0x{value}) is > 1")
ValueError: Invalid result: 1.43 (0x8F) is > 1

0.30.3: AssertionError for 3EF0

HomeAssistant
Loads of Itho devices: Spider, Autotemp, HRU

Logger: ramses_rf.protocol.parsers
Source: runner.py:119 
First occurred: 13:25:03 (32 occurrences) 
Last logged: 14:52:58

I --- 21:034615 --:------ 21:034615 3EF0 006 020000100200 < Support the development of ramses_rf by reporting this packet ([0, 0, 0, 1, 0, 0, 0, 0]), with a description of your system
I --- 21:060034 --:------ 21:060034 3EF0 006 0200001C0200 < Support the development of ramses_rf by reporting this packet ([0, 0, 0, 1, 1, 1, 0, 0]), with a description of your system
I --- 21:041873 --:------ 21:041873 3EF0 006 020000100200 < Support the development of ramses_rf by reporting this packet ([0, 0, 0, 1, 0, 0, 0, 0]), with a description of your system
I --- 21:060034 --:------ 21:060034 3EF0 006 020000100200 < Support the development of ramses_rf by reporting this packet ([0, 0, 0, 1, 0, 0, 0, 0]), with a description of your system
I --- 02:247253 --:------ 02:247253 3120 007 0000B2000000FF < Support the development of ramses_rf by reporting this packet (byte 2: B2)

Using client.py with more than one evohome controllers

client summary two evohome WIFI.txt
my system is composed of two evohome WIFI controllers, with only one active for the moment I have nothing special to report (except in the synchronization phase between controller and sensors / actuators in which exception messages are reported) while with two controllers active at the same time only the first is brought back to the exit from client.py correctly while the second only partially even if during the scan all the parameters were detected as well as for the first, for example as indicated in the annex regarding the names of the zones of the second controller that despite having been scanned are not then reported in the summary below because there are no Schema[01:095571 (evohome)], Params[01:095571 (evohome)], Status[01:095571 (evohome)].
Let me know if you need additional information.

Problems with Ramses_rf after migrating to Elga Ace

Hello,

I have a HGI80 installed in combination with Home Assistant. This worked like a charm when my Evohome was connected to my Remeha Calenta. But since a month we have a hybrid heat pump and the Evohome is migrated towards this device. After that i do not get good data from the HGI80. Do you have any idea how that is possible?

If you need any information from me i would love to give it to fix my issue... i don't like the Cloud connection to Evohome.

Best Regards,

JBSDM

ValueError: Invalid result: 1.01 (0xCA) is > 1

11:48:21.862 I --- 13:103760 --:------ 13:103760 3EF0 003 0000FF < Support the development of ramses_rf by reporting this packet (byte 5: )

11:48:39.094 I --- 13:107116 --:------ 13:107116 3EF0 003 00C8FF < Support the development of ramses_rf by reporting this packet (byte 5: )

15:17:41.881 I --- 04:065911 --:------ 01:095571 3150 002 03CA < Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1)

Traceback (most recent call last):
File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/message.py", line 331, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/parsers.py", line 141, in wrapper
result = fnc(payload, msg, **kwargs)

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/parsers.py", line 2057, in parser_3150
return valve_demand(payload[2:]) # TODO: check UFC/FC is == CTL/FC

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/helpers.py", line 27, in wrapper
return fnc(*args, **kwargs)

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/helpers.py", line 328, in valve_demand
raise ValueError(f"Invalid result: {result} (0x{value}) is > 1")

ValueError: Invalid result: 1.01 (0xCA) is > 1

message trace v0.21.6 -.txt
packet.log
evohome controllers configurations v0.21.06.txt

DT4R fingerprint missing

I have a couple of DTR4 thermostats which report device info as follows:

I --- 22:014583 63:262142 --:------ 10E0 038 000002FF1F00FFFFFFFFFFFFFFFFFFFFFFFF4454342030323200C95838F749AFA556B284EBF9
I --- 22:014503 63:262142 --:------ 10E0 038 000002FF1F00FFFFFFFFFFFFFFFFFFFFFFFF4454342030323200C95838A77CF588003884ACE5

I'm happy to provide further packet logs if they are helpful, however I am only using them as zone sensors with an evohome controller so probably won't be able to capture all possible actions.

Issues when zone sensor is the controller

1. as you can check in the attached file the zone "00" is reported in "Schema[01:095571 (evohome)]" with sensor "null" instead of with "01:095571" because it has been assigned as the current temperature that of the sensor on the controller and the same to
  || CTL:095571 | HGI:201230 | RP | zone_devices | 0004 || {'zone_type': '04', 'zone_idx': '00', 'device_role': 'zone_sensor', 'devices': []}
1. in "Status[01:095571 (evohome)]" correctly in the zone "00" is reported the temperature value of 23.19 that the controller "01:095571" sends to the zone "00" together with the setpoint as detectable in the first two lines of the attachment, but which is not found in any other parameter as the sensor on the controller 01:095571
  client summary evohome controller.txt

Setting Schedules

Hi David

I was trying out the settings functionality on the current master, using the client.py cli. Getting schedules worked fine, but setting schedules has been giving me a few errors as below:


python ./client.py execute --set-schedule "01:139901" /tmp/sched.jsn /dev/evoqinheng

client.py: Starting ramses_rf...
08:34:02.182 Allowing packets with device_id: 18:134436 (is active gateway?), configure the known_list/block_list as required
08:34:02.183 Won't create a non-allowed device_id: 18:134436 (if required, add it to the known_list)
08:34:02.181 || HGI:134436 | NUL:------ |  I | puzzle_packet    |      || {'ramses_rf': 'v0.14.24', '_parser': 'v0.14.24'}
08:34:02.216 || HGI:134436 | CTL:139901 |  W | zone_schedule    | 0041 || {'zone_idx': '00', 'frag_index': 65, 'frag_total': 1, 'frag_length': 0, 'fragment': '04'}
08:34:02.552 || HGI:134436 | NUL:------ |  I | puzzle_packet    |      || {'ramses_rf': 'v0.14.24', '_parser': 'v0.14.24'}
08:34:03.192 || HGI:134436 | CTL:139901 |  W | zone_schedule    | 0041 || {'zone_idx': '00', 'frag_index': 65, 'frag_total': 1, 'frag_length': 0, 'fragment': '04'}
08:34:04.426 || HGI:134436 | CTL:139901 |  W | zone_schedule    | 0041 || {'zone_idx': '00', 'frag_index': 65, 'frag_total': 1, 'frag_length': 0, 'fragment': '04'}
08:34:06.859 MsgTransport._pkt_receiver(0404| I|01:139901|0041): Expired callback
08:34:06.859 Exception in callback to message layer
Traceback (most recent call last):
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 414, in _pkt_received
    self._callback(pkt)  # only wanted PKTs to the MSG transport's handler
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/protocol.py", line 165, in _pkt_receiver
    callback[FUNC](False, *callback.get(ARGS, tuple()))
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/schedule.py", line 336, in tx_callback
    msg.payload.get(FRAG_INDEX),
AttributeError: 'bool' object has no attribute 'payload'
08:34:09.304 MsgTransport._pkt_receiver(0404| I|01:139901|0041): Expired callback
08:34:09.304 Exception in callback to message layer
Traceback (most recent call last):
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 414, in _pkt_received
    self._callback(pkt)  # only wanted PKTs to the MSG transport's handler
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/protocol.py", line 165, in _pkt_receiver
    callback[FUNC](False, *callback.get(ARGS, tuple()))
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/schedule.py", line 336, in tx_callback
    msg.payload.get(FRAG_INDEX),
AttributeError: 'bool' object has no attribute 'payload'
08:34:11.719 PktProtocolQos.send_data(0404| W|01:139901|0041): boff=3, want=0404| I|01:139901|0041, tout=2021-10-12T08:34:11.704: EXPIRED (5/5)
08:34:11.719 PktProtocolQos.send_data(0404| W|01:139901|0041): Expired callback
08:34:11.719 PktProtocolQos.send_data(7FFF| I|63:262142): boff=3, want=0404| I|01:139901|0041, tout=2021-10-12T08:34:11.704: EXPIRED (5/5)
08:34:11.720 PktProtocolQos.send_data(0404| W|01:139901|0041): Expired callback
08:34:11.720 Task exception was never retrieved
future: <Task finished name='Task-14' coro=<PacketProtocolQos.send_data() done, defined at /opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py:722> exception=AttributeError("'bool' object has no attribute 'payload'")>
Traceback (most recent call last):
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 787, in send_data
    _expired_cmd(self._qos_cmd)
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 741, in _expired_cmd
    callback[FUNC](False, *callback.get(ARGS, tuple()))
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/schedule.py", line 336, in tx_callback
    msg.payload.get(FRAG_INDEX),
AttributeError: 'bool' object has no attribute 'payload'
08:34:20.574 Blocking packets with device_id: 10:142568 (is not whitelisted), if required, add it to the known_list
08:34:41.194 Blocking packets with device_id: 34:112193 (is not whitelisted), if required, add it to the known_list
08:34:50.817 RQ --- 18:136712 10:142568 --:------ 3EF1 001 00 < There appears to be more than one HGI80-compatible device (active gateway: 18:134436), this is unsupported
08:34:50.817 Blocking packets with device_id: 18:136712 (is not whitelisted), if required, add it to the known_list
08:35:01.810 set_schedule(): Function timed out: The callback has expired: failed to set schedule (no hint)

client.py: Finished ramses_rf, results:


client.py: Finished ramses_rf.
 - ended without error (e.g. EOF)

08:35:01.810 Task exception was never retrieved
future: <Task finished name='Task-2' coro=<Gateway.start() done, defined at /opt/scripts/evohome/ramses_rf.master/ramses_rf/__init__.py:155> exception=AttributeError("'bool' object has no attribute 'payload'")>
Traceback (most recent call last):
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/__init__.py", line 188, in start
    await asyncio.gather(*self._tasks)
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/protocol.py", line 126, in pkt_dispatcher
    await call_send_data(cmd)
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/protocol.py", line 108, in call_send_data
    await self._dispatcher(cmd)  # send_data, *once* callback registered
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 787, in send_data
    _expired_cmd(self._qos_cmd)
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/transport.py", line 741, in _expired_cmd
    callback[FUNC](False, *callback.get(ARGS, tuple()))
  File "/opt/scripts/evohome/ramses_rf.master/ramses_rf/protocol/schedule.py", line 336, in tx_callback
    msg.payload.get(FRAG_INDEX),
AttributeError: 'bool' object has no attribute 'payload'

The test sched.jsn file contains:

{"schedule":[{"day_of_week":0,"switchpoints":[{"heat_setpoint":21.5,"time_of_day":"07:30"},{"heat_setpoint":22.5,"time_of_day":"10:10"},{"heat_setpoint":22.5,"time_of_day":"16:30"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"23:00"}]},{"day_of_week":1,"switchpoints":[{"heat_setpoint":21.5,"time_of_day":"07:30"},{"heat_setpoint":22.5,"time_of_day":"10:10"},{"heat_setpoint":22.5,"time_of_day":"16:30"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"23:00"}]},{"day_of_week":2,"switchpoints":[{"heat_setpoint":21.5,"time_of_day":"07:30"},{"heat_setpoint":22.5,"time_of_day":"10:10"},{"heat_setpoint":22.5,"time_of_day":"16:30"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"23:00"}]},{"day_of_week":3,"switchpoints":[{"heat_setpoint":21.5,"time_of_day":"07:30"},{"heat_setpoint":22.5,"time_of_day":"10:10"},{"heat_setpoint":22.5,"time_of_day":"16:30"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"23:00"}]},{"day_of_week":4,"switchpoints":[{"heat_setpoint":21.5,"time_of_day":"07:30"},{"heat_setpoint":22.5,"time_of_day":"10:10"},{"heat_setpoint":22.5,"time_of_day":"16:30"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"23:00"}]},{"day_of_week":5,"switchpoints":[{"heat_setpoint":20.0,"time_of_day":"07:30"},{"heat_setpoint":20.0,"time_of_day":"09:00"},{"heat_setpoint":22.5,"time_of_day":"11:10"},{"heat_setpoint":23.5,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"22:30"}]},{"day_of_week":6,"switchpoints":[{"heat_setpoint":20.0,"time_of_day":"07:30"},{"heat_setpoint":20.0,"time_of_day":"09:00"},{"heat_setpoint":22.5,"time_of_day":"11:10"},{"heat_setpoint":23.0,"time_of_day":"18:00"},{"heat_setpoint":5.0,"time_of_day":"21:50"}]}],"zone_idx":"00"}

Is it something I'm doing, or is this still a work in progress?

Many thanks!

ramses_rf won't run

Hi,

I'm trying to get ramses_rf running but still receiving the following error-messages when running
python client.py monitor /dev/ttyACM1 -o packet.log:

Output:
.......k:~/ramses_rf$ python client.py mopnitor /dev/ttyACM1 -o packet.log Traceback (most recent call last): File "/home/george/ramses_rf/client.py", line 49, in <module> from ramses_rf import Gateway, GracefulExit, Message File "/home/george/ramses_rf/ramses_rf/__init__.py", line 16, in <module> from .const import __dev_mode__ File "/home/george/ramses_rf/ramses_rf/const.py", line 9, in <module> from .protocol.const import ( # noqa: F401 File "/home/george/ramses_rf/ramses_rf/protocol/__init__.py", line 9, in <module> from .address import Address, is_valid_dev_id File "/home/george/ramses_rf/ramses_rf/protocol/address.py", line 14, in <module> from .helpers import typechecked File "/home/george/ramses_rf/ramses_rf/protocol/helpers.py", line 130, in <module> def timestamp() -> float: File "/home/george/.local/lib/python3.9/site-packages/typeguard/_decorators.py", line 213, in typechecked retval = instrument(target) File "/home/george/.local/lib/python3.9/site-packages/typeguard/_decorators.py", line 76, in instrument module_code = compile(module_ast, f.__code__.co_filename, "exec", dont_inherit=True) ValueError: empty body on ExceptHandler

I'vo followed the few steps listed on: https://github.com/zxdavb/ramses_rf
I'm running Linux iotstack 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux and Python 3.9.2.
With the SSM-D2 dongle running evofw3.

Am I missing something that keeps my setup from running?

Unknown code for 10:040239: RP/10E0

2021-01-24 18:06:05 ERROR (MainThread) [custom_components.evohome_cc.evohome_rf.message] 049 RP --- 10:040239 18:005567 --:------ 10E0 038 000001C8810B0700FEFFFFFFFFFF140807E35238383230000000000000000000000000000000 < AssertionError
Traceback (most recent call last):
  File "/config/custom_components/evohome_cc/evohome_rf/message.py", line 519, in process_msg
    update_entities(msg, msg._gwy._prev_msg)  # update the state database
  File "/config/custom_components/evohome_cc/evohome_rf/message.py", line 466, in update_entities
    this._gwy.device_by_id[this.src.id]._handle_msg(this)
  File "/config/custom_components/evohome_cc/evohome_rf/devices.py", line 711, in _handle_msg
    super()._handle_msg(msg)
  File "/config/custom_components/evohome_cc/evohome_rf/devices.py", line 221, in _handle_msg
    super()._handle_msg(msg)
  File "/config/custom_components/evohome_cc/evohome_rf/devices.py", line 354, in _handle_msg
    assert (
AssertionError: Unknown code for 10:040239: RP/10E0

The `01FF` payload is not fully understood

Don't know if this can be properly named an issue and if this the proper way of contacting you, but I'll do it anyway. Thanks for the great work you guys all did on ramses_rf

I've been analyzing my system with a indalo reciever on a raspberry pi using client.py. The system is a Spider (opentherm) room thermostat (21:033244), an Itho CVE box with built in CO2 and humidity sensor (37:053261) and a Spider gateway (18:010629). This consists of an HGI80 connected to an fifthplay gateway (home area manager) which in turn communicates with an external server from Itho Daalderop . (reason I'm doing this by the way is that itho daalderop will eventually end support, likely ~2024, ending time planning and remote control possibilities)

Using the gateway it is possible to have a weekplanner on the thermostat, I played around with the system through the app, changing the temperature and turning the time planning off and on. The gateway then sends a W|01FF message, the thermostat responds with an I|01FF message. (clearly this 01FF is not recognized by ramses_rf). I also logged the normal changes according to time planning (logged for 20+ hours). Finally, the thermostat sends a RQ|01FF with the same payload every ~9.5 min and gets a RP|01FF response.

I managed to figure out the following about this 01FF message:

Thermostat to gateway message:
057 RQ --- 21:033244 18:010629 --:------ 01FF 026 008026262A90008000143C28400000010480800280FF80070000
In the payload:

The third byte (26) is the currently displayed temperature x 2 (19 degrees C here)
Fourth byte (26) the set temperature - can be in/decreased by 0.5 degrees at a time
Fifth byte (2A) appears to be the max temp
(because it is consistently the same value as reported in 22C9 setpoint_bounds - temp high)
The sixth byte determines the state the thermostat is in - 90 when the time planning is active, B0 when the time planning is active, but the temperature was temporarily adjusted, and D0 when the time planning is deactivated

Gateway to thermostat message:
029 RP --- 18:010629 21:033244 --:------ 01FF 026 008080262692000000143C80800000310080800280FF80040000
In the payload:

Both the fourth and fifth byte appear to denote the temperature setpoint for the thermostat
The sixth byte determines the state the thermostat is to be in. It is 92 when the time planning is active, B2 when the time planning is active, but the temperature was temporarily adjusted and D2 when the time planning is deactivated.

Did not see any changes in any of the other bytes yet.

Hope you guys have time somewhere in the future to add this 01FF to the code of ramses_rf?

Attached the log of almost 24 hours. Also found a couple of other interesting messages:

The percentage in 3110 messages always increases when the central heating is on - I think it denotes the modulation of the heater
I also got these messages on the command line (I logged the command line output):

06:22:19.124  I 125 37:053261 --:------ 37:053261 31D9 017 00863C0E20202020202020202020202000 < Support the development of ramses_rf by reporting this packet (byte 3: 0E)
06:22:23.189  I --- 37:053261 --:------ 37:053261 3120 007 00F0B0010003FF < Support the development of ramses_rf by reporting this packet (byte 1: F0)
06:23:12.928  I --- 37:053261 --:------ 37:053261 3120 007 0070B00000F0FF < Support the development of ramses_rf by reporting this packet (byte 5: F0)
17:25:15.847  I --- 21:033244 63:262142 --:------ 10E0 038 00000100220B0001FEFFFFFFFFFF140107DF4343552D31325432300000000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 21:033244 (device type 21 not known to have signature: 000100220B0001FEFF)

test5.log

Unavailable state

Using home assistant, I noticed my climate.* entities became unknown overnight:

https://www.dropbox.com/s/t5rh2ee7dcni1bj/Screenshot%202021-06-23%20at%2007.48.00.png?dl=0

If you trigger a change, it seems to re-learn/update the correct state - so hopefully it's just a timeout or similar issue:

https://www.dropbox.com/s/5wdghka935rn0o3/Screenshot%202021-06-23%20at%2007.52.23.png?dl=0

The rest of the various sensors seem to be ok. Will capture some logs based on your request:

logger:
  default: warn
  logs:
    homeassistant.core: debug
    custom_components.evohome_cc: warn
    ramses_rf.transport: info

When a climate entity becomes unavailable, PM me the log:

cat homeassistant.log | grep -E '(climate|evohome|ramses)'

Help Wanted: Error codes support for Orcon RF15 display

The real RF15 display (Orcon RF15 display) has readout for error codes.

Can you implement these? I have the modbus addressed and error messages for the error codes if this helps.

Intergas RF (Ramses?)

rf_interface_ic3.txt
Hi,

according to the Intergas Diagnostic Software (IDS) the Intergas HRE / Xtreme HVAC systems are using some form of Ramses_II.
Definately for connecting a Honeywell thermostat. But when I sniff the connection with ramses_rf when coupled with the Intergas Incomfort gateway (Simple device, houses a PIC18F, some flash, network parts and a CC1101 in it) I don't see any packets.
There's is an undocumented extra exposed port (rj11 or rj12 or so) that does something but haven't figured out yet what it does.

So deep diving into the IDS (and some obvious magic later) I extracted attached code for the RF Dongle Intergas is using and the way it connects to the the CV. Can you perhaps look at it to see if it resembles something that can be integrated into ramses_rf?

Question

Hi. Amazing work you have done.
Do you know if the _flags_n have any useful purpose. I only ever see a value of FF?
Thanks

Exposure as Transport

Hi @zxdavb

Not an issue, but I'm the author of evogateway/listener - you may recall we had a brief chat a few months back in the automatedhome forum. I was wondering if you've had any further thoughts on exposing your library as a transport. No urgency!

Many thanks.

I --- 02:008366 --:------ 02:008366 22D0 004 0010000A < AssertionError

2023-06-25 16:20:20.387 ERROR (MainThread) [ramses_rf.protocol.message] I --- 02:008366 --:------ 02:008366 22D0 004 0010000A < AssertionError(Support the development of ramses_rf by reporting this packet)

seems to return every 15 minutes

configuration:
2x hce80
evotouch
4x honeywell round
2x relais to heatpump

no issue just helping development :-)
packet.log

Getting error in Hassio

I get now this error after the last update

Logger: ramses_rf.protocol.command
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py:151
First occurred: 9:16:35 AM (4 occurrences)
Last logged: 9:46:37 AM

validate_command(): get_dhw_params() takes 2 positional arguments but 3 were given
validate_command(): get_dhw_temp() takes 2 positional arguments but 3 were given
validate_command(): get_dhw_mode() takes 2 positional arguments but 3 were given
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 143, in _wrapper
    return fcn(*args, **kwargs)
TypeError: get_dhw_params() takes 2 positional arguments but 3 were given

client.py broken

Problem seems to have started at commit 981be83.

I am not sure why client.py is pulling in mock stuff from the test suite. That doesn't seem right.

(venv) bheading@glasnost:~/dev/ramses_rf$ python3 ./client.py
Traceback (most recent call last):
  File "/home/bheading/dev/ramses_rf/./client.py", line 47, in <module>
    from tests_rf.mock import MockGateway
  File "/home/bheading/dev/ramses_rf/tests_rf/mock/__init__.py", line 17, in <module>
    from .device_heat import (  # noqa: F401, F811, pylint: disable=unused-import
  File "/home/bheading/dev/ramses_rf/tests_rf/mock/device_heat.py", line 138, in <module>
    ZoneParamsT = dict[str, None | bool | float | int]
TypeError: unsupported operand type(s) for |: 'NoneType' and 'type'
(venv) bheading@glasnost:~/dev/ramses_rf$

0.30.0: Orcon 31D9 AssertionError

My Orcon SmartComfort zone valve (connected to the FAN, acts like a fan, can pair with remotes etc, so should be and is a FAN entity) sends a pair of 31D9 messages every 15 minutes:

2023-03-20T06:30:47.347397 066  I 123 32:132403 --:------ 32:132403 31D9 017 00-04030020202020202020202020202004
2023-03-20T06:30:47.442439 064  I 124 32:132403 --:------ 32:132403 31D9 017 01-04030020202020202020202020202004

Note that the second (always) has zone/idx 01. This throws an AssertionError in: https://github.com/zxdavb/ramses_rf/blob/master/ramses_rf/protocol/message.py#L219

I'm not sure how to fix this...

My ramses_cc config:

ramses_cc:
  serial_port: /dev/ttyACM0 # SSM-D2
  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: FAN}               # zone valve unit
    37:005302: {class: CO2}               # CO2 woonkamer
    37:005608: {class: CO2}               # CO2 slaapkamer
    37:171685: {class: DIS}               # RF15 display
[...]

zxdavb / ramses_rf Goto Github PK

ramses_rf's Introduction

Overview

Installation

ramses_rf's People

Contributors

Stargazers

Watchers

Forkers

ramses_rf's Issues

Recommend Projects

Recommend Topics

Recommend Org