now that I’ve looked at it properly and been patient for everything to come back up - restarting HA actually does help, irrespective of the restore_state setting. The status comes back up, only to disappear again after an hour or so - for both zones and the controller. At least these attributes go away: hvac_modes, hvac_action, preset_modes
This:
Turns into this:
Sorry - your language isn’t clear - I think you mean zone mode (hvac_action) is as expected after a restart with restore_state disabled, but not when it it is restarted with restore_state enabled, right?
OK, this is helpful - I think I will implement a workaround for now…
So - three separate bugs. Emergency bugfix… v0.9.2
evohome_rf is now called ramses_rf
evohome_cc will keep its name for now
Pulled it, up and running now. Will check the attributes in the morning.
Hi David,
I’ve come across your nice solution and have been trying to make it works, however I couldn’t get pass the point of loading the component in the first place 
After reading up from the history show the deployment for this custom component has changed several time, may I ask what’s the current correct way of deploying it ?
I’m currently having my HA up via docker. I checked out the repository, retrieved the evohome_cc in custom_components and deploy it to the corresponding location in HA. I did get the message that evohome_rf library was somehow not automatically retrieved in HA log and have manually tried to resolve it by running pip install evohome_rf in docker sh. With that the error messages in the log are gone, however, evohome_cc integration was still not found.
Yes, sorry.
All good with 0.9.2, attributes still there in the morning 
Did you see this? Using HACS is the easiest way
Yes, I have read through everything mentioned there as well, and unfortunately, I’m using HA core atm
I most certainly don’t fully understand how HA register custom component, but I have previously added another custom component and it works out just fine (HomeWizard Energy)
Oh, you said you did this. I’ve not used a core install, only/always supervised, so will have to pass.
Morning David.
Seeing a slight variation of the prior error message appearing on HA startup.
Logger: homeassistant
Source: helpers/entity.py:455
First occurred: 7:13:11 (1 occurrences)
Last logged: 7:13:11
Error doing job: Exception in callback async_track_point_in_utc_time.<locals>.run_action() at /usr/src/homeassistant/homeassistant/helpers/event.py:1172
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
self._context.run(self._callback, *self._args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1191, in run_action
hass.async_run_hass_job(job, utc_point_in_time)
File "/usr/src/homeassistant/homeassistant/core.py", line 428, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 455, in async_schedule_update_ha_state
self.hass.async_create_task(self.async_update_ha_state(force_refresh))
AttributeError: 'NoneType' object has no attribute 'async_create_task'
Cheers
Dan
Propably you will have to run some pip install commands (maybe you will find useful results when you search for ‘pip’ in this topic from the time before there was a HACS integration).
Are you using Core in a venv? if so, the install through HACS should work, and it will also pull in ramses_rf into your venv.
Updated and running, looks to be happy again.
Thanks.
Are there plans to make use of the outside sensor on the evohome display with this project? its the only reason why i still run my instance of Domoticz
i can confirm this. Thx
I think, this may still effect stored hot water - water_heater.* - about 1 hour after update/restart, it showed ‘unavailable’, when setting ‘boost’ it had state again.
turned on by Y
10:03:39 - 8 minutes ago
became unavailable
9:09:53 - 1 hour ago
turned off by X
8:06:43 - 2 hours ago
turned on by X
8:06:38 - 2 hours ago
Updated at 08:06, tested after update by turning on/off, then went unavailable ~1 hour later, another user set ‘boost’ and it correctly shows ‘boost’ now. Will see if it goes ‘unavailable’ again after the boost finishes.
UPDATE: About an hour after the override ended, I have failsafe automation rule to turn off the water_heater after being on for 1 hour, the water_heater went back to unavailable:
became unavailable
12:04:53 - 2 hours ago
turned off by service evohome_cc.reset_dhw_mode
11:03:40 - 3 hours ago
turned on by Y
10:03:39 - 4 hours ago
I have been running the initial Faked sensor release. Controller has lost connection to all devices. Never had a problem like this with evohome.
Not blaming anything on this component just thought it would let everyone know just incase the same happens to them.
Will let you know once I warm up, down to 16oC.
Did you have any faked sensors?