Thank you so much, this worked great.
Be nice to get current temperature onto card but I cant work that out.
For people still wanting to do this:
In manifest.yaml you have to add:
"version": "1.0.0"
(And don’t forget to add a “comma” since it’s a list you’re adding it to)
Without the version string, the custom component won’t load and you will get strange errors.
I’m not sure if this is the right place, but is anyone else having issues with this integration and Honeywell locking them out of the account? I have received this from Honeywell
"
The account was locked due to multiple requests to the server since 5th of May, but we have successfully unlocked the account.
Please remove any automation system you might have installed, and please be aware that if you will be creating the same number of high requests to the server, the account will be locked again automatically
"
What poll times are people using ?
That’s concerning. I’ve not experienced any issues or recieved emails, though heating not used very much in last few months.
My settings are default.
I got absolutely no warning at all it all just locked up. It took a fair amount of bashing their customer support to get that far. If nobody else has issues I might re enable on a tertiary account with an hour poll time to see if that helps.
It does seem stupid to have such a system and allow integrations and then get annoyed when people use it. It would also be better for them to have an mqtt type pub/sub thing rather than an API for these things.
So, the evohome integration - originally written by me - is based upon a python library that I wrote/maintain (with help of others).
A lot of work has gone into making sure that the integration (supported by the library) does not exceed any vendor-imposed API rate limits. Unless a lot of people have the same problem - which would suggest the vendor (Honeywell? Resideo?) has changed those limits (as they have don in the past), then it must be something at the end-user side…
Background, there are two limits:
a) authenticating with the servers, so that you can do b), and
b) polling the server for data per unit time (300 seconds is fine, anything less than 60 secs is outrageous)
(it would be good to know which you exceeded)
Traditionally, the issue people have is with a), but this is mitigated by the integration caching the authorization token(s) across restarts.
In addition the integration wont let you poll more often than once a minute.
So, things you can check / things you can do:
- leave the scan interval at the default value, or even set it at 15 minutes
- only have one instance of HA running - if you have more than 1, they will invalidate each other’s tokens
- disable high-precision temperatures (uses a different API, and those temps are ‘meaningless’ anyway)
- think about any other code you have using the TCC API
Just as an aside - I always regretted setting the minimum scan interval to 60 seconds…
Is it possible to start heating with all the radiator valves closed? I have in my bathroom a regular radiator without a honeywell valve which is always open. I want to start heating for 1 hour if the humidity is high (I have a sensor there) so my radiator dry the towels. Is this possible with this integration or do I need the RF one?
I think you would create a zone with a sensor, but no TRVs - I am not exactly sure what zone-type you’d use…
You will have to use evohome_rf as you’ll need a faked sensor (i.e. you can set the sensor’s reading, as a function of the humidity in the room).
Thanks for your reply. I will look into Evohome_rf
Exactly the same thing happens to me, but I don’t know how to edit the file “/usr/src/homeassistant/homeassistant/components/evohome/init.py” or how to locate it on my Synology. Is it through SSH? Through the “HomeAssistant” Docker terminal?
This is the error that appears to me:
2023-10-23 18:25:32.811 WARNING (MainThread) [homeassistant.setup] Setup of evohome is taking over 10 seconds.
2023-10-23 18:25:34.458 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 265, in async_setup
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 534, in async_update
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 476, in _update_v1_api_temps
File "/usr/local/lib/python3.11/site-packages/evohomeasync/__init__.py", line 114, in temperatures
You can help me?
I am afraid you should be more clear what you mean when you say exactly the same thing…
If you want to change the scan_interval, it is a parameter inside the configuration.yaml file.
I refer to this message:
Official Honeywell evohome/Round Thermostat integration (EU-only) - #380 by Cinamon
You helped this person with the same problem that I have (or so I think), it doesn’t allow me to perform the integration, I get this error message:
2023-10-23 18:25:32.811 WARNING (MainThread) [homeassistant.setup] Setup of evohome is taking over 10 seconds.
2023-10-23 18:25:34.458 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 265, in async_setup
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 534, in async_update
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 476, in _update_v1_api_temps
File "/usr/local/lib/python3.11/site-packages/evohomeasync/__init__.py", line 114, in temperatures
But no matter how much I have searched for that path using ssh and the docker container terminal, I have not been able to locate it to modify the “init.py” file as you showed this person.
I have also tried creating another user in case it was a token problem, but the problem remains.
I’m a complete noob, can you tell me how to access this file to modify it?
That bug has definitely been fixed.
I notice you’re running HA inside a VM… Have you ever had Evohome working?
Look at: Hass: Evohome Debug Logs · zxdavb/evohome-async Wiki · GitHub
And paste the debug log here, or pm them to me.
Yes, I am running Home Assistant through Docker (HACS) on a Synology 1819+. And yes, it’s the first time I’m trying to integrate with HA.
The .log you asked me for:
2023-10-24 16:36:08.945 INFO (MainThread) [homeassistant.setup] Setting up evohome
2023-10-24 16:38:32.321 WARNING (MainThread) [homeassistant.setup] Setup of evohome is taking over 10 seconds.
2023-10-24 16:38:34.074 DEBUG (MainThread) [homeassistant.components.evohome] Config = {'locationInfo': {'timeZone': {'timeZoneId': 'RomanceStandardTime', 'displayName': '(UTC+01:00) Brussels, Copenhagen, Madrid, Paris', 'offsetMinutes': 60, 'currentOffsetMinutes': 120, 'supportsDaylightSaving': True}}, 'gateways': [{'temperatureControlSystems': [{'systemId': '632515', 'modelType': 'FocusProWifiRetail', 'zones': [{'zoneId': '632515', 'modelType': 'FocusProWifiRetail', 'setpointCapabilities': {'vacationHoldCapabilities': {'isChangeable': False, 'isCancelable': False}, 'maxHeatSetpoint': 32.0, 'minHeatSetpoint': 4.5, 'maxCoolSetpoint': 37.0, 'minCoolSetpoint': 10.0, 'setpointDeadband': 0.0, 'valueResolution': 0.5, 'canControlHeat': True, 'canControlCool': True, 'allowedSetpointModes': ['PermanentOverride', 'VacationHold'], 'maxDuration': '1.00:00:00', 'timingResolution': '00:15:00'}, 'name': 'DINING ROOM', 'zoneType': 'Thermostat', 'allowedFanModes': [{'fanMode': 'Auto'}, {'fanMode': 'On'}]}], 'allowedSystemModes': [{'systemMode': 'Off', 'canBePermanent': True, 'canBeTemporary': False}, {'systemMode': 'Heat', 'canBePermanent': True, 'canBeTemporary': False}, {'systemMode': 'Cool', 'canBePermanent': True, 'canBeTemporary': False}]}]}]}
2023-10-24 16:38:34.464 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 288, in _async_setup_component
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 265, in async_setup
await broker.async_update() # get initial state
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 534, in async_update
await self._update_v1_api_temps()
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 476, in _update_v1_api_temps
temps = list(await self.client_v1.temperatures(force_refresh=True))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/evohomeasync/__init__.py", line 114, in temperatures
status = device["thermostat"]["changeableValues"]["heatSetpoint"][
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'status'
OK, I see you don’t have evohome, but FocusProWifiRetail. These systems are compatible with TCC, but haven’t been extensively tested with this integration (mainly because they are relatively rare).
Looking at the code of the integration (HA) and library (me)…
The library is crashing when retrieving high-precision temps from the vendor’s older API because the JSON isn’t as expected.
The integration is designed to handle a failure of the older API (everything required is in the newer API), but only in update/refresh and not on setup…
So I will ned to submit a patch to HA.
1 Like
Please raise this as an issue at Issues · home-assistant/core · GitHub
It is a new/separate issue to all other existing evohome issues.
I will try to get it turned around for you as quickly as I can.
1 Like
@zxdavb A new user here - thank you very much for the integration!
I find it extremely useful, in particular, being able to track the actual temp in the room vs the scheduled (seeing how long it takes to get to temp, under/over shooting etc.) and having the history helps to see e.g. how often the heating gets called over night .
I also created quick action buttons for common tasks, e.g. boosting 1h hot water, 1h all bedrooms etc. - much quicker than trying to do the same in the Evohome app!
One thing I am struggling with is to get a view of the overall schedule. I found from your comment on another thread here that if logging is on, I can get the full schedule for each zone, e.g.:
DEBUG (MainThread) [homeassistant.components.evohome] Schedule[‘bedroom_1’] = {‘DailySchedules’: [{‘DayOfWeek’: 0, ‘Switchpoints’: [{‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘00:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘06:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘08:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘18:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘22:00:00’}]}, {‘DayOfWeek’: 1, ‘Switchpoints’: [{‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘00:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘06:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘08:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘18:00:00’}, {‘heatSetpoint’: 18.0, ‘TimeOfDay’: ‘22:00:00’}]}, …
I couldn’t find however how to get this information to display in the HA dashboard. Can a sensor be created to access this info? I can only see current/next points in attributes in Dev Tools:
setpoints:
this_sp_from: ‘2023-10-26T07:40:00+01:00’
this_sp_temp: 15
next_sp_from: ‘2023-10-26T16:00:00+01:00’
next_sp_temp: 18
Ideally, I’d like to be able to visualise all zones on the same graph to see all set points for each day over a week as I am hoping to optimise the scheduling so that the zones call for heat at the same time.
Any pointers are greatly appreciated!
@Truman78es HA v2023.11.0 has just been released.
It includes the fixes that will handle the status error you had, but even then, it may yet not work for you - I have never tested evohome against a FocusProWifi.
To that end - and even if it does work for you - what would be really helpful would be for you to run HA with the same debugging as before and provide the line that has:
Status = ...
… the same as when you provided, above, the line containing:
Config = {'locationInfo'...
If needed, I can use that data to make further changes to get this controller working with evohome.