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!
Thanks, David. It would be cool if you ever wanted to support the custom_updater.
Haven’t played with it yet, but it doesn’t look too hard… https://github.com/custom-components/custom_updater/wiki/components
Demanding, aren’t I? Thanks again!
Not a silly idea. Short term, I will focus on getting evohome_cc ‘feature complete’ (before Winter is over). When I look bored, feel free to remind me (maybe you could add a request at: Issues · zxdavb/ramses_rf · GitHub)
1 Like
Thanks for getting back so quickly. Unfortunately, this now seems to have broken all set_temperature calls. I tried:-
which still fails with an API error. By removing the until parameter the API gets called but it doesn’t set the temperature at all and the logs:-
2019-01-30 15:49:31 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.139767067506504] Received {'type': 'call_service', 'domain': 'climate', 'service': 'set_temperature', 'service_data': {'entity_id': 'climate.zzspare', 'temperature': '10', 'operation_mode': 'TemporaryOverride'}, 'id': 15}
2019-01-30 15:49:31 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=climate, service=set_temperature, service_data=entity_id=climate.zzspare, temperature=10, operation_mode=TemporaryOverride>
2019-01-30 15:49:31 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.139767067735544] Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'call_service', 'data': {'domain': 'climate', 'service': 'set_temperature', 'service_data': {'entity_id': 'climate.zzspare', 'temperature': '10', 'operation_mode': 'TemporaryOverride'}}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2019, 1, 30, 15, 49, 31, 922269, tzinfo=<UTC>), 'context': {'id': '3fbee887ce1b4164823d0dd5c9825e38', 'user_id': None}}}
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.climate.evohome_cc] set_temperature(4491817 [ZzSpare], **kwargs=dict_items([('entity_id', ['climate.zzspare']), ('temperature', 10.0), ('operation_mode', 'TemporaryOverride')]))
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.evohome_cc] name(4491817) = ZzSpare
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.climate.evohome_cc] state(4491817) = Auto
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.evohome_cc] name(4491817) = ZzSpare
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.climate.evohome_cc] state(4491817) = Auto
2019-01-30 15:49:31 WARNING (SyncWorker_3) [custom_components.climate.evohome_cc] _set_temperature(): API call [1 request(s)]: zone(4491817).set_temperature(10.0, <bound method EvoChildDevice._next_switchpoint_time of <Entity ZzSpare: Auto>>)...
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.evohome_cc] name(4491817) = ZzSpare
2019-01-30 15:49:31 DEBUG (SyncWorker_3) [custom_components.climate.evohome_cc] state(4491817) = Auto
2019-01-30 15:49:31 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/service.py", line 289, in _handle_service_platform_call
await func(entity, data)
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/climate/__init__.py", line 574, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/climate/evohome_cc.py", line 258, in set_temperature
self._set_temperature(temperature, until)
File "/config/custom_components/climate/evohome_cc.py", line 217, in _set_temperature
self._obj.set_temperature(temperature, until)
File "/config/deps/lib/python3.6/site-packages/evohomeclient2/zone.py", line 63, in set_temperature
data = {"HeatSetpointValue":temperature,"SetpointMode":"TemporaryOverride","TimeUntil":until.strftime('%Y-%m-%dT%H:%M:%SZ')}
AttributeError: 'function' object has no attribute 'strftime'
Or am I doing something wrong?
Many thanks.
Unfortunately, until is not supported by HA’s climate.set_temperature service call. Only entity_id, temperature, and operation_mode are supported and useful (target_temp_high, target_temp_low are not useful).
This JSON works for me:
{
"entity_id": "climate.bedroom",
"temperature": 21.5
}
… and I get in my logs:
2019-01-30 16:49:51 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=climate, service=set_temperature, service_data=entity_id=climate.bedroom, temperature=21.5>
2019-01-30 16:49:51 DEBUG (SyncWorker_27) [custom_components.climate.evohome_cc] set_temperature(3432580 [Bedroom], **kwargs=dict_items([('entity_id', ['climate.bedroom']), ('temperature', 21.5)]))
2019-01-30 16:49:51 WARNING (SyncWorker_27) [custom_components.climate.evohome_cc] _set_temperature(): API call [1 request(s)]: zone(3432580).set_temperature(21.5, 2019-01-30 17:49:51.675669)...
Are you using use_schedules (I had it turned off)? I will test it soon, when I can restart HA…
In the meantime use_schedules: false works for me…