Climate Honeywell Evohome shows operation mode as Off by default

[brownad]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version): 0.60.0

Python release (python3 --version): 3.5.3

Component/platform: climate.honeywell

Description of problem: Using the Honeywell / Evohome component, it always sets the operation mode to Off for the radiators by default. Despite being set to Heat from the Evohome itself, the temp readings for current and the heat to are correct, just the mode is wrong. So net effect when this flow through to Homebridge, it will show Heat / On thermostats as Off in their mode. Which is wrong, a long time ago it used to show as a correct setting to Auto. If I try to override this in the HASS settings it will disappear on the next update, so I'm guessing it is being read back from the evohome py client library and defaulting to Off all the time. Also there are no operation_modes available for the client to set inside the UI for HASS, its just unclickable.

Expected: It should read the current settings from Evohome and show the operation mode correctly.

Problem-relevant configuration.yaml entries and steps to reproduce:

1. Need to have Evohome radiator thermostats
2. Load them up in HASS
3. Notice they are always Off in their operation mode despite being set to Heat in the source Evohome controller.

Traceback (if applicable):

None

Additional info:

[JvS68]

Seeing the same behaviour. In addition when I manually change the target temperature through HA for one of the Evohome zones, the zone keeps showing as 'off'. It also caused an error email to come from the Evohome backend telling me that a remote attempt to change a zone (temperature) has failed.

HA 0.60 / Python 3.6.4

[ciotlosm]

Do you know a HA version when it worked? Might help track the diff in changes.

[brownad]

A long time ago.. either way to make it appear correct I manually changed the homebridge homeassistant locally to have AUTO instead of Off. But problem lies within the homeassistant side I think.

Sent from my iPhone

On 6 Jan 2018, at 13:14, Marius notifications@github.com wrote:

Do you know a HA version when it worked? Might help track the diff in changes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ciotlosm]

The screenshot abobe shows a selected “operation_mode” different from anything in “operation_list”

[brownad]

Ah ok, either way operation_list isn’t populated. And by default the plugin reads status of Off regardless of the true state.

Sent from my iPhone

On 6 Jan 2018, at 13:33, Marius notifications@github.com wrote:

The screenshot abobe shows a selected “operation_mode” different from anything in “operation_list”

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[MartinHjelmare]

Please provide your configuration. It's not clear which region you are using. There are two different regions with different thermostat implementations and underlying libraries.

[brownad]

The default EU region

Sent from my iPhone

On 6 Jan 2018, at 13:33, Marius notifications@github.com wrote:

The screenshot abobe shows a selected “operation_mode” different from anything in “operation_list”

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ciotlosm]

The display problem seems to be because home-assistant/homeassistant/components/climate/honeywell.py doesn't implement:

    @property
    def operation_list(self):
        """Return the list of available operation modes."""
        return None

Because this comes from __init__.py it will always be empty. I don't own such a device, but I guess someone has to either find a way to get the list from the device and redefine that method inside honeywell.py.

It seems there is code in there that might hold the above list:

            self.client.system_mode = device[
                'thermostat']['changeableValues']['mode']

The US version also has a problem (looking at current_operation):

    @property
    def current_operation(self: ClimateDevice) -> str:
        """Return current operation ie. heat, cool, idle."""
        oper = getattr(self._device, ATTR_CURRENT_OPERATION, None)
        if oper == "off":
            oper = "idle"
        return oper

The idle / off should have been handled inside a state otherwise the operation mode dropdown would be broken if operation_list does not contain idle.

[brownad]

I’d have to look through the history but I’m pretty sure I used to see Auto or Heat in the past within homebridge

Sent from my iPhone

On 6 Jan 2018, at 16:10, Marius notifications@github.com wrote:

The display problem seems to be because home-assistant/homeassistant/components/climate/honeywell.py doesn't implement:

@property
def operation_list(self):
    """Return the list of available operation modes."""
    return None

Because this comes from init.py it will always be empty. I don't own such a device, but I guess someone has to either find a way to get the list from the device and redefine that method inside honeywell.py or allow config to define a static list of supported operation modes.

The US version also has a problem (looking at current_operation):

@property
def current_operation(self: ClimateDevice) -> str:
    """Return current operation ie. heat, cool, idle."""
    oper = getattr(self._device, ATTR_CURRENT_OPERATION, None)
    if oper == "off":
        oper = "idle"
    return oper

The idle / off should have been handled inside a state otherwise the operation mode dropdown would be broken if operation_list does not contain idle.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[brownad]

It used to work when Evohome was a component in its own right then it was merged into a common component if I remember correctly

Sent from my iPhone

On 6 Jan 2018, at 16:10, Marius notifications@github.com wrote:

The display problem seems to be because home-assistant/homeassistant/components/climate/honeywell.py doesn't implement:

