Thanks!
So, from what I can see on the Honeywell app, the only options for HW are On or Off, and the ability to see what the current temperature is. Target temp is set via a physical sensor on the cylinder, so no need to control that. Simples hopefully. 
Yes, very doable, but I’ll be relying upon people like yourself for testing.
Honeywell has reduced the OAuth access token timeout from 60 mins to 30 mins.
Thus the component will stop working for 30 mins in every hour.
Updated code will be available shortly (after some testing, I’m including many other changes with it).
Ignore me: I think there may be a v3 of the api!
I’m testing this component also and I have DWH cylinder let me know if you need any logs or for me to test anything excellent work so far!
Thanks. I am busy making a few changes to the underlying api library (below), then will get to work on this, including DHW. Will ping you when I am ready.
I would be curious: if you cat homeassistant.log | grep Found do you see “DHW”?
no doesnt show any output
Did you try cat homeassistant.log | grep Found or cat homeassistant.log | grep DATA_EVOHOME?
I am after:
cat homeassistant.log | grep Found
If i do cat homeassistant.log | grep DATA_EVOHOME
then it shows
dhw’: {‘temperatureStatus’: {‘isAvailable’: True, ‘temperature’: 52.0}, ‘dhwId’: ‘redacted’, ‘stateStatus’: {‘state’: ‘Off’, ‘mode’: ‘FollowSchedule’}
cat homeassistant.log | grep Found doesnt show any output
Thank you for your work!!
This is something I am waiting for since the beginning.
So the Bean had me busy for a while. Tried to get it to work hit an error though.
2018-06-30 16:45:59 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.5/site-packages/homeassistant/setup.py”, line 146, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File “/usr/lib/python3.5/asyncio/futures.py”, line 380, in iter
yield self # This tells Task to wait for completion.
File “/usr/lib/python3.5/asyncio/tasks.py”, line 304, in _wakeup
future.result()
File “/usr/lib/python3.5/asyncio/futures.py”, line 293, in result
raise self._exception
File “/usr/lib/python3.5/concurrent/futures/thread.py”, line 55, in run
result = self.fn(*self.args, **self.kwargs)
File “/home/homeassistant/.homeassistant/custom_components/evohome.py”, line 170, in setup
_updateStateData(ec_api, hass.data[DATA_EVOHOME], True)
File “/home/homeassistant/.homeassistant/custom_components/evohome.py”, line 196, in _updateStateData
= _returnZoneSchedules(evo_client)
File “/home/homeassistant/.homeassistant/custom_components/evohome.py”, line 310, in _returnZoneSchedules
s = z.schedule()
File “/srv/homeassistant/lib/python3.5/site-packages/evohomeclient2/zone.py”, line 13, in schedule
r.raise_for_status()
File “/srv/homeassistant/lib/python3.5/site-packages/requests/models.py”, line 935, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://tccna.honeywell.com/WebAPI/emea/api/v1/temperatureZone/XXXXXXX/schedule
@AlexBeumer, from the above line, I think you must be using a version of my code that includes the following:
REQUIREMENTS = ['https://github.com/zxdavb/evohome-client/archive/logging.zip#evohomeclient==0.2.7']
… rather than:
REQUIREMENTS = ['evohomeclient==0.2.5']
I have put some work in with the developer of the client api, GitHub - watchforstock/evohome-client: Python client to access the Evohome web service, and (among other ‘improvements’) it includes many r.raise_for_status() that the 0.2.5 version did not have.
In this case, there is a HTTP request status 400 error, which could be my fault, or just one of those things…
So: Is it still happening? Does it happen 100% of the time?
@matthewcky2k @jarrah (and anyone else with evohome & DHW):
I am working on DHW support, but I do not have DHW at home.
Looking at WatchForStock’s evohomeclient2 (the client api), I am not sure if it can even extract the DHW schedule (I think it can only extract zone schedules). If this is the case, I will have to make some more PRs for that code…
Rather than ask people to co-develop my code (i.e. developing, not testing), it would really help if someone would be willing to let me have access to their evohome system via:
https://international.mytotalconnectcomfort.com/Account/GrantAccess
If so, please PM me.
You are, of course, welcome to test my code yourself (below). If so, I warn you that it’ll use my version of evohomeclient2, and will clash with HA’s built-in honeywell component (i.e. don’t run them at the same time). Once you’ve run that, please post the results either of (via a PM if you prefer):
cat homeassistant.log | grep _returnZoneSchedules
cat homeassistant.log | grep DATA_EVOHOME
OK, for those interested, the beginning of DHW support. Only current_temperature (not the target temp), state (either on or off), and operation_mode - all properties - work so far.
Functions such as turn_on and set_operation_mode are yet to be implemented.
zxdavb thanks for your work.
I’m trying your code, from now is working very well.
The only 2 comment are the following:
I have some zone in state “FrostProtect” winch, if i correctly understood, is the problem 1 in your bug list?
Also sometime, i think when set the temperature, i get this error:
2018-07-12 14:48:28 ERROR (MainThread) [homeassistant.core] Invalid service data for climate.set_temperature: must contain one of temperature, target_temp_high, target_temp_low.. Got {'entity_id': 'climate.studio'}`
Let me know if can help in any way or make additional test.
Not exactly, actually no. If the Controller is in HeatingOff mode, then zones with be in FollowSchedule mode with a target_temperature of 5C.
In this case, their state will be FrostProtect rather than Off (which I feel is more ‘correct’ - i.e. they will call for heat if they detect a current_temperature <= 5C).
I am hoping just to squash bugs fro a while - testing/reporting of bugs would be great, you can report them via github, Issues · zxdavb/ramses_rf · GitHub
I am opening a new thread, could we please continue from there:
https://community.home-assistant.io/t/refactored-honeywell-evohome-custom-component-eu-only
Could you be more specific? What exact steps are you taking? What is your config (are you using use_schedules)?
Back again, sorry for the delay. Can begin testing in about a month. Moving in to a new house end of the month.
I’ll keep you updated. Any updates from you guys?
I am in the process of madly converting this from a custom_component to a component. Hope to submit a PR within a few weeks, but will need testers for the heuristics. Will post more info on the below forum when the time comes: