The next big change to ramses_rf is to stop using device types (the 18: in 18:123456) - then HVAC. This issue is that HVAC, unlike CH/DHW doesn’t use device types consistently.
Weeks away.
Good spot! Now updating. Apologies if you’ve spent any time on this.
@zxdavb Could it be possible to get the flame state as a binary_sensor?
2021-11-29 07:08:52 INFO (MainThread) [ramses_rf.message] || OTB:040239 | CTL:223036 | RP | actuator_state | || {'modulation_level': 1.0, '_flags_0': '10', '_flags_3': [0, 0, 0, 0, 1, 0, 1, 0], 'ch_enabled': True, 'dhw_active': False, 'flame_active': True, '_unknown_4': '00', '_unknown_5': 'FF', '_flags_6': [0, 0, 0, 0, 0, 0, 1, 1], 'ch_active': True, 'ch_setpoint': 75, 'max_rel_modulation': 1.0}
Yes, I think it is best left for you to do, using a (binary) sensor template. Here is an example you can use as a start - put it in configuration.yaml:
sensor:
- platform: template
sensors:
fc_relay_demand:
friendly_name: "heating_control (relay_demand)"
unit_of_measurement: "%"
value_template: >-
{{ state_attr('climate.controller', 'relay_demands').FC * 100 }}
attribute_templates:
device_id: "{{ state_attr('binary_sensor', '01_054173_schema').system.heating_control }}"
However, the attribute you want should be available as a entity attribute, but I see it is not - this happened when I deprecated the RAMSES equivalent to OpenTherm’s relative modulation level.
I will fix this & let you know - when you get it working, perhaps you could add an entry to the Wiki?
I could add it to the wiki
Could please share the difference between heat and relay demand?
This template is also not working, will look into it
{{ state_attr('binary_sensor', '01_054173_schema').system.heating_control }}
this is works:
{{ state_attr('binary_sensor.01_054173_schema', 'schema').system.heating_control }}
Indeed, the warnings are repeated every 15 mins. Apart from the (meaningless?) heat_demand entity for the electric zone showing as Unavailable, my other errors have cleared and things are working well.
Oke so I had the system working and then i had to upgrade 
My configuration was using a second RPI with evofw3 stick linked to ser2net (port 3001) and Home Assistant had the line serial_port: rfc2217://192.168.1.70:3000
Which was working fine until I updated HA Core from 2021.11.4 → 2021.11.5
The error I’m seeing is:
2021-11-30 12:20:54 ERROR (MainThread) [ramses_rf.protocol.transport] Failed to open rfc2217://192.168.1.70:3000 (config: {‘xonxoff’: True, ‘rtscts’: False, ‘baudrate’: 115200, ‘timeout’: 0, ‘dsrdtr’: False}): Could not open port rfc2217://192.168.1.70:3000: timed out
File “/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py”, line 863, in create_pkt_stack
If I try a wrong port, I get this:
2021-11-30 13:10:01 ERROR (MainThread) [ramses_rf.protocol.transport] Failed to open rfc2217://192.168.1.70:3001 (config: {‘baudrate’: 115200, ‘xonxoff’: True, ‘rtscts’: False, ‘timeout’: 0, ‘dsrdtr’: False}): Could not open port rfc2217://192.168.1.70:3001: [Errno 111] Connection refused
Also I found
Telnet to this port from another device is working and nothing changed on that side
Any pointers where to look?
Weird it just started to work again after a reboot number 10 
Care to share you ser2net setup?
Nice job. The HCW82 battery_low state is now working
ser2net is not officially supported- it will mess with the subtleties of timings - you would expect more re-transmits.
This is the ser2net.yaml I use when I am inclined:
# HGI80-like ser2net connection that allows multiple connections
connection: &con00
accepter: telnet(rfc2217),tcp,5001
timeout: 0
connector: serialdev,/dev/ttyUSB0,115200n81,local
options:
max-connections: 3
This is the corresponding configuration.yaml:
evohome_cc:
serial_port:
port_name: rfc2217://localhost:5001
1 Like
@zxdavb I use a similar ser2net config.
Just wondering why the timeout 0?
By the way if anyone has the problem that ser2net is not ready for connections after a reboot on a rpi.
That is because it is starting before the network stack and cannot create the socket therefore.
I managed to fix that, I’ll try to post the fix I did tomorrow.
On another note: the nanocul with external antenna came in and the average rssi’s dropped by 10 points with out tuning. After tuning they improved even a little more.
So I’m happy for now.
Next up experimenting with the bluetooth temperature sensor linked to a fake evohome sensor.
But first my bluetooth sensor config needs to be stable. need to keep the w.a.f. high, she is already not happy she cannot burn candles or place flowers with ice-cold water next to the controller 
without the heating going crazy.
Necessary for development (to reduce timing errors), but maybe not required for production.
I would like to drop a new version this weekend - are there any bugs?
Nothing that comes to mind.
Enhancement suggestion for the future would be to include in the schema if a zone if multi or single room.
ramses_rf tracks 3 classes of attributes (variables):
schema: read-only (or objects needing to be deleted/re-created to re-configure)params: configurable things (parameters)status: state of things
Examples would be:
schema: zone sensors, number of zonesparams: single/multi room mode, min/max zone setpoint, DHW setpointstatus: zone temperature, window_open detected
Some of these attributes are a bit grey - they fit between the two, so I have made a call on each of them:
- zone_setpoint is status (and not
params) - zone_type is schema (and not
params)
Currently, params are not exposed in evohome_cc - this is planned.
1 Like
All fine on my side. I still don’t have data from the UFH zones, but I am pretty sure this is a problem of reception (my dongle is too far from my UFH antenna).
All the rest seems to work as expected 
Minor niggle, certainly not high priority, and I don’t know if the problem is in the integration or core.
If I edit an existing automation that calls evohome_cc.set_dhw_mode using HA Configuration->Automations (as opposed to a file editor), it loses settings for duration.
This is the code before:
- id: DHW_Fri-Sat
alias: DHW Late Night Friday Saturday
description: ''
trigger:
- platform: time
at: '22:55'
condition:
- condition: state
entity_id: water_heater.stored_hw
attribute: operation_mode
state: auto
- condition: time
weekday:
- fri
- sat
action:
- service: evohome_cc.set_dhw_mode
data:
mode: temporary_override
active: true
duration:
minutes: 15
mode: single
And then after editing
- id: DHW_Fri-Sat
alias: DHW Late Night Friday Saturday
description: ''
trigger:
- platform: time
at: '22:55'
condition:
- condition: state
entity_id: water_heater.stored_hw
attribute: operation_mode
state: auto
- condition: time
weekday:
- fri
- sat
action:
- service: evohome_cc.set_dhw_mode
data:
mode: temporary_override
active: true
mode: single
16.26 looks good. Only thing in my logs are this warning.
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:786
First occurred: 19:15:29 (632 occurrences)
Last logged: 20:43:44
PktProtocolQos.send_data(sent=3220|RQ|10:051349|00): boff=1, want=3220|RP|10:051349|00, tout=2021-12-05T20:43:42.743: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:051349|11): boff=1, want=3220|RP|10:051349|11, tout=2021-12-05T20:43:43.145: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:051349|13): boff=1, want=3220|RP|10:051349|13, tout=2021-12-05T20:43:43.761: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:051349|19): boff=1, want=3220|RP|10:051349|19, tout=2021-12-05T20:43:44.165: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:051349|1C): boff=1, want=3220|RP|10:051349|1C, tout=2021-12-05T20:43:44.863: QoS: IS_EXPIRED (giving up) (0/0)
I do not get this error in my system.
Is this a one-off, or does it happen for every restart of HA?
You’re not suddenly using ser2net are you?
Any idea when the flame state will be added as a sensor?