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.
I have only tested on TRVs thus far - when you get there, let me know how you get on.
There seem to be two separate rate limits, one for Oauth (i.e. logging on when HA is started), and another for pulling state data per unit time - the scan_interval.
Please consider using evohome_cc rather than evohome (master branch) - there will be no significant development on master. See: https://github.com/zxdavb/evohome/tree/evohome_cc
In your logs, you’ll have [custom_components.evohome_cc] instead of the above.
I agree: the default behaviour of changing the target temperature should be the same as using evohome (i.e. via Controller, Y87RF or HR92), that is: TemporaryOverride. You would then change mode to PermanentOverride (as via Controller) separately.
@jaustin Your analysis is spot on…
Many of these issues are cause by limitations/obligations of HA. This is why I suspect we’ll be running both versions of the evohome component: the ‘official’ version that fully integrates with HA, and a ‘custom’ version that is feature complete.
Please consider running both & see how you go (watch your overall rate limit).
I will have a look at these issues soon, probably over the weekend.
I want to do this (and have it working: Auto → Eco → SuperEco → Off, and DHW Off), but my wife won’t accept a smartphone with a battery big enough to do the GPS tracking…
There seem to be two separate rate limits, one for Oauth (i.e. logging on when HA is started), and another for pulling state data per unit time - the
scan_interval
Ah - that makes sense - thanks!
OK, I think I found the issue - a fix was pushed to evohome_cc just now: https://github.com/zxdavb/evohome/tree/evohome_cc
The diff is broadly:
- self._obj.set_temperature(temperature)
+ self._obj.set_temperature(temperature, until)
Splendid - have switched branch and copied things into place. Will play some more tomorrow!
Always worth doing a git pull - may be frequent changes!
Currently, all my testing is with the old UI.
And post your custom cards here - I’m always willing to learn!
Being new to this game, I’m still trying to work out the best way of managing custom components that need to be in one custom_components directory but may come from different repositories and want regular pulling.
In addition, I noticed in one of the logs that if there are ‘.git’ folders under /config, HA will scan them and all their contents when looking for updates, which seems wasteful.
So I’m wondering about putting the git clone somewhere else and arranging for the working directory to be custom_components. Something like the following:
git --work-tree=/config/custom_components \
--git-dir=/someotherplace/evohome.git \
clone https://github.com/zxdavb/evohome.git
Then you can do all the git operations under /someotherplace/evohome.git but the files will actually be stored in the right place. Does that sound good? Of course, it won’t work if more than one repo has a README or a LICENSE at the top level 
But assuming no filename clashes, I think this might work.
I’m assuming that everything does need to be at the top level under custom_components…
Sorry, I am not sure what you mean!
Gotcha.
TL;DR - Yes, and no. Issues at HA startup can’t be worked around (you’ll have to restart at a minimum). However, recovery from issues that occur after startup were never a ‘problem’ (although the error logging/warnings have now been improved).
The evohome components use the underlying client API (evohomeclient) in an effectively stateless way - either it can ‘connect’ to Honeywell’s servers, or not, and there is no concept of ‘reconnecting’. The exception to this is the first connection (i.e. when HA starts), as it is only then that the devices are enumerated.
If the devices can’t be ‘found’ (when HA starts), then the component will fail to load (sometimes you immediately restart HA & it is OK, sometimes not). I cannot see a reasonable workaround for this…
[ as an aside, if you change your evohome configuration (not state), then you have to restart HA - e.g. adding a zone ]
Unfortunately, Honeywell’s web servers are relatively unreliable (they did send out a recent email effectively saying so), and there is a lot of scope for a) HTTPErrors and b) ConnectionErrors.
This is in addition to API rate limits, which are becoming more of an issue, primarily during HA startup (see Post #263).
Every scan_interval, the component tries to download the latest state data (i.e. temperatures, modes, etc), and also - if use_schedules is true, the latest schedules once hourly. Either it gets this data, or not.
If it doesn’t get the data for a while, then ‘things’ happen (gaps in graphs, entities marked as unavailable, etc). The main thing I hear about is errors in the logs, that people often think is an error in my code, but is simply reflecting the fact that Honeywell’s web servers are not behaving.
In any case, the connection/HTTP errors eventually stop & the component starts downloading data again - no intervention is required (so the component does ‘reconnect’ in that sense).
I have implemented a ‘fix’ for this: a clearer message in the logs that when these errors do occur, look to blame Honeywell first.
1 Like
Yes (specifically the 3 evohome_cc.py files in their correct folders). The vagaries of git I leave to you…
Thanks for that detailed explanation!