From e3bb0150d4ca64688012eb50dd3c2de396a2ec2c Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 11:10:56 +0000 Subject: [PATCH 01/20] initial commit --- source/_integrations/evohome.markdown | 72 ++++++++++++++++----------- 1 file changed, 44 insertions(+), 28 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index a1737e2f35e7..d9cbbcace1b0 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -1,6 +1,6 @@ --- title: Honeywell Total Connect Comfort (Europe) -description: Instructions on how to integrate a Honeywell evohome/TCC system with Home Assistant. +description: Instructions on how to integrate a Honeywell Evohome/TCC system with Home Assistant. logo: honeywell.png ha_category: - Hub @@ -12,29 +12,37 @@ ha_codeowners: - '@zxdavb' --- -The `evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: +The `Evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: -- the Honeywell evohome CH/DHW system, and +- the Honeywell Evohome CH/DHW system, and - the Honeywell Round Thermostat - the Honeywell Mobile Access Kit It does not support the home security functionality of TCC. -It uses the [evohome-async](https://github.com/zxdavb/evohome-async) client library. +It uses the [Evohome-async](https://github.com/zxdavb/evohome-async) client library. -If your system is compatible with this integration, then you will be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the `international`). +For your system to be compatible with this integration, then you must be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the `international`). + +## Locations and Zones + +TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: + - the system location (e.g. house) is used for home, away, economy modes + - a heating zone (e.g. room) is used for target temperature ### Evohome -Evohome is a multi-zone system. Each zone is represented as a **Climate** entity: it will expose the zone's operating mode, temperature and setpoint. +Each zone is represented as a **Climate** entity which will expose the zone's operating mode, current temperature and setpoint. + +The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode (see below for details). Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. -The location (controller) is also represented as a **Climate** entity: it will expose the location's operating mode (see below for details). Note that the entity's current temperature is calculated as an average of all the Zones. +The DHW controller is represented as a **WaterHeater** entity which will report its current temperature, and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported, and cannot be changed. -The DHW controller is represented as a **WaterHeater** entity: It will report its current temperature, and it can be turned on or off. The setpoint is not reported, and cannot cannot be changed. +Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality) ### Round Thermostat -Such systems usually have only one Round Thermostat, although they can have two. Systems with one such thermostat are merged into a single **Climate** entity. Systems with two thermostats will have a 3rd entity for the TCC locations, much like evohome, above. +Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location mode (away, economy, etc.), and another for the zone setpoint. ## Configuration @@ -42,7 +50,7 @@ To set up this integration, add the following to your **configuration.yaml** fil ```yaml # Example configuration.yaml entry -evohome: +Evohome: username: YOUR_USERNAME password: YOUR_PASSWORD ``` @@ -62,25 +70,33 @@ location_idx: type: integer default: 0 scan_interval: - description: How often updates are retrieved from Honeywell's web servers. The minimum value is 60 seconds. + description: How often updates are retrieved from the vendor's web servers. The minimum interval is 60 seconds. required: false type: integer default: 300 {% endconfiguration %} -This is an IoT cloud-polling integration, and the recommended `scan_interval` is 180 seconds. Testing has indicated that this is a safe interval that - by itself - shouldn't cause you to be rate-limited by Honeywell. +This is an IoT cloud-polling integration, and the recommended minimum `scan_interval` is 180 seconds. Testing has indicated that this is a safe interval that - by itself - shouldn't cause you to be rate-limited by the vendor. There is little value in shorter intervals, as this integration will automatically force a refresh shortly after any configuration changes. ## System modes, Zone overrides and Inheritance -Evohome locations support up to six distinct operating modes: **Auto**, **AutoWithEco**, **Away**, **DayOff**, **HeatingOff**, and **Custom**. Not all evohome systems support all modes. +TCC locations can support up to six distinct operating modes: **Auto**, **AutoWithEco**, **Away**, **DayOff**, **HeatingOff**, and **Custom**. Not all systems support all modes. + +Zones support three setpoint modes: **FollowSchedule**, **TemporaryOverride**, and **PermanentOverride** but 'inherit' an operating mode from their location (the actual algorithm for this is a little more complicated than indicated below - please see the vendor's documentation). + +For **FollowSchedule**, a zone's `setpoint` (target temperature) is a function of its scheduled target temperature and its inherited mode: + +- **Auto** setpoints are scheduled temperatures (the default) +- **AutoWithEco** setpoints are scheduled temperatures, less 3 °C -Zones support three setpoint modes: **FollowSchedule**, **TemporaryOverride**, and **PermanentOverride** but 'inherit' an operating mode from their location (the actual algorithm for this is a little more complicated than indicated below - please see your vendor's documentation). +If the zone's target temperature is changed, then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** at the next scheduled setpoint (or in an hour, if there is no such schedule). A **PermanentOverride** is a permanent change. Zones can be switched between the two override modes without changing the target temperature. -For **FollowSchedule**, a zone's `temperature` (target temperature, a.k.a setpoint) is a function of its scheduled temperature and its inherited mode. For example, **AutoWithEco** would be scheduled temperature less 3C. +For some location modes all zones will have a setpoint enforced upon them, regardless of their own mode: -If the location is set to **HeatingOff** (temperature set to a minimum) or **Away** (temperature set to 12C), then the zones will inherit that setpoint regardless of their own mode. For **Away**, the DHW controller will also be turned off. +- **Away** setpoints to 12 °C +- **HeatingOff** setpoints to a minimum, usually 4 °C -If the zone's temperature is changed, then it will be a **TemporaryOverride** that will revert to **FollowSchedule** at the next scheduled setpoint (or in an hour, if there is no such schedule). Zones can be switched between the two override modes without changing the target temperature. +For **Away**, the DHW controller will also be turned off. Some locations have a hidden mode, **AutoWithReset**, that will behave as **Auto**, and will reset all zones to **FollowSchedule**. @@ -88,33 +104,33 @@ In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and ## Service Calls -This integration provide service calls to expose the full functionality of evohome beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). +This integration provide service calls to expose the full functionality of TCC systems beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). -### evohome.set_system_mode +### Evohome.set_system_mode -This service call is used to set the system `mode`, either indefinitely, or for a set period of time, after which it will revert to **Auto** mode. +This service call is used to set the location `mode`, either indefinitely, or for a set period of time, after which it will revert to **Auto** mode. -For some modes, such as **Away**, the duration is in `days`, where 1 day will revert after midnight, and 2 days reverts at midnight tomorrow. For other modes, such as **AutoWithEco**, the duration is in `hours`. +For some modes, such as **Away**, the duration is in `days`, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. For other modes, such as **AutoWithEco**, the duration is in `hours`. -### evohome.reset_system +### Evohome.reset_system This service call is used to set the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. -### evohome.refresh_system +### Evohome.refresh_system -This service call is used to pull the latest state data from the vendor's servers. +This service call is used to pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. -### evohome.set_zone_override +### Evohome.set_zone_override This service call is used to set the `temperature` of a zone as identified by its `entity_id`. This change can either be indefinite, or for a set period of time, after which it will revert to **FollowSchedule**. The duration can be in `minutes` from the current time, or `until` a specified time within the next 24 hours. -### evohome.clear_zone_override +### Evohome.clear_zone_override This service call is used to set a zone, as identified by its `entity_id`, to **FollowSchedule**. ## Useful Jinja Templates -The actual operating mode of evohome entities can be tracked via their state attributes, which includes a JSON data structure for the current state called `status`. +The actual operating mode of Evohome entities can be tracked via their state attributes, which includes a JSON data structure for the current state called `status`. For the location (controller), see `system_mode_status`: @@ -144,7 +160,7 @@ The Zones will expose the current/upcoming scheduled `setpoints`: ``` {% endraw %} -All evohome entities may have faults, and these can be turned into sensors, or: +All Evohome entities may have faults, and these can be turned into sensors, or: {% raw %} ```text From 81b2eeb7f90b792ebd8605b9173fd48465b928bf Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 11:18:39 +0000 Subject: [PATCH 02/20] small fixes --- source/_integrations/evohome.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index d9cbbcace1b0..1a66980f550e 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -20,15 +20,15 @@ The `Evohome` integration links Home Assistant with all _non-US_ [Honeywell Tota It does not support the home security functionality of TCC. -It uses the [Evohome-async](https://github.com/zxdavb/evohome-async) client library. +It uses the [evohome-async](https://github.com/zxdavb/evohome-async) client library. For your system to be compatible with this integration, then you must be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the `international`). ## Locations and Zones TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: - - the system location (e.g. house) is used for home, away, economy modes - - a heating zone (e.g. room) is used for target temperature + - the system location (e.g. house) is used for operating modes such as home, away, economy, etc. + - heating zones (e.g. rooms) are used for target temperature ### Evohome From a78029cf8abefd0d0fd6a7476c44ddacaa9b4c2e Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 11:29:24 +0000 Subject: [PATCH 03/20] small fixes 2 --- source/_integrations/evohome.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 1a66980f550e..3b20ac5805ea 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -38,11 +38,11 @@ The Evohome location (controller) is also represented as a **Climate** entity wh The DHW controller is represented as a **WaterHeater** entity which will report its current temperature, and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported, and cannot be changed. -Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality) +Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality). ### Round Thermostat -Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location mode (away, economy, etc.), and another for the zone setpoint. +Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location mode (away, economy, etc.), and another for the zone setpoint. ## Configuration @@ -50,7 +50,7 @@ To set up this integration, add the following to your **configuration.yaml** fil ```yaml # Example configuration.yaml entry -Evohome: +evohome: username: YOUR_USERNAME password: YOUR_PASSWORD ``` From eba1ff533ec06dff9b51de921abc5dca90c321ff Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 11:40:48 +0000 Subject: [PATCH 04/20] small fixes 3 --- source/_integrations/evohome.markdown | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 3b20ac5805ea..e423a50169af 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -12,7 +12,7 @@ ha_codeowners: - '@zxdavb' --- -The `Evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: +The `evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: - the Honeywell Evohome CH/DHW system, and - the Honeywell Round Thermostat @@ -34,19 +34,19 @@ TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, Each zone is represented as a **Climate** entity which will expose the zone's operating mode, current temperature and setpoint. -The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode (see below for details). Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. +The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode. Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. -The DHW controller is represented as a **WaterHeater** entity which will report its current temperature, and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported, and cannot be changed. +The DHW controller is represented as a **WaterHeater** entity which will report its current temperature and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported and cannot be changed. Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality). ### Round Thermostat -Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location mode (away, economy, etc.), and another for the zone setpoint. +Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location for mode (away, economy, etc.), and another for the zone setpoint. ## Configuration -To set up this integration, add the following to your **configuration.yaml** file: +To set up this integration add the following to your **configuration.yaml** file: ```yaml # Example configuration.yaml entry @@ -76,7 +76,7 @@ scan_interval: default: 300 {% endconfiguration %} -This is an IoT cloud-polling integration, and the recommended minimum `scan_interval` is 180 seconds. Testing has indicated that this is a safe interval that - by itself - shouldn't cause you to be rate-limited by the vendor. There is little value in shorter intervals, as this integration will automatically force a refresh shortly after any configuration changes. +This is an IoT cloud-polling integration and the recommended minimum `scan_interval` is 180 seconds. Testing has indicated that this is a safe interval that - by itself - shouldn't cause you to be rate-limited by the vendor. There is little value in shorter intervals, as this integration will automatically force a refresh shortly after any configuration changes. ## System modes, Zone overrides and Inheritance @@ -89,7 +89,7 @@ For **FollowSchedule**, a zone's `setpoint` (target temperature) is a function o - **Auto** setpoints are scheduled temperatures (the default) - **AutoWithEco** setpoints are scheduled temperatures, less 3 °C -If the zone's target temperature is changed, then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** at the next scheduled setpoint (or in an hour, if there is no such schedule). A **PermanentOverride** is a permanent change. Zones can be switched between the two override modes without changing the target temperature. +If the zone's target temperature is changed then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** at the next scheduled setpoint (or in an hour, if there is no such schedule). A **PermanentOverride** is a permanent change until some intervention is made. For example, zones can be switched between the two override modes without changing the target temperature. For some location modes all zones will have a setpoint enforced upon them, regardless of their own mode: @@ -106,25 +106,25 @@ In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and This integration provide service calls to expose the full functionality of TCC systems beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). -### Evohome.set_system_mode +### evohome.set_system_mode This service call is used to set the location `mode`, either indefinitely, or for a set period of time, after which it will revert to **Auto** mode. For some modes, such as **Away**, the duration is in `days`, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. For other modes, such as **AutoWithEco**, the duration is in `hours`. -### Evohome.reset_system +### evohome.reset_system This service call is used to set the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. -### Evohome.refresh_system +### evohome.refresh_system This service call is used to pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. -### Evohome.set_zone_override +### evohome.set_zone_override This service call is used to set the `temperature` of a zone as identified by its `entity_id`. This change can either be indefinite, or for a set period of time, after which it will revert to **FollowSchedule**. The duration can be in `minutes` from the current time, or `until` a specified time within the next 24 hours. -### Evohome.clear_zone_override +### evohome.clear_zone_override This service call is used to set a zone, as identified by its `entity_id`, to **FollowSchedule**. From caf3d8210af944fc4511d99a4b07f273b4850b7c Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 13:10:00 +0000 Subject: [PATCH 05/20] latest tweaks --- source/_integrations/evohome.markdown | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index e423a50169af..6f1976ebff8c 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -12,22 +12,21 @@ ha_codeowners: - '@zxdavb' --- -The `evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: +The **evohome** integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: - the Honeywell Evohome CH/DHW system, and -- the Honeywell Round Thermostat -- the Honeywell Mobile Access Kit +- the Honeywell Mobile Access Kit with a Round Thermostat It does not support the home security functionality of TCC. It uses the [evohome-async](https://github.com/zxdavb/evohome-async) client library. -For your system to be compatible with this integration, then you must be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the `international`). +For your system to be compatible with this integration, then you must be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the 'international'). ## Locations and Zones TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: - - the system location (e.g. house) is used for operating modes such as home, away, economy, etc. + - the system location (e.g. a house) is used for operating modes such as home, away, economy, etc. - heating zones (e.g. rooms) are used for target temperature ### Evohome @@ -42,7 +41,7 @@ Note that there is limited support for schedules: they cannot be changed and the ### Round Thermostat -Such systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one location for mode (away, economy, etc.), and another for the zone setpoint. +These systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one for location mode (away, economy, etc.), and another for the zone setpoint. ## Configuration @@ -57,7 +56,7 @@ evohome: {% configuration %} username: - description: The username (email address) that has access to [Honeywell TCC](https://international.mytotalconnectcomfort.com/Account/Login) web site. + description: The username (email address) that has access to the [TCC](https://international.mytotalconnectcomfort.com/Account/Login) web site. required: true type: string password: From 6f9e3679a7ee30cc267b1775f0136326ead99513 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sat, 8 Feb 2020 21:47:06 +0000 Subject: [PATCH 06/20] samples --- source/_integrations/evohome.markdown | 82 ++++++++++++++++++++------- 1 file changed, 61 insertions(+), 21 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 6f1976ebff8c..81d6d1e61ad6 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -23,26 +23,6 @@ It uses the [evohome-async](https://github.com/zxdavb/evohome-async) client libr For your system to be compatible with this integration, then you must be able to access it via [https://international.mytotalconnectcomfort.com/](https://international.mytotalconnectcomfort.com/) (note the 'international'). -## Locations and Zones - -TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: - - the system location (e.g. a house) is used for operating modes such as home, away, economy, etc. - - heating zones (e.g. rooms) are used for target temperature - -### Evohome - -Each zone is represented as a **Climate** entity which will expose the zone's operating mode, current temperature and setpoint. - -The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode. Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. - -The DHW controller is represented as a **WaterHeater** entity which will report its current temperature and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported and cannot be changed. - -Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality). - -### Round Thermostat - -These systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one for location mode (away, economy, etc.), and another for the zone setpoint. - ## Configuration To set up this integration add the following to your **configuration.yaml** file: @@ -77,6 +57,32 @@ scan_interval: This is an IoT cloud-polling integration and the recommended minimum `scan_interval` is 180 seconds. Testing has indicated that this is a safe interval that - by itself - shouldn't cause you to be rate-limited by the vendor. There is little value in shorter intervals, as this integration will automatically force a refresh shortly after any configuration changes. +## Locations and Zones + +TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: + - the system location (e.g. a house) is used for operating modes such as home, away, economy, etc. + - heating zones (e.g. rooms) are used for target temperature + +### Evohome + +Each zone is represented as a **Climate** entity which will expose the zone's operating mode, current temperature and setpoint. + +The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode. Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. + +The DHW controller is represented as a **WaterHeater** entity which will report its current temperature and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported and cannot be changed. + +Note that there is limited support for schedules: they cannot be changed and there is no facility to backup/restore that data (see [here](https://evohome.readthedocs.io/en/latest/) for such functionality). + +### Round Thermostat + +These systems use an internet gateway rather than an Evohome controller. They usually have only one Round Thermostat, although they can have two. Systems with one such thermostat will still appear as two **Climate** entities, one for location mode (away, economy, etc.), and another for the zone setpoint. + +## Temperature Precision + +Note that TCC devices may well measure temperatures with very high precision, but the vendor API will report temperatures rounded _towards_ the setpoint (i.e. either up or down) with a precision of 0.5 °C; this a proxy for the deadband as used by other climate systems. Where possible, this integration will leverage an older vendor API to obtain current temperatures with a precision of 0.01 °C. + +Depending upon the above, Home Assistant will display/record current temperatures with a precision of either 0.5 °C or 0.1 °C (it's highest supported precision). In addition, if higher-precision temperatures are obtained, it will be possible to access them via each entity's device state attributes. + ## System modes, Zone overrides and Inheritance TCC locations can support up to six distinct operating modes: **Auto**, **AutoWithEco**, **Away**, **DayOff**, **HeatingOff**, and **Custom**. Not all systems support all modes. @@ -103,7 +109,9 @@ In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and ## Service Calls -This integration provide service calls to expose the full functionality of TCC systems beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). +This integration provides its own service calls to expose the full functionality of TCC systems beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). + +It is recommended to use the native service calls instead of the generic equivalents whenever possible. ### evohome.set_system_mode @@ -111,6 +119,23 @@ This service call is used to set the location `mode`, either indefinitely, or fo For some modes, such as **Away**, the duration is in `days`, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. For other modes, such as **AutoWithEco**, the duration is in `hours`. +{% raw %} +```yaml +- alias: Set evo_home to Away mode if > 20km distant + trigger: + - platform: numeric_state + entity_id: proximity.home + above: 20000 + action: + - service: evohome.set_system_mode + data: + entity_id: climate.loungeroom + mode: Away + period: + days: 1 +``` +{% endraw %} + ### evohome.reset_system This service call is used to set the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. @@ -123,6 +148,21 @@ This service call is used to pull the latest state data from the vendor's server This service call is used to set the `temperature` of a zone as identified by its `entity_id`. This change can either be indefinite, or for a set period of time, after which it will revert to **FollowSchedule**. The duration can be in `minutes` from the current time, or `until` a specified time within the next 24 hours. +{% raw %} +```yaml +- alias: handle_open_window + trigger: + platform: state + entity_id: sensor.window + to: open + action: + - service: evohome.set_zone_override + data: + entity_id: climate.loungeroom + setpoint: 10 +``` +{% endraw %} + ### evohome.clear_zone_override This service call is used to set a zone, as identified by its `entity_id`, to **FollowSchedule**. From 74550a89989f245e1c9e1abd1c0801a452256f54 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 14:33:08 +0000 Subject: [PATCH 07/20] tidy up --- source/_integrations/evohome.markdown | 38 ++++++++++++++++++++------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 81d6d1e61ad6..addbb59d2009 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -115,42 +115,61 @@ It is recommended to use the native service calls instead of the generic equival ### evohome.set_system_mode -This service call is used to set the location `mode`, either indefinitely, or for a set period of time, after which it will revert to **Auto** mode. +This service call will set the operating `mode` of the system for a specified period of time, after which it will revert to **Auto**. However, if no period of time is provided, then the change is permanent. -For some modes, such as **Away**, the duration is in `days`, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. For other modes, such as **AutoWithEco**, the duration is in `hours`. +For **AutoWithEco**, the period of time is a `duration` is up to 24 hours. + +#### Automation example {% raw %} ```yaml -- alias: Set evo_home to Away mode if > 20km distant +- alias: Set Eco mode if > 20km away trigger: - platform: numeric_state entity_id: proximity.home above: 20000 action: + - service: evohome.set_system_mode + data: + entity_id: climate.loungeroom + mode: AutoWithEco + duration: {hours: 1, minutes: 30} +``` +{% endraw %} + +For the other modes, such as **Away**, the duration is a `period` of days, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. + +#### Automation example + +{% raw %} +```yaml +- action: - service: evohome.set_system_mode data: entity_id: climate.loungeroom mode: Away - period: - days: 1 + period: {days: 30} ``` {% endraw %} ### evohome.reset_system -This service call is used to set the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. +This service call will set the operating mode of the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. ### evohome.refresh_system -This service call is used to pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. +This service call will pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. ### evohome.set_zone_override -This service call is used to set the `temperature` of a zone as identified by its `entity_id`. This change can either be indefinite, or for a set period of time, after which it will revert to **FollowSchedule**. The duration can be in `minutes` from the current time, or `until` a specified time within the next 24 hours. +This service call will set the `setpoint` of a zone, as identified by its `entity_id`, for a specified period of time (**TemporaryOverride**). However, if no period of time is provided, then the change is permanent (**PermanentOverride**). + +The `duration` can be up to 24 hours, after which the zone mode will revert to schedule (**FollowSchedule**). +#### Automation example {% raw %} ```yaml -- alias: handle_open_window +- alias: Handle open window trigger: platform: state entity_id: sensor.window @@ -160,6 +179,7 @@ This service call is used to set the `temperature` of a zone as identified by it data: entity_id: climate.loungeroom setpoint: 10 + duration: {minutes: 120} ``` {% endraw %} From 51167fb0bc8bd854daf3c0b25d7c55006ba3fa1f Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 14:34:21 +0000 Subject: [PATCH 08/20] tidy up --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index addbb59d2009..88a96c7342ea 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -81,7 +81,7 @@ These systems use an internet gateway rather than an Evohome controller. They us Note that TCC devices may well measure temperatures with very high precision, but the vendor API will report temperatures rounded _towards_ the setpoint (i.e. either up or down) with a precision of 0.5 °C; this a proxy for the deadband as used by other climate systems. Where possible, this integration will leverage an older vendor API to obtain current temperatures with a precision of 0.01 °C. -Depending upon the above, Home Assistant will display/record current temperatures with a precision of either 0.5 °C or 0.1 °C (it's highest supported precision). In addition, if higher-precision temperatures are obtained, it will be possible to access them via each entity's device state attributes. +Depending upon the above, Home Assistant will display/record current temperatures with a precision of either 0.5 °C or 0.1 °C (it's highest supported precision). ## System modes, Zone overrides and Inheritance From f8c10bb4a76174ae6a7e5f17eec0249e4aeb8199 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 14:38:09 +0000 Subject: [PATCH 09/20] small fixes --- source/_integrations/evohome.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 88a96c7342ea..c7daa42bd8eb 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -105,7 +105,7 @@ For **Away**, the DHW controller will also be turned off. Some locations have a hidden mode, **AutoWithReset**, that will behave as **Auto**, and will reset all zones to **FollowSchedule**. -In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and `PRESET_MODE` (but also see the state attributes `systemModeStatus` and `setpointStatus`, below). +In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and `PRESET_MODE` (but also see the state attributes `system_mode_status` and `setpoint_status`, below). ## Service Calls @@ -203,7 +203,7 @@ For the location (controller), see `system_mode_status`: ``` {% endraw %} -For the Zones, it is `setpointStatus`: +For the Zones, it is `setpoint_status`: {% raw %} ```text From 814e7749287c6919293e7dac4fb81edd1e04002e Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 15:47:19 +0000 Subject: [PATCH 10/20] small fixes 2 --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index c7daa42bd8eb..9b443a6e93ac 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -94,7 +94,7 @@ For **FollowSchedule**, a zone's `setpoint` (target temperature) is a function o - **Auto** setpoints are scheduled temperatures (the default) - **AutoWithEco** setpoints are scheduled temperatures, less 3 °C -If the zone's target temperature is changed then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** at the next scheduled setpoint (or in an hour, if there is no such schedule). A **PermanentOverride** is a permanent change until some intervention is made. For example, zones can be switched between the two override modes without changing the target temperature. +If the zone's target temperature is changed then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** after some specified time. A **PermanentOverride** is a permanent change until some subsequent intervention is made. For example, zones can be switched between the two override modes without changing the target temperature. For some location modes all zones will have a setpoint enforced upon them, regardless of their own mode: From 974a74d8c30bbad0a75fb4095cccbb7e3dce90a4 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 17:00:14 +0000 Subject: [PATCH 11/20] small fixes 3 --- source/_integrations/evohome.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 9b443a6e93ac..44c75fb8bee7 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -164,7 +164,7 @@ This service call will pull the latest state data from the vendor's servers rath This service call will set the `setpoint` of a zone, as identified by its `entity_id`, for a specified period of time (**TemporaryOverride**). However, if no period of time is provided, then the change is permanent (**PermanentOverride**). -The `duration` can be up to 24 hours, after which the zone mode will revert to schedule (**FollowSchedule**). +The `duration` can be up to 24 hours, after which the zone mode will revert to schedule (**FollowSchedule**). If the `duration` is 0 hours, then the change will be until the next setpoint. #### Automation example {% raw %} @@ -179,7 +179,7 @@ The `duration` can be up to 24 hours, after which the zone mode will revert to s data: entity_id: climate.loungeroom setpoint: 10 - duration: {minutes: 120} + duration: {minutes: 0} ``` {% endraw %} From 3594de75906f0ca761651c5abea934c459b8a9c8 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 17:38:36 +0000 Subject: [PATCH 12/20] small fixes 4 --- source/_integrations/evohome.markdown | 30 ++++++++++----------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 44c75fb8bee7..8a4e8d52174d 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -119,19 +119,11 @@ This service call will set the operating `mode` of the system for a specified pe For **AutoWithEco**, the period of time is a `duration` is up to 24 hours. -#### Automation example - {% raw %} ```yaml -- alias: Set Eco mode if > 20km away - trigger: - - platform: numeric_state - entity_id: proximity.home - above: 20000 - action: +- action: - service: evohome.set_system_mode data: - entity_id: climate.loungeroom mode: AutoWithEco duration: {hours: 1, minutes: 30} ``` @@ -139,14 +131,11 @@ For **AutoWithEco**, the period of time is a `duration` is up to 24 hours. For the other modes, such as **Away**, the duration is a `period` of days, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. -#### Automation example - {% raw %} ```yaml - action: - service: evohome.set_system_mode data: - entity_id: climate.loungeroom mode: Away period: {days: 30} ``` @@ -164,17 +153,20 @@ This service call will pull the latest state data from the vendor's servers rath This service call will set the `setpoint` of a zone, as identified by its `entity_id`, for a specified period of time (**TemporaryOverride**). However, if no period of time is provided, then the change is permanent (**PermanentOverride**). +{% raw %} +```yaml +- action: + - service: evohome.set_zone_override + data: + entity_id: climate.loungeroom + setpoint: 10 +``` + The `duration` can be up to 24 hours, after which the zone mode will revert to schedule (**FollowSchedule**). If the `duration` is 0 hours, then the change will be until the next setpoint. -#### Automation example {% raw %} ```yaml -- alias: Handle open window - trigger: - platform: state - entity_id: sensor.window - to: open - action: +- action: - service: evohome.set_zone_override data: entity_id: climate.loungeroom From 9dfd9a4f912bc74bdcb5317f9c256bb34ba162f2 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Sun, 9 Feb 2020 18:23:02 +0000 Subject: [PATCH 13/20] small fixes 5 --- source/_integrations/evohome.markdown | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 8a4e8d52174d..b3db9aa06f8a 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -129,7 +129,7 @@ For **AutoWithEco**, the period of time is a `duration` is up to 24 hours. ``` {% endraw %} -For the other modes, such as **Away**, the duration is a `period` of days, where 1 day will revert at midnight, and 2 days reverts at midnight tomorrow. +For the other modes, such as **Away**, the duration is a `period` of days, where 1 day will revert at midnight tonight, and 2 days reverts at midnight tomorrow. {% raw %} ```yaml @@ -145,13 +145,15 @@ For the other modes, such as **Away**, the duration is a `period` of days, where This service call will set the operating mode of the system to **AutoWithReset**, and reset all the zones to **FollowSchedule**. +Not all systems support this feature. + ### evohome.refresh_system -This service call will pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. +This service call will immediately pull the latest state data from the vendor's servers rather than waiting for the next `scan_interval`. ### evohome.set_zone_override -This service call will set the `setpoint` of a zone, as identified by its `entity_id`, for a specified period of time (**TemporaryOverride**). However, if no period of time is provided, then the change is permanent (**PermanentOverride**). +This service call will set the `setpoint` of a zone, as identified by its `entity_id`, for a specified period of time (**TemporaryOverride**). However, if no period of time is provided (c.f. a duration of 0, below), then the change is permanent (**PermanentOverride**). {% raw %} ```yaml From 813fcedf8d7e9a599eb8e640646132937b309743 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 12:59:54 +0000 Subject: [PATCH 14/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index b3db9aa06f8a..6ba0679af716 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -12,7 +12,7 @@ ha_codeowners: - '@zxdavb' --- -The **evohome** integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: +The `evohome` integration links Home Assistant with all _non-US_ [Honeywell Total Connect Comfort (TCC)](https://international.mytotalconnectcomfort.com/Account/Login) CH/DHW systems, such as: - the Honeywell Evohome CH/DHW system, and - the Honeywell Mobile Access Kit with a Round Thermostat From eda29b1cb1f8349f9da28578fd681263d482eb2e Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:00:31 +0000 Subject: [PATCH 15/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 6ba0679af716..40a7bc5a7863 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -25,7 +25,7 @@ For your system to be compatible with this integration, then you must be able to ## Configuration -To set up this integration add the following to your **configuration.yaml** file: +To set up this integration, add the following to your `configuration.yaml` file: ```yaml # Example configuration.yaml entry From a98541ddac6baf4ec32e9d76a6056c4f47ea4944 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:01:12 +0000 Subject: [PATCH 16/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 1 + 1 file changed, 1 insertion(+) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 40a7bc5a7863..3a69a93c106e 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -60,6 +60,7 @@ This is an IoT cloud-polling integration and the recommended minimum `scan_inter ## Locations and Zones TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: + - the system location (e.g. a house) is used for operating modes such as home, away, economy, etc. - heating zones (e.g. rooms) are used for target temperature From 3abc54816e610ddeade7f69ecae3e58179ccbba5 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:01:40 +0000 Subject: [PATCH 17/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 3a69a93c106e..c03635fc7742 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -61,7 +61,7 @@ This is an IoT cloud-polling integration and the recommended minimum `scan_inter TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: - - the system location (e.g. a house) is used for operating modes such as home, away, economy, etc. + - The system location (e.g., a house) is used for operating modes such as home, away, economy, etc. - heating zones (e.g. rooms) are used for target temperature ### Evohome From b4e7bd51870072d006e4405513349032dab2afc0 Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:02:03 +0000 Subject: [PATCH 18/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index c03635fc7742..55c47ece5d9b 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -62,7 +62,7 @@ This is an IoT cloud-polling integration and the recommended minimum `scan_inter TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, optionally, a DHW controller: - The system location (e.g., a house) is used for operating modes such as home, away, economy, etc. - - heating zones (e.g. rooms) are used for target temperature + - Heating zones (e.g., rooms) are used for the target temperature. ### Evohome From 6c76ecb330aa3800f31b1bcf2f64dd2078d3049e Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:02:20 +0000 Subject: [PATCH 19/20] Update source/_integrations/evohome.markdown Co-Authored-By: Franck Nijhof --- source/_integrations/evohome.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 55c47ece5d9b..3e7488f81bd2 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -68,7 +68,7 @@ TCC systems are implemented as a _location_, which consist of 1-12 _zones_ and, Each zone is represented as a **Climate** entity which will expose the zone's operating mode, current temperature and setpoint. -The Evohome location (controller) is also represented as a **Climate** entity which will expose the location's operating mode. Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. +The Evohome location (controller) is also represented as a **Climate** entity that will expose the location's operating mode. Locations have neither a current temperature nor a setpoint, but as all **Climate** entities are required by Home Assistant to report a temperature, this is calculated as the average of all the zones. The DHW controller is represented as a **WaterHeater** entity which will report its current temperature and can be turned on or off. Due to limitations with the vendor's RESTful API, the setpoint is not reported and cannot be changed. From 5aecf46d57f4c18b69cf7c61eed32372372e215c Mon Sep 17 00:00:00 2001 From: David Bonnes Date: Mon, 10 Feb 2020 13:14:20 +0000 Subject: [PATCH 20/20] more tweaks --- source/_integrations/evohome.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/_integrations/evohome.markdown b/source/_integrations/evohome.markdown index 3e7488f81bd2..0fe274fd92af 100644 --- a/source/_integrations/evohome.markdown +++ b/source/_integrations/evohome.markdown @@ -82,7 +82,7 @@ These systems use an internet gateway rather than an Evohome controller. They us Note that TCC devices may well measure temperatures with very high precision, but the vendor API will report temperatures rounded _towards_ the setpoint (i.e. either up or down) with a precision of 0.5 °C; this a proxy for the deadband as used by other climate systems. Where possible, this integration will leverage an older vendor API to obtain current temperatures with a precision of 0.01 °C. -Depending upon the above, Home Assistant will display/record current temperatures with a precision of either 0.5 °C or 0.1 °C (it's highest supported precision). +Therefore, depending upon the above, Home Assistant will display/record current temperatures with a precision of either 0.5 °C or 0.1 °C (it's highest supported precision). ## System modes, Zone overrides and Inheritance @@ -95,7 +95,7 @@ For **FollowSchedule**, a zone's `setpoint` (target temperature) is a function o - **Auto** setpoints are scheduled temperatures (the default) - **AutoWithEco** setpoints are scheduled temperatures, less 3 °C -If the zone's target temperature is changed then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** after some specified time. A **PermanentOverride** is a permanent change until some subsequent intervention is made. For example, zones can be switched between the two override modes without changing the target temperature. +If the zone's target temperature is changed then it will either be a **TemporaryOverride** or a **PermanentOverride**, depending. A **TemporaryOverride** will revert to **FollowSchedule** after some specified time. A **PermanentOverride** is a permanent change until some subsequent intervention is made. Zones can be switched between the two override modes without changing the target temperature. For some location modes all zones will have a setpoint enforced upon them, regardless of their own mode: @@ -106,13 +106,13 @@ For **Away**, the DHW controller will also be turned off. Some locations have a hidden mode, **AutoWithReset**, that will behave as **Auto**, and will reset all zones to **FollowSchedule**. -In Home Assistant schema, all this is done via a combination of `HVAC_MODE` and `PRESET_MODE` (but also see the state attributes `system_mode_status` and `setpoint_status`, below). +In the Home Assistant schema, all this is done via a combination of `HVAC_MODE` and `PRESET_MODE` (but also see the state attributes `system_mode_status` and `setpoint_status`, below). ## Service Calls This integration provides its own service calls to expose the full functionality of TCC systems beyond the limitations of Home Assistant's standardised schema. Mostly, this relates to specifying the duration of mode changes, after which time the entities revert to **Auto** or **FollowSchedule** (for locations and zones, respectively). -It is recommended to use the native service calls instead of the generic equivalents whenever possible. +It is recommended to use the native service calls (e.g., `evohome.set_system_mode`) instead of Home Assistant's generic equivalents (e.g., `climate.set_hvac_mode`) whenever possible. However, it may be necessary to use the generic service calls for integration with 3rd party systems such as Amazon Alexa or Google Home. ### evohome.set_system_mode