@property
def operation_list(self):
    """Return the list of available operation modes."""
    return None

Because this comes from init.py it will always be empty. I don't own such a device, but I guess someone has to either find a way to get the list from the device and redefine that method inside honeywell.py or allow config to define a static list of supported operation modes.

The US version also has a problem (looking at current_operation):

@property
def current_operation(self: ClimateDevice) -> str:
    """Return current operation ie. heat, cool, idle."""
    oper = getattr(self._device, ATTR_CURRENT_OPERATION, None)
    if oper == "off":
        oper = "idle"
    return oper

The idle / off should have been handled inside a state otherwise the operation mode dropdown would be broken if operation_list does not contain idle.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ABeumer525]

My setup has never shown operation mode. Had the Honeywell setup in November 17.

[brownad]

I’ve dropped the need for home assistant with Evohome, the homebridge-evohome plugin has received some great updates recently and is much better now. Does everything you’d hope for and works

Sent from my iPhone

On 21 Jan 2018, at 14:42, ABeumer525 notifications@github.com wrote:

My setup has never shown operation mode. Had the Honeywell setup in November 17.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RickDB]

EU region and operation mode not working either, anyone working on a fix or are we lacking additional info?

[brownad]

Use the homebridge-evohome plugin - it works.. and has a lot better support

Sent from my iPhone

On 22 Jan 2018, at 21:00, Rick164 notifications@github.com wrote:

EU region and operation mode not working either, anyone working on a fix or are we lacking additional info?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RickDB]

But that's homekit only and would rather have proper HA integration, seems like some coding changes are in order and we are good to go as the rest of the functions do work. Will take a look this weekend but my Python experience isn't that great, have 2 Evohome locations to debug this with at least.

If a developer needs access to one to get this going just let me know.

[dws199]

Has there been any progress on resolving this issue? I'm seeing the same issue with the latest version of Hass.io (0.64.3).

Thanks

[pcdewolff]

Like dws199, same here.

[dws199]

@RickDB @MartinHjelmare Sorry to pester but are there any plans to fix this issue? It would be great to have it working properly

Thanks

Dave

[MartinHjelmare]

Sorry, not from my side. I don't own the device so I can't test code changes.

[dws199]

@MartinHjelmare If there is anything that I can do to help test then please let me know

@dansarginson I noticed that you made some changes that affect the state of the Honeywell devices so perhaps you can assist with this issue?

Thanks

[zxdavb]

Has anyone had a look at this - I am afraid it is beyond my skills to even implement it on my system.

https://community.home-assistant.io/t/honeywell-evohome-thermostat-work-started-need-advice/43740

FYI, the gist is to be found here:

https://gist.github.com/namadori/3f3a15bbbae4f8783394993c148cb555

[dansarginson]

Hi all, the timing here is unfortunate as I've had to move for work and haven't been able to set up my system. I can't test anything. I'll look at this in a couple of months if nobody else gets there first, but please don't count on me in the short term.

On Thu, 29 Mar 2018, 21:22 zxdavb, notifications@github.com wrote:

Has anyone had a look at this - I am afraid it is beyond my skills to even implement it on my system.

https://community.home-assistant.io/t/honeywell-evohome-thermostat-work-started-need-advice/43740

FYI, the gist is to be found here:

https://gist.github.com/namadori/3f3a15bbbae4f8783394993c148cb555

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/11433#issuecomment-377360565, or mute the thread https://github.com/notifications/unsubscribe-auth/ABG9MgT_OuwCy_zOfWtSMmcqtei8Iqisks5tjUKGgaJpZM4RR01S .

[ABeumer525]

Same here. And I'm not even afraid I know I'm not capable of fixing this. The lack of operation mode is very big for me. So if in anyway someone needs help figuring out how to fix this. Let me know.

[zxdavb]

I am working on a fix. My code only deals with EU systems (sorry US).

Note that the zones (referred to as a thermostat, above) have three modes: "FollowSchedule", "TemporaryOverride", "PermanentOverride". It's the controller has the 'Away' mode, as well as 'Auto', 'AutoWithEco', 'DayOff', 'Custom' and 'HeatingOff'.

TBH, honeywell.py is a bit of a mess and I think that it may be best to separate the EU (using 'evohomeclient==0.2.5') and US (using 'somecomfort==0.5.0') evohome systems into separate components as they have distinct schemas.

Anyway, one relevant piece of code is the last line:

def setup_platform(hass, config, add_devices, discovery_info=None):
    from evohomeclient2 import EvohomeClient

    ec_api = EvohomeClient(username, password)
    ec_tmp = ec_api.full_installation()  ## using: ec_api.installation() causes problems

    locationInfo = ec_tmp['locationInfo']
    controlSystem = ec_tmp['gateways'][0]['temperatureControlSystems'][0]

    evo_devices = []
