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)
Would it be possible to provide some guidance on how to address the entities delivered by this component?
Under the old honeywell component they would typically be
climate.kitchen
climate.living_room etc etc
I’ve tried
evohome.kitchen
evohome.living_room
but this doesn’t seem to do anything. Thank in advance
Assuming you’re not running honeywell.py at the same time, they should have the same name. That is:
climate.kitchen
Can you not see them in the log file (grep evohome, or grep climate), or the Web UI (Developer Tools, States).
I should have said, only if no until is explicitly declared (and one is needed, e.g. TemporaryOverride), then it will be 1 hour, or until next setpoint.
You cannot explicitly set an until via the Web UI, but you can if you’re calling a service.
I was using the declaration earlier in the post from ’ jarrah’, but I get a status of ‘unknown’ which tells me I still haven’t been able to get the component to retrieve from the honeywell server yet.
Beginning to wish I’d not started down the hassio route as it’s not helping at all.
Thanks
I am not sure which post you’re referring to, but if it’s the one with group & sensor, you can leave that out until after you get the entities in your UI.
Maybe I could help - but you’d have to provide more info. What does your logs look like?
And always use the latest version of the component, as I am tweaking it all the time!