@scstraus Your best chance is to provide evohome_rf logs of the relevant time window (from before until after this strange event) the answer (if any) will be in there.
Okay, will PM them to you… I suspect it was a comms fault that appeared to be due to a low battery in a different zone. But time will tell.
EDIT: darn, looks like the HGI-80 wasn’t running because I unplugged it to plug something else into the USB port. I will have to get it going again in case I have the problem more, but about 8 hours after changing the battery in the room which was low, I stopped having this problem in this room… We will see.
I have just added my 10th zone which is a Honeywell round controlling 2x HR92. One other zone is controlled by the main unit and all other zones are just HR92’s. Adding all these zones was done over a couple of weeks and each new zone nicely popped up in HAss.Maybe after a restart was needed but they always would show up.
Now this last added zone (the one with the Honeywell Round) does NOT show up in HASS.
Any idea?
I think you mean you added a 10th zone, controlled by the evohome controller, with the TR87 as a sensor (a thermostat)?
Does it show up in the TCC website app as a 10th Zone? If so, I will need logs.
Yes correct. The TR87 is the sensor for that zone.
It all works fine in the connected home app and Evohome controller.
Happy to send you logs. Sorry for asking this but a) where can I find the logs for Evohome specific and b) how would you like to get them?
Look here: https://www.home-assistant.io/docs/configuration/troubleshooting/
Try something similar to:
grep evohome ~/home-assistant/.config/home-assistant.log | head -n 100
If you can’t see anything in the log, then try adding this to your configuration.yaml:
logger:
logs:
homeassistant.components.evohome: debug
homeassistant.components.climate.evohome: debug
homeassistant.components.water_heater.evohome: debug
Finally, submit an issue here: https://github.com/home-assistant/core/issues - select core.
hey!
not sure if i have done something wrong, however i cant seem to call the service for the hot water?
YAML
evohome:
username: !secret EvoHomeUserName
password: !secret EvoHomePassword
ive tried the following but neither seem to work.
water_heater.turn_on
water_heater.turn_on
entity_id: entity_id: water_heater.dhw_controller
i get this error too
AttributeError: ‘EvoDHW’ object has no attribute ‘async_turn_on’
2020-10-24 16:03:32 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.548354343312] 'EvoDHW' object has no attribute 'async_turn_on'
If I tell you the answer - will you update the docs for me? 
Or at least submit an issue here
async def async_set_operation_mode(self, operation_mode: str) -> None:
"""Set new operation mode for a DHW controller.
Except for Auto, the mode is only until the next SetPoint.
"""
if operation_mode == STATE_AUTO:
await self._evo_broker.call_client_api(self._evo_device.set_dhw_auto())
else:
await self._update_schedule()
until = dt_util.parse_datetime(self.setpoints.get("next_sp_from", ""))
until = dt_util.as_utc(until) if until else None
if operation_mode == STATE_ON:
await self._evo_broker.call_client_api(
self._evo_device.set_dhw_on(until=until)
)
else: # STATE_OFF
await self._evo_broker.call_client_api(
self._evo_device.set_dhw_off(until=until)
)
async def async_turn_away_mode_on(self):
"""Turn away mode on."""
await self._evo_broker.call_client_api(self._evo_device.set_dhw_off())
async def async_turn_away_mode_off(self):
"""Turn away mode off."""
await self._evo_broker.call_client_api(self._evo_device.set_dhw_auto())
sure, happy to open an issue, didnt want to do that if it wasnt a problem however 
Sorry - I should have been clear - the functionality is there, but it’s not clear in teh docs how to get what you want - the issue should be here to fix the docs
However, the service calls you use could equally be added…
Use:
water_heater.set_operation_mode
and
water_heater.set_away_mode
instead.
1 Like
Hi David,
I’m getting a new error any time I try to change the temperature of a zone in lovelace since .117.1. It is:
Unable to call service climate/set_temperature. Coroutine not allowed to be passed to HassJob
Here’s the traceback. Should I open an issue?
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1448, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1483, 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 482, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 519, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 544, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/evohome/climate.py", line 241, in async_set_temperature
await self._evo_broker.call_client_api(
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 434, in call_client_api
self.hass.helpers.event.async_call_later(1, self.async_update())
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1160, in async_call_later
return async_track_point_in_utc_time(
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1134, in async_track_point_in_utc_time
job = action if isinstance(action, HassJob) else HassJob(action)
File "/usr/src/homeassistant/homeassistant/core.py", line 174, in __init__
raise ValueError("Coroutine not allowed to be passed to HassJob")
ValueError: Coroutine not allowed to be passed to HassJob
This is the fix:
2 Likes
Wow, can’t beat that! Thanks!
I’ve noted a curious anomaly. I suspect it is the Evohome API and not HA, but I wondered if anyone else has experienced this.
If I place the Evohome in to “Away” mode I can issue the following 2 x Evohome service commands and they work fine:
- action:
- service: evohome.set_zone_override
data:
entity_id: climate.loungeroom
setpoint: 10
and
- action:
- service: evohome.clear_zone_override
data:
entity_id: climate.loungeroom
However if you send:
- action:
- service: evohome.set_zone_override
data:
entity_id: climate.loungeroom
setpoint: 10
duration: 00:05:00
The first part of the command is actioned, but when the system is in “Away” the duration is ignored?
It works fine when Evohome is in “Auto” mode.
This is from another forum, but some people may find it interesting. The question was:
Question:
Does anyone know how I can plot the scheduled temperature, as opposed to the temperature being requested by the controller? With optimum start and stop enabled, the requested temperature will start and end before the scheduled ones. I have the Total Connect Comfort (Europe) integration…
Answer:
HA’s evohome integration already tracks the current setpoint (called temperature, and/or: status.setpoint_status.target_heat_temperature), and the scheduled setpoint (status.setpoints.this_sp_temp).
Have a look in Lovelace (the Web UI); Developer Tools; States, and select one of your zones (e.g. climate.bathroom), and you’ll see them.
You can set up custom sensors for these:
sensor:
- platform: template
sensors:
bathroom_actual:
friendly_name: "Bath Actual Setpoint"
unit_of_measurement: '°C'
value_template: >
{% if state_attr('climate.bathroom', 'status') -%}
{{ state_attr('climate.bathroom', 'status').setpoint_status.target_heat_temperature }}
{%- endif %}
bathroom_scheduled:
friendly_name: "Bath Scheduled Setpoint"
unit_of_measurement: '°C'
value_template: >
{% if state_attr('climate.bathroom', 'status') -%}
{{ state_attr('climate.bathroom', 'status').setpoints.this_sp_temp }}
{%- endif %}
…and then just graph sensor.bathroom_scheduled, sensor.bathroom_actual, etc.
Or you could even just graph the difference between the two:
{{
state_attr('climate.bathroom', 'status').setpoint_status.target_heat_temperature
-
state_attr('climate.bathroom', 'status').setpoints.this_sp_temp
}}
Thanks David!
sorry been manic and just looking at this again.
I assume my options for when i set operation mode are either “on” “off” or “auto” as per the image?
Be careful - an away mode in minutes doesn’t make sense - it has to be days. IIRC, 1 day is until the end of today, two days is the end of tomorrow. Is that the cause of what you’re seeing?
Have a look in the evohome UI, you’ll see what I mean.
Having said that, the HA integration provdes a superset of what the controller will allow you to do - and evohome_rf even has some additional modes:
- zones have two extra modes, one is until the next scheduled setpoint change (I think this is called advance)
- the system as a whole has some too, but I forget now
The evohome.set_zone_override zone override command only accepts hours as per the documentation:
“The duration can be up to 24 hours, after which the zone mode will revert to schedule ( FollowSchedule ). If the duration is 0 hours, then the change will be until the next setpoint.”
and that works.
I would not have thought putting the system in to Away (which accepts days) would affect this commands duration which requires hours.
@imellor I wrote that documentation 
There are no guarantees that it matches reality, although our chances are good, and I’m glad someone is reading it.
It took me ages to get those service calls working in HA - complicated by TZ issues (and naive datetimes, etc.), so there is a chance things don’t work as documented. Note: the HA service calls provide a superset of what’s available in the controller UI.
Broadly: the system (controller) mode can ‘influence’ (overrule) the setpoint of any/all zone in FollowSchedule mode. Under certain circumstances, it can also influence those zones in TemporaryOverride mode, and - in one particular circumstance - even those zones in PermanentOverride mode!
TIP: the three modes, above, are the only zone modes, and all other modes are system modes.
Don’t ask me for the details of the middle case, but the latter case is for AutoWithReset, IIRC.
Whether the zone has minutes, hours, etc. left before it automatically reverts from
TemporaryOverridetoFollowSchedulemode, and how long the system has remaining of its mode before it automatically reverts toAutois irrelevant (although there may be clear patterns). In all cases, the usual rules of influence apply.
In Auto mode the controller lets zones do their own thing (i.e. follow their schedule), and the setpoint is only influenced by the various optimizations (I think there are 3 different sets of optimizatins/scaling now), and the open window mode.
I think the lesson is that evohome is pretty complicated, and the latest firmware even more so - this is why the actual setpoint, and the scheduled setpoint can be different, even for zones in FollowSchedule mode.