climate entity incorrectly reports integration as implicitly supporting turn_on/off without setting the proper ClimateEntityFeature

[make-all]

The problem

My integration explicitly supports turn_on and turn_off methods, and also sets the ClimateEntityFeature.TURN_ON and TURN_OFF flags in its supported_features. However users are constantly reporting that HA is outputting a log message saying

Entity None (<class 'custom_components.tuya_local.climate.TuyaLocalClimate'>) implements HVACMode(s): off, heat_cool, cool, dry, fan_only, heat and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at https://github.com/make-all/tuya-local/issues

This is due to a missing condition on line 398 of climate/init.py, where it merely checks that the modes contain HVAC_OFF to output this message, without checking that the ClimateEntityFeature flag is set as the previous lines do, or whether the turn_off/turn_on methods are overridden by the integration, so the implicit fallback will actually be used.

What version of Home Assistant Core has the issue?

2024.3.3

What was the last working version of Home Assistant Core?

2024.1.6

What type of installation are you running?

Home Assistant OS

Integration causing the issue

climate

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.climate
Source: components/climate/init.py:361
integration: Climate (documentation, issues)
First occurred: 10:46:18 (1 occurrences)
Last logged: 10:46:18

Entity None (<class 'custom_components.tuya_local.climate.TuyaLocalClimate'>) implements HVACMode(s): off, heat_cool, cool, dry, fan_only, heat and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at https://github.com/make-all/tuya-local/issues

Additional information

No response

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (climate) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of climate can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign climate Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

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

[make-all]

Although I have found what is apparently the official way to work around the issue, the issue of the log messages being incorrect still exists in Home Assistant as a bug, and will be affecting other integrations as well.

[PeteRager]

Can you make a pull request to fix?

[TheJulianJES]

Setting _enable_turn_on_off_backwards_compatibility = False after you migrated should prevent the fallback and error messages no matter what.

[make-all]

That is the workaround that I installed in my integration, but it still does not fix the bug, which is that the wrong message is being logged under the wrong conditions.

[TheJulianJES]

Yes, the error message seems to log incorrectly. Just wanted to mention that you should still set the value to False.

[make-all]

After my proposed change, setting the "opt-out" variable is only necessary for integrations that do not want turn_on/off services implemented for some reason, even though they support HVAC_MODE_OFF and other modes.

Integrations that already set the support flags should not be required to set extra opt-out variables to work around an incorrect log message (which is the only effect of setting that variable). Adding that requirement just creates additional busywork for custom integration authors who often have very little time to keep up with such changes.

[gjohansson-ST]

I am going to close this issue as it states explicitly in the blog post that integrations should set _enable_turn_on_off_backwards_compatibility to False once migrated regardless.

[make-all]

Disappointing that defending your past mistake is more important to this project than quality of the information you are logging.