Official Honeywell evohome/Round Thermostat integration (EU-only)

[zxdavb (David Bonnes)]

@quentinsf

Am I right that if I want a temporary override to run until the next switchpoint, I should set use_schedules: true ? And is the comment that this is only for the adventurous still appropriate?

Yes, and YMMV (I think I said slightly adventurous).

TBH, I am not sure what adventurous means - you certainly wont break anything.

Let me know how you get on…

[zxdavb (David Bonnes)]

@quentinsf - has the problem resolved after I accepted your PR?

[quentinsf (Quentin Stafford-Fraser)]

Yes, seems to - thanks!

[Langh_Tamas (bocsitomcsi)]

Hi,

First of all let me thanks for your hardwork. I really like the custom component, know much more than the stock one.

I have integrated the latest version of it (v0.9.6) to my HAS (0.88) and works however I got several warning and error message. Most of them do not look like a serious one, however one yes:

Log Details (ERROR)
Fri Feb 22 2019 18:57:02 GMT+0800 (China Standard Time)
Update for climate.home fails
Traceback (most recent call last):
File “/usr/src/app/homeassistant/helpers/entity.py”, line 221, in async_update_ha_state
await self.async_device_update()
File “/usr/src/app/homeassistant/helpers/entity.py”, line 349, in async_device_update
await self.hass.async_add_executor_job(self.update)
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/climate/evohome_cc.py”, line 892, in update
self._update_state_data(evo_data)
File “/config/custom_components/climate/evohome_cc.py”, line 793, in _update_state_data
new_dict_list = list(ec1_api.temperatures(force_refresh=True))
File “/usr/local/lib/python3.7/site-packages/evohomeclient/init.py”, line 73, in temperatures
self._populate_full_data(force_refresh)
File “/usr/local/lib/python3.7/site-packages/evohomeclient/init.py”, line 44, in _populate_full_data
self.location_id = self.full_data[‘locationID’]
KeyError: ‘locationID’

Have you any idea what can be the problem? Should I try to set the locationID explicitly in configuration.yaml? Another point in the last 5 minutes I got the above error message 18 times.

Just digging further it looks like if I use v2 it works perfectly. If I use v1 got the above error… Any idea ?

[Langh_Tamas (bocsitomcsi)]

Another thing is that however I set my log level to error or above for this particular component, considering the description of wiki page, I still get the warning message on the frontend (lovelace ui). Has any body identified this kind of bug?

Configuration:

logger:
  default: debug
  logs:
    custom_components.evohome_cc: error
    custom_components.climate.evohome_cc: error

Home Asisstant 0.88.1

[zxdavb (David Bonnes)]

I am sorry there hasn’t been much feedback currently - I am flat out with existing commitments, including a few changes to the underlying client API:
https://github.com/watchforstock/evohome-client/tree/allow_session_reuse

We’ve come up with a solution to solve the HTTP_STATUS_429 error that occur when you restart HA.

[zxdavb (David Bonnes)]

Unfortunately, you haven’t given enough information fro me to say…

The new version of the client API should address this issue by providing a more useful error message.

What has happened is that somewhere earlier in the code, a HMTL GET failed, and this wasn’t caught - this too has been addressed…

[Langh_Tamas (bocsitomcsi)]

Thanks for the reply. To be honest I did not know where I should start to dig into the details therefore I dropped a mail to Honeywell about this error. Now I am in contact with one of the designer from evohome project, at the moment looks like I have some exocit problem that manifest in evohome v1…

[zxdavb (David Bonnes)]

OK, there is a new evohome_cc, v0.9.8, written for, and tested upon HA v0.88.2.

It addresses the new integrated folders structure, and can work with the newest evohome-client api, which is not yet released, but which will address some of the 429 errors (api rate limit exceeded).

Note: The new folder structure (from now on) for integrated folders is:

<config_folder>/custom_components/evohome_cc
    --> __init__.py
    --> climate.py
    --> water_heater.py

The latest custom_components.json will always be on the master branch:
https://raw.githubusercontent.com/zxdavb/evohome/master/evohome_cc/custom_components.json

(other branches have been deleted)

There may be issues because (AFAIK) custom components has no means to delete/move/rename files.

Let me know how you get on.

[zxdavb (David Bonnes)]

@zxdavb

OK, there is a new evohome_cc , v0.9.8, written for, and tested upon HA v0.88.2.

Now v0.9.9.

[BVE (Bert Verlinden)]

Thank you very much for your continuing work on this component!
I juts updated to the new structure and this is working as a charm.

Only still having trouble with the custom updater. (running Hassio 0.88.2)

> #Enable Custom Component Updater
> custom_updater:
>   component_urls:
>     - https://raw.githubusercontent.com/keatontaylor/custom_components/master/custom_components.json
>     - https://raw.githubusercontent.com/zxdavb/evohome/master/evohome_cc/custom_components.json
>   track:
>     - cards
>     - components

And my folder for custom components looks just like you described.
custom_components/evohome_cc/ the three py files.

But they are not showing up in the custom updater tracker card.

thanks for the help

[furiaceka]

I have opned an issue related to HA 0.89

[zxdavb (David Bonnes)]

Wild ride

@furiaceka Thanks for keeping everyone up to date.

@zxdavb

OK, we’re in for a wild ride…

As per previous post, I knew this 0.87-0.89 issue was coming, but there wasn’t much that could be done about it; we just have to wait for the wave to pass.

Hopefully everything will settle after HA 0.89 is released. Please bear with us, and do not upgrade to 0.89 until evohome has been upgraded to match (I will post here, and at https://github.com/zxdavb

Of course, the official version of evohome should be OK.

Other news:

There will be a new evohome-client library soon. This code sits between the evohome integration, and Honeywell’s servers.

The good news is that it:
a) has much better error logging,
b) includes a lot of intelligence to reduce 429s (API rate exceeded) during authentication/authorization (some features are not transparent)
c) adds high-precision support for DHW

The bad news is that it would break the official HA version of the evohome integration in edge cases.

[zxdavb (David Bonnes)]

Official Honeywell evohome/Round Thermostat integration (EU-only)

Hallo all. Install of component is great. Thank you for the contribution and development! Can we set a temporary override until a specific time? Because I can create automation to adapt the operation_mode but I cannot specify a temperature or until. Thanks for the help

@BVE Is this still an issue? There was a bug in the code that @quentinsf picked up. It may well be working now?

[BVE (Bert Verlinden)]

Hey thanks for taking a moment to reply. I’m afraid I don’t see any changes.
Updated the code, restarted, checked link in custom updater.
But none of the evohome components are showing up.
As others I’m staying on 88.2 for the moment.

[zxdavb (David Bonnes)]

Can I ask how many people use HA’s evohome, and evohome_cc at the same time?

[Cinamon]

After your latest update, i get the error:

Unable to find platform evohome_cc. Search path was limited to path of component: custom_components

I have only replace the old files with the new ones. I have hass 0.89.0

[BVE (Bert Verlinden)]

Only cc, because it works like a charm and more functionality.

[BVE (Bert Verlinden)]

Not compatible with 0.89. Need to wait for update from Honeywell. See a few posts above. You can reverse to 0.88 or wait it out.

[Cinamon]

Thx! I will wait!