Hi, I’ve followed the instructions re:installation of the evohome.py files under /config/custom_components, and I’m running hassio so currently unable to find the location of the components directory to make the change identified above. Any guidance?
Sorry, I don’t use hassio!
No worries, i’ve done some searching about and discovered that I need to ssh as root on port 22222 to access the docker container to get to the code. That said it turns out that if I can get a copy of the honeywell.py file I can put an edited version in the /custom_components directory to achieve the same thing. Now just need to find the source code for honeywell.py…
Btw I have a full Evohome (12 zones) with hot water running for the last 2 years so happy to help in testing if required. I’m moving from Vera to HA so keen to get a fully working environment.
solved that element, by going back to the honewell component documentation and taking a copy from the source code definition, installed in custom_components/honeywell.py with the REQ updated. Have also updated the evohome.py code to point at the custom_components director per the instructions above.
Getting the following error;
Testing configuration at /config Failed config General Errors: - Component not found: evohome Successful config (partial)
14:18 components/hassio/init.py (ERROR)
Could not render template Hot Water Actual, the state is unknown.
14:10 components/sensor/template.py (WARNING)
Could not render template Heating Demand, the state is unknown.
14:10 components/sensor/template.py (WARNING)
Could not render template Heating Actual, the state is unknown.
14:10 components/sensor/template.py (WARNING)
If you use mine, then the necessary change is already there (it will be part of the PR)…
https://raw.githubusercontent.com/zxdavb/home-assistant/dev/homeassistant/components/climate/honeywell.py
It shouldn’t affect honeywell.py to use the updated evohomeclient library (i.e. v0.2.7), as only v2 of the api has changed (which my component uses) and v1 has not changed at all.
Sorry, I am completely flummoxed by that!
i’m using your latest commit but the display seems to be showing odd temperatures and status?
before it was showing follow schedule now it shows autowitheco on each zone? the setpoints are also off by a large amount.
one of the zones also appears to be unavailable?
Hi @matthewcky2k,
Do you have the experimental heuristics feature enabled in your configuration.yaml?
use_heuristics = true
I have decided to set each zone’s state to the controller’s operation_mode() if the zone is in FollowSchedule mode.
The bold text, AutoWithEco is state() (you say status) & not operation_mode(). If you click on a zone, you will see it still shows the correct operating mode, which will be one of FollowSchedule, TemporaryOverride, or PermanentOverride
It will also show FrostProtect, and - for TRVs - I am still trying to work out how to make it say OpenWindowMode when they are in that mode.
if self._params[CONF_USE_HEURISTICS]:
if tcs_opmode == EVO_RESET: # TCS is the controller
state = EVO_AUTO
elif tcs_opmode == EVO_HEATOFF:
state = EVO_FROSTMODE
elif zone_opmode == EVO_FOLLOW:
state = tcs_opmode
1 Like
Background: In the old days, you may have seen the graph of a zone’s current_temperature() go completely horizontal. This was not a room that had a 100% stable temperature for several hours, but is caused when HA isn’t getting updates for the attributes of that entity for a period of time.
A good example of this is my post on July 19, look at before and after 8pm. Any variation before 8pm is just when I rebooted HA.
Answer: I added some code to detect ‘unavailable’ zones and this is the first time I have seen this in the real world! These are zones that have not had an update, an so their data is stale:
no_recent_updates = self._timers['statusUpdated'] < datetime.now() - \
timedelta(seconds=self._params[CONF_SCAN_INTERVAL] * 2.1)
if no_recent_updates:
# unavailable because no successful update()s (but why?)
self._available = False
elif not self._status
# unavailable because no status (but how? other than at startup?)
self._available = False
elif self._status and (self._type & EVO_SLAVE):
# (un)available because (web site via) client api says so
self._available = \
bool(self._status['temperatureStatus']['isAvailable'])
else:
self._available = True
(as an aside, my code defers the first status check until after HA starts, so you will see the zones are unavailable immediately after HA started)
Can you check that it is actually available? I’d be interested to know.
If only one zone is unavailable, then it’s because of self._status['temperatureStatus']['isAvailable'], which is coming from Honeywell’s web servers.
I can’t really comment on this for now, but do you have use_schedules = true ?
If so, I have almost completed a big re-write in this area - just waiting for some upstream bugs to clear so I can test…
Yes it’s available on the honeywell app and web ui
Are you running with homeassistant.components.evohome: debug? In any case, could you cat homeassistant.log | grep vailable (no A) for me?
evohome:
username: Redacted
password: Redacted
scan_interval: 60
high_precision: true
use_heuristics: true
use_schedules: true
location_idx: 0
Another issue the highlighted zone (man cave) appears to have the temporary override of the guest bed??
this is how it looks in the app
log (2).yaml (80.1 KB)
I enabled the debug logging which is attached
log seems to think its available?
2018-08-30 09:18:51 DEBUG (Thread-5) [homeassistant.components.evohome] update(slave=929528),
self._status = {'zoneId': '929528', 'highPrecisionTemp': 19.11, 'activeFaults': [], 'name': 'Guest Bed',
'temperatureStatus': {'temperature': 22.0, 'isAvailable': True}, 'setpoint': 14.5, 'setpointStatus':
{'targetHeatTemperature': 21.0, 'setpointMode': 'TemporaryOverride', 'until': '2018-08-30T08:30:00Z'}}A minimal configuration.yaml is as as below:
evohome:
username: !secret evohome_username
password: !secret evohome_password
# These config parameters are presented with their default values:
# scan_interval: 300 # seconds, you can probably get away with 60
# high_precision: true # tenths instead of halves
# location_idx: 0 # if you have more than 1 location, use this
# These config parameters are YMMV:
# use_heuristics: false # this is for the highly adventurous person
# use_schedules: false # this is for the adventurous person
# away_temp: 15.0 # if you have a non-default Away temp
# off_temp: 5.0 # if you have a non-default Heating Off temp
Hi, would you like to try the latest version? I found/squash some bugs.
Will do what does the use schedule option actually allow? Does it allow you to set the override u till a time
?
If you set ‘use_schedules’ to ‘true’, it retrieves each zone’s schedule, and updates it once every hour.
Other than just having this data available, this also allows:
- when you change a zone’s temp or mode and do not specify an ‘until’ datetime, it will use the time of next scheduled setpoint (otherwise for 1 hour)
if self._params[CONF_USE_SCHEDULES]:
until = self._next_switchpoint_time
else:
until = datetime.now() + timedelta(hours=1)
- if a setpoint temperature is needed, it can use the scheduled setpoint, rather than the current setpoint/target temp (these 3 temps are not necessarily the same)