@phdelodder Can you edit manifest.yaml to say (14 instead of 13):
"requirements": [
"evohome-rf==0.5.14", "pyserial-asyncio==0.5"
],
and try again.
I had the same errors, ignoring the version mismatch now looks much better.
it seems to be fixed!
@zxdavb. Thanks for working on dhw, I’ve updated this morning I can confirm its working perfectly.
I can finally decommission my really old and very out of date home assistant which I used to turn the dhw on out of schedule.
Have you had a chance to look at the 3 zones that reports no devices?
@hamba I am so sorry - I had a large number of logs sent to me at one time, and maybe missed responding…
You you want to restart HA, and send me a HA log, and a packet log pair? That way I can take a view if it is a bug, or an issue with your system.
The latest log I have from you - 2021-02-26 - did not did capture a a startup - and so is not usefule.
Can do, I’ll blank the packet log and restart and let it run for a bit.
Here is a nice example of a misconfigured system - in this case, some zones have TRVs as sensors, but not as actuators. Have a look at this fragment of the schema (Zone 0A has no actuator):
"09": {
"heating_type": "radiator_valve",
"sensor": "04:017016",
"devices": ["04:017016"]
},
"0A": {
"heating_type": "radiator_valve",
"sensor": "04:016926",
"devices": []
In 3 instances (zones 0x04, 0x08, 0x0A), you’ll have to add the TRV to the corresponding zone:
(venv) dbonnes@vm-builder ~/c/evohome (master)> cat .secrets/packet-20210305.log | python client.py parse | grep RP | grep rad_actuators
14:29:52.092 Not Using an device filter (an allow_list is recommended)
14:29:52.093 PktProtocol.pause_writing()
14:29:52.093 # evohome_rf 0.5.14
13:38:21.809 || CTL:102458 | HGI:009874 | RP | zone_devices | 00080... || {'zone_idx': '00', 'device_class': 'rad_actuators', 'devices': ['04:017066', '04:017068']}
13:38:23.430 || CTL:102458 | HGI:009874 | RP | zone_devices | 01080... || {'zone_idx': '01', 'device_class': 'rad_actuators', 'devices': ['04:017072']}
13:38:24.123 || CTL:102458 | HGI:009874 | RP | zone_devices | 02080... || {'zone_idx': '02', 'device_class': 'rad_actuators', 'devices': ['04:017020', '04:017018']}
13:38:24.597 || CTL:102458 | HGI:009874 | RP | zone_devices | 03080... || {'zone_idx': '03', 'device_class': 'rad_actuators', 'devices': ['04:017022', '04:017070']}
13:38:25.039 || CTL:102458 | HGI:009874 | RP | zone_devices | 04087... || {'zone_idx': '04', 'device_class': 'rad_actuators', 'devices': []}
13:38:25.488 || CTL:102458 | HGI:009874 | RP | zone_devices | 06080... || {'zone_idx': '06', 'device_class': 'rad_actuators', 'devices': ['04:016934']}
13:38:25.884 || CTL:102458 | HGI:009874 | RP | zone_devices | 07080... || {'zone_idx': '07', 'device_class': 'rad_actuators', 'devices': ['04:178853', '04:016930']}
13:38:26.272 || CTL:102458 | HGI:009874 | RP | zone_devices | 08087... || {'zone_idx': '08', 'device_class': 'rad_actuators', 'devices': []}
13:38:26.652 || CTL:102458 | HGI:009874 | RP | zone_devices | 09080... || {'zone_idx': '09', 'device_class': 'rad_actuators', 'devices': ['04:017016']}
13:38:28.013 || CTL:102458 | HGI:009874 | RP | zone_devices | 0A087... || {'zone_idx': '0A', 'device_class': 'rad_actuators', 'devices': []}
This:
{'zone_idx': '0A', 'device_class': 'zone_actuators', 'devices': []}
should be saying something like:
{'zone_idx': '0A', 'device_class': 'zone_actuators', 'devices': ['04:016926']}
In this case, the heat demand requested by those TRVs would not have influenced the heat demand requested from the boiler by the controller.
My point is - mis-configured evohome systems are every common - Honeywell have no tool that can check a configuration (there was a tool from a 3rd party, years ago, but is no longer available) - evohome_rf provides the means to do so, just check the schema.
@hamba (and others):
This may be worth trying - add the following to you configuration.yaml
sensor:
- platform: template
sensors:
fc_heat_demand:
friendly_name: "FC Heat Demand"
unit_of_measurement: "%"
value_template: "{{ state_attr('climate.controller', 'heat_demands').FC }}"
fc_relay_demand:
friendly_name: "FC Relay Demand"
unit_of_measurement: "%"
value_template: "{{ state_attr('climate.controller', 'relay_demands').FC }}"
Note: you can do this for F9, FA and FC (and even FD?), see:
Status[01:123456 (evohome)] = {
"system": {
"heat_demand": 0.0,
"heat_demands": {
"FC": 0.0
},
"relay_demands": {
"F9": 0.0,
"FC": 0.0,
"FA": 0.0
},
},
...
I expect you to have heat_demand for FC only and relay_demand for all three.
Then graph these values & let us know what you learn - I am interested in learning which of the relay demands match the FC_heat_demand.
This may help people -
For relay_demand, 0008:
> cat .secrets/*.log | grep -E ' 0008 ... F9' | wc -l
1509
> cat .secrets/*.log | grep -E ' 0008 ... FA' | wc -l
1123
> cat .secrets/*.log | grep -E ' 0008 ... FC' | wc -l
1122
> cat .secrets/*.log | grep -E ' 0008 ... F[8BDEF]' | wc -l
0
and for heat_demand, 3150:
> cat .secrets/*.log | grep -E ' 3150 ... F9' | wc -l
0
> cat .secrets/*.log | grep -E ' 3150 ... FA' | wc -l
0
> cat .secrets/*.log | grep -E ' 3150 ... FC' | wc -l
1245
> cat .secrets/*.log | grep -E ' 3150 ... F[8BDEF]' | wc -l
0
I have just pushed v0.5.14 - can anyone with an OpenTherm Bridge please send me a log pair from startup of HA, until 10 minutes after that.
David what do you mean by log pair?
The Home Assistant log file, and the packet log file.
The packet log file may be enough, for now.
I am aiming to increase support for the OTB in HA.
OK, I’ll send you a link shortly.
I have an OpenTherm Bridge:
Here are the log files: https://drive.google.com/file/d/10razr_xP7dUaMzDwJduU5BUhzgQFV_3-/view?usp=sharing
Just noticed:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 446, in async_set_preset_mode
await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/evohome_cc/climate.py", line 212, in set_preset_mode
self._evo_device.cancel_override()
AttributeError: 'RadZone' object has no attribute 'cancel_override'
When trying the renewed modes:
2021-03-06 08:01:46 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139851780125648] 00
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 446, in async_set_preset_mode
await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/evohome_cc/climate.py", line 255, in set_preset_mode
self._evo_device.reset_mode()
File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 835, in reset_mode
return self.set_mode(mode="follow_schedule")
File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 826, in set_mode
cmd = Command.set_zone_mode(self._ctl.id, self.idx, mode, setpoint, until)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/command.py", line 516, in set_zone_mode
assert mode in ZONE_MODE_LOOKUP, mode
AssertionError: 00
1 Like
Also seeing the above on latest release - think open window sensors may also be broken (showing unavailable after some hours still)
Have gone back to 0.5.10 to seemingly resolve both issues.
Hi! I was wondering:
Is this HA plug-in capable of managing two evohome systems through one HGI-80?
(My setup at home 
)