# Add the (parent) controller (device)
    evo_devices.append( evoController(ec_api, controlSystem, locationInfo) )

# Add each (child) zone as a (climate component) device
    for device in controlSystem['zones']:
        if device['zoneType'] == "RadiatorZone":
            evo_devices.append( evoZone(ec_api, device) )

# Create them all in one batch...
    add_devices(evo_devices)

class evoZone(ClimateDevice):

    def __init__(self, client, zone):
        """Initialize the thermostat."""
        self.client = client
        self._id = zone['zoneId']
        self._name = zone['name']
        self._min_temp = zone['heatSetpointCapabilities']['minHeatSetpoint']
        self._max_temp = zone['heatSetpointCapabilities']['maxHeatSetpoint']
        self._operation_list = zone['heatSetpointCapabilities']['allowedSetpointModes']

[dws199]

Hi @zxdavb

Great to hear that you are working on this, how's it going?

[zxdavb]

Broadly, it is OK - a few minor bugs, but the basic functionality is there...

Have a look at the screenshot here https://community.home-assistant.io/t/honeywell-evohome-thermostat-work-started-need-advice/43740/19

And the latest code is here: https://gist.github.com/zxdavb/3556bc7f59847d70f695e855f11721ff

[edit: screenshot added here)

[dws199]

That looks great! How could I install this code, can I update using pip?

[zxdavb]

Install it as a custom component. There are two ways to do this - either override the existing component by calling it honeywell.py, or creating an additional component, by calling it (say) evohome.py.

Instructions how to do the latter are in the first few lines of the GIST/code.

[dws199]

Sorry I missed that note in the code, I've installed it and it seems to work well.

Is there a way to tell if the boiler is on or off, i.e. if any of the TRVs are calling for heat?

Many thanks

[zxdavb]

Can I ask:

