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.
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:
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.
I think I have the answer for you.
When you says the first part, do you mean the target temp, but not the duration. If so, what happens when you switch the system back to Auto from Away?
Also test with a temp of 15 instead of 12.
What is happening is that in Away mode, it will use the lower of the setpoint, and 12C. That is, Away mode sets an upper limit for the current setpoint to 12C (to be clear, this is what the controller is doing, not what HA is doing).
Again, the duration of the TemporaryOverride is ignored, until the system returns to Auto mode.
Hello,
I’m traying to make an automation based on the actual temperature the Honeywell is measuring. I like to do this with the identity climate. The entity climate in has an attribute actual temperature but if I ask the actual temperature as a trigger it is not working. In the home assistant app I see setpoint temperature and actual temperature but can’t use the actual temperature as a trigger.
Any idea how I can use the actual temperature the Honeywell is reading?
Thanks in advance.
Regards,
Wilfried
You will have to use the attribute current_temperature from your climate entity in your trigger. Look at the example and explanation here. You could take this as a simpler starting point and look at their examples for more complex variations:
automation:
trigger:
platform: numeric_state
entity_id: climate.dining_room
above: 17
attribute: current_temperature
Dear scstraus,
Thanks for reply.
I do use the numeric state and when i use it as in your example it is ok and working.
It looks like:
platform: numeric_state
entity_id: climate.overloop
attribute: current_temperature
above: '18.6'
Thanks.
Instead of fix number to program in automation i like to use a helper so i can change number . For that i have:`
platform: numeric_state
entity_id: climate.overloop
attribute: current_temperature
above: {input_number.temperatuur_overloop}
input_number.temperatuur_overloop is the variable i like to modify in frontend of homeassistent. here things go wrong i think 
how can i use the helper input_number.temperatuur_overloop as value to check if temperature is above input_number.temperatuur_overloop?
I like to hear from you.
Regards
I’m not sure it’s possible to use a template in the “above” section of the automation. But it it were possible to do it, the correct syntax would look more like
"{{ states('input_number.temperatuur_overloop')|int }}"
If that doesn’t work, you will likely have to write the whole trigger as one big template as described here
Dear scstraus,
I tried a little, but this template trigger thing I think is too difficult for me to understand. I’m new and not so good in this programming. For now I use with fixed number in automation.
Maybe later if I understand it all better I try to do with template trigger.
Thanks.
Wilfried
Thank you for taking the time to look at this, apologies, I read your reply whilst at work then forgot all about it.
I’ve done some testing using your suggestions,my results are as follows:
Switching modes will change the temperature to that dictated by the controller, resetting anything HA has sent.
HA can set TemporaryOverride whilst in away, but duration is ignored.
I have now written my automations to use HA evohome.set_zone_override without a duration, which makes the change permanent, I then clear it later in HA using evohome.clear_zone_override.
This works, but if Evohome accepted the duration, it would be so much easier 
Hi David, probably this is the wrong place to ask, but I am shopping for a new boiler and wanted to get one where I could read the boiler pressure and basic fault info from Home Assistant. It appears you have made a nice integration for Intergas which would also support OpenTherm which I would like too.
Can I ask you if there’s any modern Intergas boilers which support this integration? It seems that they phased out the Incomfort/Intouch apps in favor of their new Comfort Touch app. Does that mean we cannot integrate to the new boilers?
Here in Czechia it seems they only import the HRE ones but it looks like they might be adding the Xclusive range. Though I’m not opposed to importing if I must.
If there are boilers which will still work, please let me know, I will try to get the one you recommend.
Hi @scstraus I see you sometimes help other posters - thanks.
The intergas integration speaks with a Lan2RF gateway, which is approx £150 or so - it is this device that inncomfort integration uses.
I cannot recommend it, mainly because it does not expose a return temp for CV (CH circulating volume). Note: I have no direct experience with v2 of the LAN2RF bridge, but I suspect it is the same.
If you’ve evohme, I suggest going down the opentherm route - a boiler with OT built in may be cheaper than adding it to a boiler, then all you have to do is but an evohome OT bridge & you can get all you want via evohome_rf
Whatever you do get - modulation level, return CV temp, and pushed fault alerts are the minimum required.
People who can speak with authorty can be found here: Heating Control (automatedhome.co.uk)