evohome integration incorrect value for hvac_mode (current state)

dajomas commented 1 year ago

The problem

In the evohome integration, climate elements always have a status of "heat". The status shouls be off if the radiator is not requesting heat and on if it is.

However, this value seems not to be available from the API so it must be deducted. Unfortunately, the deduction algorithm is comparing the current temperature with the minimum temperature for each climate element. Unless the current temperature drops below the minimum temperature, this will always mean that the status is seat to heat.

This issue can be found in core/homeassistant/components/evohome/climate.py at line 196 where it says: is_off = self.target_temperature <= self.min_temp

this should be changed to: is_off = self.target_temperature <= self.current_temperature

What version of Home Assistant Core has the issue?

2022.10.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Core

Integration causing the issue

Honeywell Total Connect Comfort (Europe)

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 1 year ago

Hey there @zxdavb, mind taking a look at this issue as it has been labeled with an integration (evohome) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `evohome` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant unassign evohome` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

evohome documentation evohome source _{^{(message by IssueLinks)}}

zxdavb commented 1 year ago

Hello, thanks for your submission.

Ever since the change to climate architecture a few years ago, I have agonized about this. It is complicated by the fact that evohome zones:

don't have their own modes, only follow_schedule, or temporary/permanent_override
have a target temp that may not be their scheduled temp (e.g. eco mode)

Indeed, evohome originally behaved much like you describe.

The problem was it wasn't accurate. It would indicate that the zone was calling for heat when it wasn't (according to the evohome controller UI), and that it wasn't when it was.

This was due to delayed start/stop, deadbands, etc. The situation is even worse with the latest controller firmware...

In the end, it was changed (by me) to what you see today and I believe this is the best solution. The whole idea being that less data is better than incorrect data.

see: https://github.com/home-assistant/core/pull/38244

If required, you can obtain the behaviour you want by creating a sensor template

If you want to know when a zone is calling for heat, there is a custom integration called ramses_rf that can do this precisely - you will need an RF dongle:

https://community.home-assistant.io/t/honeywell-ch-dhw-via-rf-evohome-sundial-hometronics-chronotherm/151584

I hope this explanation satisfies.

I will be closing this issue.

home-assistant / core