• do you have an EU evohome system (the code won't work with a US system).
• do you have zones other than radiator TRV-based zones (currently, the code assumes only these), for example a DWH heater?

I'd be interested in someone testing DHW at some stage...

[dws199]

Yes I have an EU system, I'm in the UK.

I have TRV zones and a DWH controller, but I don't use the DWH temp sensor as I wasn't able to fit it to my hot water tank

[dws199]

@zxdavb I'd be interested to hear how you are getting on with this? Also I thought it was worth mentioning that I had been using Domoticz with their Honeywell plugin which I believe is based off of the source for the HASS version and it seemed to work quite well. The source is here https://github.com/gordonb3/domoticz-evohomeclient and I thought you might find it useful, even though it has been rewritten in C++

[zxdavb]

Well, I've moved the code to https://github.com/zxdavb/evohome

I use the custom_component at home (to automatically switch to AutoWithEco mode if everyone is >2h away, and Away mode if everyone is >12h away) - works for me!

It is under active development, but slowly! I would love people to use it & provide feedback, but it is definitely beta code (having said that, it is not throwing any exceptions).

There is no reason why you couldn't use it (it uses v2 of the evhohome-client api) and the honeywell (which uses v1) component at the same time.

There is some stuff going on in the background! https://github.com/home-assistant/architecture/issues/22

Thanks for the tip - I will have a look at https://github.com/gordonb3/domoticz-evohomeclient

[zxdavb]

Is there a way to tell if the boiler is on or off, i.e. if any of the TRVs are calling for heat?

Sorry @dws199, I sped-read & missed this question. The underlying api, evohome-client does not access this information from the honeywell servers, and - from what I understand - the honeywell api does not provide this information.

Then again, I know that there are things the honeywell api can do, that the evohome-client api does not utilize...

To clarify your question, the controller uses a algorithm called TPI to decide when to call for heat (unless it is using OpenTherm). The TRVs will be open if their current_temp is lower than their target_temp (which is not the same as their setpoint temp).

[dws199]

@zxdavb Thanks for this info, I have now updated the custom component with your latest version and it does seem to work very well. However I think there is one syntax error in line 202 where there is a missing # before the comment "a private function...".

Regarding the question about the boiler state, I suppose I could probably write a template sensor to check each of the TRVs to see if their current_temp is lower than their target_temp, if any of them are then this would imply that the controller will call for heat? Although I guess it might not be that accurate it would allow me to see roughly how often my boiler is running

[zxdavb]

Well done! A change I made to the code and uploaded before testing :( Check the repository often, I will be making changes all the time!

The Honeywell servers are polled via the evohome-client api, but I know there is a way to receive push notifications - would require extensive change to evohome-client (or I could write my own?) - I plan to chase this as the information you see can be 5-10 mins out of date otherwise.

[boy-wonder]

I switched to the evohome.py file as a custom component and only my evohome controller shows up. There are no sensors showing including its inbuilt one. I have three other radiator valves that don't show. Have I missed the point here? I'm in UK with latest evohome hardware.

[zxdavb]

@boy-wonder OK, I just commited the latest version with cleaned up logging. With the logger: option in configuration.yaml, the latest version of evohome.py will expose useful information via: cat home-assistant.log | grep climate.evohome

You can also try: cat home-assistant.log | grep ERR

From the first command, you should see something like:

2018-04-28 22:31:41 INFO (MainThread) [homeassistant.loader] Loaded climate.evohome from custom_components.climate.evohome
2018-04-28 22:31:41 INFO (MainThread) [homeassistant.components.climate] Setting up climate.evohome
2018-04-28 22:31:41 INFO (SyncWorker_5) [custom_components.climate.evohome] Started: setup_platform(evohome), unit: °C
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Controller: id: 2738909, type: EvoTouch, name: My Home
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432521, type: RadiatorZone, name: Main Room
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432576, type: RadiatorZone, name: Front Room
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432577, type: RadiatorZone, name: Kitchen
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432578, type: RadiatorZone, name: Bedroom
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432579, type: RadiatorZone, name: Beans Room
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3432580, type: RadiatorZone, name: Noos Room
2018-04-28 22:31:43 INFO (SyncWorker_5) [custom_components.climate.evohome] Found Zone: id: 3449703, type: RadiatorZone, name: Bathroom

[zxdavb]

BTW @boy-wonder, Sensors won't 'show up', only the Controller and it's Zones. The Controller's thermometer may be configured as 'the' thermometer for a Zone, or it may not be used at all.

If so, that Zone will have a current_temperature according to the Controller's (a.k.a. ATC928) thermometer, rather than for the thermometer of one of the TRVs (e.g. a HR92), or a round thermostat (i.e. T87RF).

To be clear, Controllers (unlike Zones) do not have a current_temperature (and thus, are not actually climate devices according to HA criteria).

[boy-wonder]

Thanks for your speedy response.

My log looks the same as yours other than my zones are of type ZoneValves as opposed to RadiatorZone like yours. I am using HR92s, but I used the controller to configure the "heating" part of the zone to use the zone switch (BDR91) which switches on the boiler. Plumbing-wise there is only one "zone". It's strange that it appears as a ZoneValve really as that is only a small part of the chain.

The controller's temp doesn't show even though it is configured as the temp sensor for the room it is in.

[zxdavb]

The problem is of my making - I don't have access to the api documentation (if anyone can help with that?). I had a line of code (because I have chosen not to support DHW until someone can test for me): if zone['zoneType'] == "RadiatorZone":

That is now: if zone['zoneType'] in [ "RadiatorZone", "ZoneValve" ]:

You can now download the new version. Thanks for your patience.

And again, the Controller will not have a temperature. The only time it will have a temperature is when it reports the external weather (either via an external weather sensor, or from the cloud), but I understand this is not exposed via the public Honeywell api.

Your Controller provides the temp to the zone, which hopefully you will be able to see shortly.

[boy-wonder]

The type is ZoneValves (plural). I did a find and replace in your code and it now works great. Functionality is good in initial testing. I understand the difference between sensors and zones now. I see all the zones I was expecting.

Thanks for your efforts. It is a good replacement for the existing component already I would say. What plans do you have for functional improvement, if any?

[zxdavb]

Actually, I've now taken out that if statement altogether (a mistake to have it in, I think) - a small update will be forthcoming.

The main focus now is converting from a climate (custom) component to a bespoke (custom) component. Architecturally, the Controller doesn't fit as a climate-type device (you now see what I mean by saying it doesn't have a current_temperature). Then I'd like to replicate the UI/UX of the Honeywell Controller.

In the meantime, you now have access to all the operating modes!

Future plans might include something like websockets rather than polling, but this would require significant changes to the underlying evohomeclient python library. https://github.com/watchforstock/evohome-client/tree/master/evohomeclient2

If you have any suggestions, let me know.

[zxdavb]

Code updated - a quick and nasty hack to increase current_temperature precision from .5 to 0.1 by utilizing Honeywell's older (v1) api (actually the reported temps are in hundredths, but HA can only handle tenths).

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[zxdavb]

For those who'll be interested, there is a custom_component in development that is planned to replace the EU-based Honeywell climate component, hopefully well before next winter.

https://github.com/zxdavb/evohome

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[boy-wonder]

It all works for me using recent versions of HA. No customisation required.

[zxdavb]

@boy-wonder The EU half of the honeywell climate component has been superseded by the built-in evohome integration. Thus, it should be removed, and I would advise people to use evohome instead.

https://www.home-assistant.io/components/evohome/

I would be interested to know if the evohome component doesn't work fro EU-based people.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.