Reset/rebind does not change the behaviour. Curious to see if others with HR80’s have a similar experience or not.
Agree that discovering an authoritative schema, to be in line with the controller, is a good thing, but if the controller does not expose all the devices it talks to…
tried combos and got it to deploy, thanks for the tip!
Now I only seein evopacket.log
2021-03-23T20:25:33.380864
2021-03-23T20:28:02.622186
and lots like this in homeassistant.log
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 000A)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 000A): no dispatcher
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.get_write_buffer_size()
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 000B)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 000B)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 000B): no dispatcher
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.get_write_buffer_size()
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 0011)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 0011)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:138490 --:------ 0005 002 0011): no dispatcher
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport.get_write_buffer_size()
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.pause_writing()
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 0000)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 0004)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 000C)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 000F)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0005 002 0010)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 2E04 001 FF)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 0100 001 00)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgProtocol.send_data(RQ --- 18:000730 01:138490 --:------ 1F09 001 00)
2021-03-23 20:28:02 DEBUG (MainThread) [evohome_rf.protocol] MsgTransport._set_dispatcher(<bound method PacketProtocolQos.send_data of <evohome_rf.transport.PacketProtocolQos object at 0x7f2dd8ef75e0>>)
I think I broke this - will have a look at it when I can. Sorry - working 12h days vaccinating!
That makes no sense.
The build baudrate option controls the speed of the host link in the evofw3 FW.
The only difference between ‘standard’ and ‘old’ bootloader is the speed the bootloader uses to communicate with the host when updating the FW. there is no difference with the downlaoded FW.
With an atmega328 platform this suggests that the cc1101 has not completed initialisation. You should always see the evofw3 version string in packet.log.
I’m not entirely sure about atmega32u4 behaviour with evohome cc. @zxdavb hasn’t been able to test and there is different behaviour.
atmega328p ALWAYS resets on serial port open. The atmega32u4 doesn’t do this.
Its really weird 
and indeed doesn’t make sense, but its what worked for me. maybe a dodgy board. BTW no issues encountered with 0.7.0
Does anyone have a configuration file that has an allow_list or a block_list that is being successfully processed by evohome_cc. Could you please post it here as an example
Full config:
evohome_cc:
scan_interval: 60
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
serial_config:
baudrate: 57600 # default: 115200
config:
packet_log: /config/packet.log
enforce_allowlist: True
max_zones: 8
schema:
controller: 01:xxxxxx
allow_list:
- 01:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 07:xxxxxx
- 13:xxxxxx
- 13:xxxxxx
- 22:xxxxxx
- 22:xxxxxx
- 22:xxxxxx
# block_list:
Using a nanoCUL, with 0.7 version of the firmware, evohome_cc 0.6.6 (plus patches) so not the latest I’m afraid.
With the official evohome integration on an zone you have an hvac mode heat and off, is it possible to add this in this version?
Now you can only set the controller on off but not one zone.
My configuration file has the enforce allow_list and the allow_list. But I still get a message in the log saying that no device filter has been applied. I see the same issue reported a few posts earlier.
I am using
evohome_cc v0.7.1, using evohome_rf v0.7.1 - versions match (this is good)
And get
Logger: evohome_rf.schema
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/schema.py:256
First occurred: 25 March 2021, 17:22:46 (1 occurrences)
Last logged: 25 March 2021, 17:22:46
An empty allowlist was configured, so will be ignored
Logger: evohome_rf.transport
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/transport.py:323
First occurred: 25 March 2021, 17:22:46 (1 occurrences)
Last logged: 25 March 2021, 17:22:46
Not Using an device filter (an allow_list is recommended)
All,
There are some issues with functionality, such as:
allow_list / enforce_allow_listserial_configA fix is on it’s way for these - expect them by Sunday - bare with me.
Maybe - I will be having a think about how to best do this.
In the meantime: All the native evohome modes are available in each entity’s attributes (device_state_attributes) and service calls - that is a better option, certainly for automatiions, and - if you’re willing - bespoke Lovelace UIs.
Fixed!
I tried after rebooting my (windoze) PC and Arduino IDE seemed to work that time!.
Now running evfw3 0.7.0 and all seems well…
Could someone share an automation for a service call if the DHW relay sensor changes state?
I have just pushed v0.7.5 - it includes many, many fixes, several tweaks, and a complete re-write of the configuration of evohome_cc (and thus evohome_rf).
The allow_list functionality should be fixed (or at least in a state where I can fix it):
evohome_cc:
serial_port: /dev/ttyUSB0
packet_log: packet.log
allow_list:
- 01:145038
- 04:056053
- 13:056057
And also:
evohome_cc:
serial_port:
port_name: /dev/ttyUSB
baudrate: 57600
packet_log: packet.log
Please check out this handy guide !!
I am not intending to refactor this again, so things should be stable now.
Can anyone with an OpenTherm bridge tell me what they can see of their bridge in HA:
"10:123456": {
"actuator_cycle": null,
"actuator_state": {
"actuator_enabled": false,
"modulation_level": 0.0,
"flame_active": false,
"dhw_active": false,
"ch_enabled": false
},
"boiler_setpoint": 10.0,
"modulation_level": 0.0,
"opentherm_status": {
"boiler_temp": 42.0,
"ch_pressure": 25.5,
"dhw_flow_rate": null,
"dhw_temp": null,
"rel_modulation_level": 0.0,
"return_cv_temp": 41.0
}
},
'10:022270': {
'actuator_cycle': None,
'actuator_state':
{
'actuator_enabled': False,
'modulation_level': 0.0,
'flame_active': False,
'dhw_active': False,
'ch_enabled': True,
'ch_active': True,
'ch_setpoint': 27,
'max_rel_modulation': 100},
'boiler_setpoint': None,
'modulation_level': 0.0,
'opentherm_status':
{
'boiler_temp': None,
'ch_pressure': None,
'dhw_flow_rate': None,
'dhw_temp': None,
'rel_modulation_level': None,
'return_cv_temp': None
}
}
}
Also getting this error appearing:
Logger: asyncio
Source: custom_components/evohome_cc/__init__.py:167
First occurred: 9:11:36 (8 occurrences)
Last logged: 9:18:36
Unhandled error in exception handler context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'"), 'future': <Task finished name='Task-7076' coro=<EvoBroker.async_update() done, defined at /config/custom_components/evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Unhandled error in exception handler context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'"), 'future': <Task finished name='Task-7496' coro=<EvoBroker.async_update() done, defined at /config/custom_components/evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Unhandled error in exception handler context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'"), 'future': <Task finished name='Task-7858' coro=<EvoBroker.async_update() done, defined at /config/custom_components/evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Unhandled error in exception handler context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'"), 'future': <Task finished name='Task-8248' coro=<EvoBroker.async_update() done, defined at /config/custom_components/evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Unhandled error in exception handler context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'"), 'future': <Task finished name='Task-8597' coro=<EvoBroker.async_update() done, defined at /config/custom_components/evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1744, in call_exception_handler
self._exception_handler(self, context)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/__init__.py", line 130, in handle_exception
raise exc
File "/config/custom_components/evohome_cc/__init__.py", line 167, in async_update
_LOGGER.info("Devices = %s", {d.id: d.status for d in self.client.devices})
File "/config/custom_components/evohome_cc/__init__.py", line 167, in <dictcomp>
_LOGGER.info("Devices = %s", {d.id: d.status for d in self.client.devices})
File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 837, in status
self.BOILER_SETPOINT: self.boiler_setpoint,
File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 808, in boiler_setpoint
return self._msgs["22D9"].payload[self.BATTERY_LOW]
Not sure what you wanted to see. Note this uses custom firmware for the Opentherm Gateway.
alias: Hot Water - State - Change - On
description: Disable weather compensation
trigger:
- platform: state
entity_id: binary_sensor.hot_water_actuator
to: 'on'
condition: []
action:
- service: opentherm_gw.set_outside_temperature
data:
gateway_id: boiler
temperature: 99
- service: opentherm_gw.set_max_modulation
data:
gateway_id: boiler
level: 100
mode: single
I have just pushed v0.7.6 which addresses this KeyError:
evohome_cc/__init__.py:164> exception=AttributeError("'OtbGateway' object has no attribute 'BATTERY_LOW'")>}
Thanks. Just noticed nothing is refreshing beyond the initial discovery values with 0.7.5?