Errors for my electric zone are gone in 0.16.23. I had a couple of protocol warnings but could be corruption; I’ll keep my eyes on it tomorrow.
RQ --- 18:204306 01:225826 --:------ 0008 001 08 < Corrupt payload: Payload doesn't match '^00$': 08 (will be ignored)
RQ --- 18:204306 01:225826 --:------ 0008 001 08 < Corrupt packet: Invalid verb/code for 01:225826 to Rx: RQ/0008 (will be ignored)
No, this is a bug.
Saw this in the logs today. Unfortunately no logging turned on, so this is probably of little use to you. (0.16.23)
WARNING (MainThread) [homeassistant.helpers.entity] Updating state for binary_sensor.04_003278_battery_low (<class 'custom_components.evohome_cc.binary_sensor.EvoBattery'>) took 0.415 seconds. Please report it to the custom component author.Well, it appears the 0.16.x ride may be nearing its end…
I think I can reasonably recommend people run it, instead of earlier releases.
Can anyone with UFH please send me the schema from your 01:xxxxxx (schema) entity, as well as your configuration.yaml, and a packet log that includes a start of HA.
I also need to know if the zone has a heat demand at all.
I do not have any UFH to dev/test against, so I’ll need your help.
I am hoping to get heat demand working for all zone types, before the next big change. so that people can stay on 0.16.x while 0.17.x goes through its cycle.
The next version will include another large refactor, so that HVAC devices can be supported (they do not respect the device type rule that CH/DHW devices do).
Hmmm… seems a bit arbitrary - I may just ignore it for now (but it is on Main thread, so you must let me know if it happens again).
Any chance we could try and track down my missing radiator sensor? This one has never appeared since day one. What level of logging would you need?
@Lloyd Can you please check that you haven’t disabled it in HA?
Look in the HA menu: Configuration // Entities, and enable Show disabled entities.
The relevant logging is:
logger:
logs:
custom_components.evohome_cc.sensor: info
You are looking for this entry in your HA logs:
INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temperature), unique_id=04:026298-temperature
Let me know what you see.
In principle, this shouldn’t be required - first, always try without doing this.
The schema in in 01 sensor is:
schema:
system:
heating_control: null
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Woonkamer
heating_type: underfloor_heating
sensor: null
devices: []
_sensor: null
_actuators: []
'01':
_name: Slaapkamer
heating_type: underfloor_heating
sensor: '34:247739'
devices:
- '34:247739'
_sensor: '34:247739'
_actuators: []
'02':
_name: Garage
heating_type: radiator_valve
sensor: '04:113257'
devices:
- '04:113257'
_sensor: '04:113257'
_actuators:
- '04:113257'
'03':
_name: Voorzolder
heating_type: underfloor_heating
sensor: '34:247741'
devices:
- '34:247741'
_sensor: '34:247741'
_actuators: []
'04':
_name: Badkamer
heating_type: underfloor_heating
sensor: '34:148939'
devices:
- '34:148939'
_sensor: '34:148939'
_actuators: []
'05':
_name: Babykamer
heating_type: underfloor_heating
sensor: '34:247919'
devices:
- '34:247919'
_sensor: '34:247919'
_actuators: []
'06':
_name: Scrapkamer
heating_type: underfloor_heating
sensor: '34:247743'
devices:
- '34:247743'
_sensor: '34:247743'
_actuators: []
'07':
_name: Zolder Zuid
heating_type: underfloor_heating
sensor: '03:256021'
devices:
- '03:256021'
_sensor: '03:256021'
_actuators: []
'08':
_name: Zolder Noord
heating_type: underfloor_heating
sensor: '03:256004'
devices:
- '03:256004'
_sensor: '03:256004'
_actuators: []
My own config is:
serial_port:
port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: packet.log
restore_state: true
ramses_rf:
# disable_discovery: true
# enable_eavesdrop: true
enforce_known_list: false
max_zones: 9
schema:
system:
heating_control: "10:050360"
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
"00":
_name: Woonkamer
heating_type: underfloor_heating
sensor: null
devices:
- "02:044435"
"01":
_name: Slaapkamer
heating_type: underfloor_heating
sensor: "34:247739"
devices:
- "02:044446"
"02":
_name: Garage
heating_type: radiator_valve
sensor: "04:113257"
devices:
- "04:113257"
"03":
_name: Voorzolder
heating_type: underfloor_heating
sensor: "34:247741"
devices:
- "02:044328"
"04":
_name: Badkamer
heating_type: underfloor_heating
sensor: "34:148939"
devices:
- "02:044446"
"05":
_name: Babykamer
heating_type: underfloor_heating
sensor: "34:247919"
devices:
- "02:044446"
"06":
_name: Scrapkamer
heating_type: underfloor_heating
sensor: "34:247743"
devices:
- "02:044446"
"07":
_name: Zolder Zuid
heating_type: underfloor_heating
sensor: "03:256021"
devices:
- "02:044328"
"08":
_name: Zolder Noord
heating_type: underfloor_heating
sensor: "03:256004"
devices:
- "02:044328"
known_list:
- "03:256021": { faked: true }
- "03:256004": { faked: true }
block_list:
- 10:037879
- 37:258565
- 37:261128
- 12:228610
- 20:010779
- 20:036714
- 29:151550
- 29:237552
- 37:011523
- 37:017639
- 37:053679
- 37:070351
_is_evofw3: true
Is added UFH ids to the devices as it was not working without and saw your suggestion to @bluediamond84. That isn’t picked up. Starting with restore_state: false doesn´t help either, as you pointed out already (but after I tried).
I will provide the packet.log via dm.
@llevering @bishop I have released 0.16.24 that has UFH-specific changes - please use that & send me a packet log that includes a restart of HA when you can.
I have updated the schema output, so you’ll have to resend that too.
Can the person who had a HVAC ventilator with a device_id starting with an 18: please PM me.
How’s the HVAC side coming along?
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