In the custom_component it is (note case, FollowSchedule):
- service: climate.set_operation_mode
data:
entity_id: climate.kitchen
operation_mode: FollowSchedule
In the official version, it is (note case, auto):
- service: climate.set_operation_mode
data:
entity_id: climate.kitchen
operation_mode: auto
For reference, see this post: Official Honeywell evohome/Round Thermostat integration (EU-only) - #227 by zxdavb
@freekeys Have you got the above working yet? If not, would you be able to send me some logs?
You may need to increase logging in HA, with a logger section in configuration.yaml like;
logger:
default: warn
logs:
homeassistant.components.evohome: debug
homeassistant.components.climate.evohome: debug
custom_components.evohome: debug
custom_components.climate.evohome: debug
evohomeclient2: debug
…and then do something like:
grep home-assistant.log evohome | tail -n 20
Hello,
I’m successfully using the V2 component to control 8 thermostatic radiator valves, now I just want to realize a simple SWITCH (using automation? or something else?) to turn-on (heat to 24°C) and turn-off(Follow Schedule) all the radiator valves together.
The purpose is to expose only the SWITCH to homekit and gogle assistant in order to easy control all the valves by voice-control.
Do you have any suggestion? Or a scratch to start with this job?
Regards…
How did you manage to do that? Did you only leverage the Evohome hardware?
I used a weather comp from the boiler’s manufacturer. It adjusts the temp of circulating CH water according to outside temp.
I understand evohome does something similar, but via TPI (on/off intervals) rather than temp.
Both aim to prevent overshoot (as do the TRVs, by starting to close the valves as the system nears target temperature - I get ‘whistling’ when the valves are partly open), but the former is more efficient.
WC will become more prevalent over time, because of the ‘boiler plus’ standard.
I’m creating an automation…
If I run following automation:
action: - service: climate.set_temperature data: entity_id: climate.cameretta temperature: 25
What is happening is that 25 degree is PermanentOverride to climate.cameretta also if I enable:
use_schedules: true # this is for the adventurous person
Do you have any suggestion for temporaryOverride until next set point?
If I used until I get this error in the log:
Invalid data for call_service at pos 1: extra keys not allowed @ data[‘until’]
All,
I have been beating my head up against a wall trying to get evohome accepted in HA as a maximally functional component. In the meantime, the custom component has been neglected.
FWIW, see: Architectural review of climate entity · Issue #22 · home-assistant/architecture · GitHub and Current `water_heater` entity missing important attributes, methods · Issue #117 · home-assistant/architecture · GitHub
Despise my efforts, nothing much has progressed with the official component (e.g. I am ready to add DHW, but it is not worth my while to submit the PR as HA is not) and this doesn’t look like changing soon.
So I will be switching my focus back to the custom component, starting this weekend, when I will address many of the issues raised in this thread. Step 1 will be to improve the quality of the code.
Your job will be to be clear on which version of the component you are using.
I think - on balance - it will be best to change the name of the custom component to (say) evohome_cc, but I am willing to hear any objections to this. As it stands (and moving forward):
scan_interval)Great work on the threads there, it needs people like you to fight the sensible corner for the rest of us! Thanks!
Happy to go with evohomecc - I will always use this version for the extra functionality it gives. 
I’ve been happy with both the custom and official component. Keep up the great work. Definitely in favor of having them with different names. There were some times right after official was released that I didn’t realize I was running it yet. But they both worked well, so not a big issue…
For the guy with problems starting on restart, I find that waiting 10 minutes between restarts is enough to avoid this. Sometimes if I am doing a bunch of testing and want to restart quicker, I just accept that I will have to do another restart later after a 10 minute interval.
zxdavb,
did you receive message from Honeywell: Planned maintenance of Honeywell Home Services / Total Connect Comfort…?
Yes I did, till mid February.
evohome_cc (evohome new generation)
So for a while, I’m going to focus on the custom_component version of evohome, and try to complete the set of features I’ve had planned.
For now, I have re-written the custom component, it is now available via the evohome_cc branch, something like:
git clone https://github.com/zxdavb/evohome.git custom_components
cd custom_components
git checkout evohome_cc
Please feel free to download & test (@matthewcky2k). I would really appreciate informed/useful feedback.
You can run it alongside HA’s official version. A sample configuration.yaml is below:
evohome_cc:
username: !secret my_evohome_username
password: !secret my_evohome_password
# location_idx: 1
scan_interval: 600
high_precision: true
Warnings and NB:
Try to avoid exceeding Honeywell’s API rate limits. If you are running evohome and evhome_cc, be sure to set the scan_interval for one to (say) 600. Also, there appears to be a more aggressive rate limit on the OAuth URL, so avoid restarting HA if you can.
Depending how you’re set up, there may be a lot of logging - however, if you want to submit bugs, please do enable full logging for the component (see below), and submit bugs via https://github.com/zxdavb/evohome/issues
DHW has yet to be tested - I’ll need someome to provide access to their system (you can add my email address via the TCC website - please PM me)
It appears to work read only, but setting modes/temps not fully tested - that’s where you can help!
Enable Logging:
In configuration.yaml, add the following under the logging section:
logger:
logs:
custom_components.evohome_cc: debug
custom_components.climate.evohome_cc: debug
custom_components.water_heater.evohome_cc: debug
Thank for your work.
So I can use evohome and evohome_cc tha same time with 600 scan?
TL;DR: Yes, you’ll have an overall scan_interval of 300 seconds from Honeywell’s point of view.
Long answer: You can use both, with whatever scan_interval you like, but they will both ‘count’, and you may exceed your API rate limit (let us know if you have any hard figures from Honeywell).
For example, evohome at 180 (20/hour), and evohome_cc at 120 (30/hour) is 50 polls per hour, or an effective scan_interval of 72 (once every 72 seconds is 50/hour)!
This is quite likely take you over Honeywell’s API rate limit & is simply not necessary (you’re just recording the same data twice). FWIW, I know of no other sanctions from Honeywell other than being rate limited…
I would make one 600-1200, and the other say 180-300 (or try both at 300), which is which is up to you, but at evohome_cc is likely to be unstable, consider making it’s scan_interval the longer one. The only downside is changes made in evohome_cc will show up quickly in evohome, but wont show up in evohome_cc until the next poll.
OK, thanks.
I start to test it.
OK, so DHW starts now - read only currently.
Ooh! Thanks for this! I am using the default Evohome component currently and to be honest it isn’t that great. Can’t wait to try this one. Currently I only have one zone, I am planning to divide my floor heating in multiple zones later.
David - thanks again for this excellent work. Discovering that I could get graphs of all my room temperatures was a major part of getting me interested in HA.
My graphs are a bit patchy, because I regularly hit the API limit despite my scan_interval being 600. But that’s probably because I’m doing lots of other tweaks and restarting HA frequently!
So I’m mostly interested in reporting, rather than controlling, the temperature - but I notice when I do set it from HA (just using the standard Lovelace entities list), it always seems to go into PermanentOverride, when I almost always want TemporaryOverride. (I used the iOS app to check after making the change) Perhaps I need to use/create a different control?
I notice the following warnings in the log, but they sound as if they’re doing the right thing by default.
2019-01-29 08:41:56 WARNING (SyncWorker_0) [custom_components.evohome] set_operation_mode(3189234): For 'TemporaryOverride' mode, 'temperature' should not be None (will use current target temp).
2019-01-29 08:41:56 WARNING (SyncWorker_0) [custom_components.evohome] set_operation_mode(3189234): For 'TemporaryOverride' mode, 'until' should not be None (will use until next switchpoint).I’m seeing similar issues when trying to set TemporaryOverride. No matter how I try to do this - from an entity card, Service call or script - it always results in a PermanentOverride.
I tried climate.set_temperature passing temperature and operation_mode=TemporaryOverride. There’s no way to set ‘until’, but the code suggests it will then use +1 hour or the next scheduled switchpoint, but it doesn’t.
I tried climate.set_operation_mode, passing temperature and until, but this just results in API error, although your component looks like it should accept these arguments.
2019-01-29 10:20:37 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140181396624944] Received {'type': 'call_service', 'domain': 'climate', 'service': 'set_operation_mode', 'service_data': {'entity_id': 'climate.zzspare', 'operation_mode': 'TemporaryOverride', 'Temperature': 10}, 'id': 26}
2019-01-29 10:20:37 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140181396624944] Sending {'id': 26, 'type': 'result', 'success': False, 'error': {'code': 'invalid_format', 'message': 'Invalid format'}}
I would really like to use this component so that I can get access to the main controller for setting automated ‘Away’, ‘Home’ based on presence detection.
Another minor thing I noticed (minor as I think I’ll likely build my own custom card) is that the standard Thermostat card loses the Auto/Manual icons and control when using this custom component.
I did wonder if this was because the exposed Operation Modes are different from the standard evohome component? (ie, FollowSchedule,TemporaryOverride,PermanentOverride vs Auto,Manual)
Many thanks.