Never mind - I figured it out - I just needed to nest the groups:
e.g.
heating:
view: true
name: heating
entities:
- group.heat_hall
etc
heat_hall:
name: Hall temperatures
entities:
- history_graph.hall_temperatures
etc
Can anyone tell me why the graphs for different zones contain gaps in different places? Does this represent comms loss or is it just a graphics glitch?
Sorry got to this too late. Yes in my example, I have 4 columns, one for each floor. You could make one per graph if you want them just to autofill the space dynamically, or divide into how many columns you find useful.
And you are correct, gaps in the graph are simply places where HomeAssistant couldn’t retrieve data… Could be the component didn’t start properly (happens if you restart a lot), or gaps where you restarted, or problems connecting to the evohome API.
Also, for anyone who wants to do this in lovelace, here’s how it looks. I also put the standard climate component below the graph in case you want to touch it and change the climate.
- title: Climate
icon: mdi:radiator
cards:
- type: vertical-stack
cards:
- type: history-graph
title: 'Entrance'
entities:
- climate.entrance
- type: entities
entities:
- climate.entrance
- type: vertical-stack
cards:
- type: history-graph
title: 'Play Room'
entities:
- climate.dining_room
- type: entities
entities:
- climate.dining_room
- type: vertical-stack
cards:
- type: history-graph
title: 'Living Room'
entities:
- climate.living_room
- type: entities
entities:
- climate.living_room
- type: vertical-stack
cards:
- type: history-graph
title: 'Master Bedroom'
entities:
- climate.master_bedroom
- type: entities
entities:
- climate.master_bedroom
- type: vertical-stack
cards:
- type: history-graph
title: 'Master Bath'
entities:
- climate.master_bath
- type: entities
entities:
- climate.master_bath
- type: vertical-stack
cards:
- type: history-graph
title: 'Master Closet'
entities:
- climate.master_closet
- type: entities
entities:
- climate.master_closet
- type: vertical-stack
cards:
- type: history-graph
title: 'Office / Library'
entities:
- climate.office__library
- type: entities
entities:
- climate.office__library
- type: vertical-stack
cards:
- type: history-graph
title: "Sebastian's Room"
entities:
- climate.sebastians_room
- type: entities
entities:
- climate.sebastians_room
- type: vertical-stack
cards:
- type: history-graph
title: "Sophie's Room"
entities:
- climate.sophies_room
- type: entities
entities:
- climate.sophies_room
- type: vertical-stack
cards:
- type: history-graph
title: 'Gym'
entities:
- climate.guest_bedroom
- type: entities
entities:
- climate.guest_bedroom
- type: vertical-stack
cards:
- type: history-graph
title: 'Garage'
entities:
- climate.garage
- type: entities
entities:
- climate.garage
- type: vertical-stack
cards:
- type: history-graph
title: 'Laundry Room'
entities:
- climate.laundry_room
- type: entities
entities:
- climate.laundry_roomIndeed, not using DNSSEC or host files. I’ll try changing to a different DNS provider when I get home…
How do you set the Evohome to follow schedule in the official component? I used to call operation mode = FollowSchedule on the custom component but it’s stopped working when I’ve switched to the official - I tried changing it to operation mode = Auto but still no luck… Thanks!
HA is firmly restrictive with regards to available operating modes.
This reduces the functionality available via the official component, so I think there will always be a place for the custom component version (this is all up for grabs with Climate v2). For example, the official component has no way to set the controller to DayOff mode.
In your case, HA does not support the concept of FollowSchedule, so I have had to map HA modes to evohome modes (and vice versa) as best I could:
HA_STATE_TO_ZONE = {
STATE_AUTO: EVO_FOLLOW,
STATE_MANUAL: EVO_PERMOVER
}
From this, if you set a zone to auto via HA, then evohome will receive a message to set to FollowSchedule. Please note: STATE_AUTO = 'auto' (and not ‘Auto’)
Here are the rest:
# for the Controller. NB: evohome treats Away mode as a mode in/of itself,
# where HA considers it to 'override' the exising operating mode
TCS_STATE_TO_HA = {
EVO_RESET: STATE_AUTO,
EVO_AUTO: STATE_AUTO,
EVO_AUTOECO: STATE_ECO,
EVO_AWAY: STATE_AUTO,
EVO_DAYOFF: STATE_AUTO,
EVO_CUSTOM: STATE_AUTO,
EVO_HEATOFF: STATE_OFF
}
HA_STATE_TO_TCS = {
STATE_AUTO: EVO_AUTO,
STATE_ECO: EVO_AUTOECO,
STATE_OFF: EVO_HEATOFF
}
# for the Zones...
ZONE_STATE_TO_HA = {
EVO_FOLLOW: STATE_AUTO,
EVO_TEMPOVER: STATE_MANUAL,
EVO_PERMOVER: STATE_MANUAL
}
HA_STATE_TO_ZONE = {
STATE_AUTO: EVO_FOLLOW,
STATE_MANUAL: EVO_PERMOVER
}
Please let me know if you are still having problems after reading this…
Thanks @zxdavb !
I still seem to be getting the issue, see the automations below. The unoccupied one works but not the occupied one…
automation:
- alias: 'Unoccupied heating'
trigger:
- platform: state
entity_id: input_boolean.occupied
to: 'off'
action:
- service: climate.set_temperature
data:
entity_id: group.radiators_ex_utility_guest
temperature: 15
operation_mode: manual
- alias: 'Occupied heating'
trigger:
- platform: state
entity_id: input_boolean.occupied
to: 'on'
action:
- service: climate.set_operation_mode
data:
entity_id: group.radiators_ex_utility_guest
operation_mode: autoOK, initial testing my end has revealed nothing - I will do more detailed testing when I get a chance.
In the meantime, you can try the dev tools section of the website, and/or have a look at your logs.
{
"entity_id": "climate.bathroom",
"operation_mode": "auto"
}
Thanks for your help. Could it be that auto needs to be in quotes?
Your component works like a charm, but I use Alexa and one of my device was returning error, I do some research and see that the thermostat mode was manual, in the HA log this is the error: homeassistant.components.alexa.smart_home._UnsupportedProperty: thermostatMode and from the Alexa documentation the thermostateMode can be set to “AUTO”, “COOL”, “ECO”, “HEAT” and “OFF”
So where is the problem, you use not standard HA thermostat mode or the HA alexa component must be fixed? What to do?
Did you try it in quotes?
I know nothing about Alexa, Google and the Apple equivalent. However, I understand that if I have the correct modes, then such integration should be seamless.
IIRC, I was told that STATE_MANUAL was such a mode, when the evidence you provide indicates that it is not.
If your issue is with the custom component version, please confirm in this thread whether it also affects the official/HA version of the component.
If your problem is with the official component, please submit a bug report at Issues · home-assistant/core · GitHub (if there isn’t one already).
If you are not sure which version you are using, just look at HA’s log file, grep evohome homeassistant.log, it will have either:
[homeassistant.components.climate.evohome] - official version, or[custom_components.evohome] - custom componentThere are currently irreconcilable differences between the two versions, and it may will be the case that you’ll have to run both! You can achieve this by renaming the custom version.
BTW, there is such an argument about the difference between state, and mode, and even between operation mode (as requested), and operating mode (as happening), but let’s ignore that for now…
Ok it’s with the official version, your version that was accepted into HA 0.84, I found an issue with the same problem reported: https://github.com/home-assistant/home-assistant/issues/17874
Why did you say that I’ll have to run also the custom component?
It is the case, and I suspect that it will always be the case that one will never be a functional super-set of the other.
The official/built-in component is 100% compatible with HA, the custom component has the most / will have complete functionality (e.g. reset mode for the controller).
I am waiting to get the built-in version up to date with the current version of the custom component (e.g. adding DHW support) before I clean up / add further functionality to the custom component (e.g. schedules).
Hi Dave,
Occasionally I’ve noticed the custom component of Evohome fail to load due to the error shown below, as a result of rebooting HA a few times within a short timeframe.
2019-01-10 21:06:06 INFO (MainThread) [homeassistant.loader] Loaded evohome from custom_components.evohome
2019-01-10 21:06:06 WARNING (MainThread) [homeassistant.loader] You are using a custom component for evohome which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-01-10 21:06:06 INFO (MainThread) [homeassistant.setup] Setting up evohome
2019-01-10 21:06:06 DEBUG (SyncWorker_3) [custom_components.evohome] setup(): Configuration parameters: {'username': 'REDACTED', 'password': 'REDACTED', 'scan_interval': 300, 'high_precision': True, 'away_temp': 15.0, 'dhw_target_temp': 54.0, 'off_temp': 5.0, 'location_idx': 0, 'use_schedules': False, 'use_heuristics': False}
2019-01-10 21:06:06 DEBUG (SyncWorker_3) [custom_components.evohome] setup(): API call [4 request(s)]: client.__init__()...
2019-01-10 21:06:07 ERROR (SyncWorker_3) [custom_components.evohome] TOO MANY REQUESTS
2019-01-10 21:06:07 INFO (MainThread) [homeassistant.setup] Setup of domain evohome took 1.0 seconds.
2019-01-10 21:06:07 ERROR (MainThread) [homeassistant.setup] Setup failed for evohome: Component failed to initialize.
It’s not really a problem as another reboot usually fixes it, but I’m curious to know if anything can be done to cater for this please?
Here is a section of the relevant code:
_LOGGER.debug("setup(): API call [4 request(s)]: client.__init__()...")
try:
client = EvohomeClient(
evo_data['params'][CONF_USERNAME],
evo_data['params'][CONF_PASSWORD]
)
except HTTPError as err:
if err.response.status_code == HTTP_TOO_MANY_REQUESTS:
_LOGGER.error("TOO MANY REQUESTS")
return False # unable to continue
What is is saying is simply that when the component tries to substantiate the client object, Honeywell’s web servers are complaining that their API rate limit has been exceeded.
Personal experience is that if you immediately restart HA, it will then go through OK.
I was toying with the idea of having a second go at it in the component (i.e. return False only after the 2nd attempt to instantiate the client), but I felt a bit awkward about bypassing Honeywell’s rate limits in that way.
Ah yes I see, makes sense.
Perhaps it could be a configurable option to try once more before failing, say 5 or 10 seconds later, so that the onus is on the user? e.g.
evohome:
toomayrequests_2ndtry: true #or something more eloquent
It’s not that simple. For example, the client is substantiated during HA startup, and (there are so many threads to be had and thus) HA takes a dim view on components that take a while to start up.
I may do this on the custom component, but never in the official version.
No problems, restarting HA again is straight forward so I’m happy to do that. Thanks for looking into this.
Sorry @zxdavb I’ve been away from a few days… Yep tried it in quotes and still no luck, any thoughts?