-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate fan speeds into percentages and presets modes #45407
Conversation
I've only had a cursory look through so far but I like what I see. I am a big fan of the gradual transition approach. What is the breaking change at this stage? |
Custom integration will have to update their Note that |
Ah ok - that's not too onerous I don't think. |
Looks like coverage is needed for backcompat https://github.com/home-assistant/core/pull/45407/checks?check_run_id=1746793288 |
It might be better to make a '@fan_speed_compat' and '@fan_percentage_compat' decorator instead. Might need 4 of them though for async vs sync so not sure how much it saves but at least it's more dry |
Will pick this back up tomorrow, but it's at least ready to get feedback |
I'm hoping to clean this up a bit to use a Will probably rework the shared comment to something like
|
Managed to get this to 100% diff hit 👍 |
Do we need to limit the mqtt fan platform allowed speed values to make it compatible and have some valid speeds? |
I think we should remove the ability for I opened a separate PR for this since we should document the breaking change in the release notes for MQTT in case someone is actively using this #45445 I'm not sure anyone actually does this in production (well except that one guy who does) since it looks like it was only added in #33584 to ensure there was full coverage since the code supported passing it. |
It looks like zha has a fan speed of
|
apparently SPEED_ON means very high |
I've done all the manual testing I can think to do with this and ran though the code line by line again. |
Did another run though. Can't find anything else that needs to be adjusted. |
I've converted 14 out of the 26 fans in core in separate PRs. I was able to make all 14 of them conform to the spec without having to the ability to set some speeds. |
This is looking really good. My +1 doesn't mean much outside of homekit_controller, but you have it. I can't think of a better way we could handle the transition AND cope with the non compliant fans. |
I've got HomeKit updated in #45549 Alexa and Google both support the percentage model and they looks quite strait-forward to update Alexa percentage controller Google supportsFanSpeedPercent https://developers.google.com/assistant/smarthome/traits/fanspeed |
I'll look at this again after the beta cut. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good!
This should not be merged until we cut the beta. |
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Final testing looks good 👍 |
Continuation of @Jc2k 's work in #39204
Architecture issue: home-assistant/architecture#127
WTH: https://community.home-assistant.io/t/wth-homekit-controller-support-for-4-fan-speeds/221305
fan.set_percentage
orfan.set_preset_mode
instead of a speed list. Separate fan speeds into percentages and presets modes frontend#8216Breaking change
For users
The fan entity model has changed to split named speeds into percentages in the range from 0 (off)-100 and preset modes.
Why change?
This change allowed us to expand the number of supported speeds to accommodate additional fan models in Home Assistant. (#45407 (comment))
We had 3 fan speeds and that worked great as long as the fan had no more than 3 speeds
Over time we received a number of requests to add fans with 4, 5, or even more speeds and preset modes. This put us in the difficult position of having to reject this support because the underlying fan model didn’t support it.
Percentages were chosen because they can represent up to 100 speeds which should accommodate all fans. Additionally it’s a lot easier to ask your voice voice assistant to set the fan to 20% then remember that medium-low is actually low-medium or have to learn and remember how to say the speeds for every fan model you want to control.
Moving forward
Calls in automations and scripts to
fan.set_speed
should be replaced:fan.set_percentage
.fan.set_preset_mode
.The following speeds existed in core integration and will now be automatically identified as preset modes:
auto
,smart
,interval
,idle
, andfavorite
Both of the new calls are backwards compatible.
Calls in automations and scripts to
fan.turn_on
that use thespeed
attribute should be switched to use thepercentage
orpreset_mode
attribute once the underly integration has been updated to support it.All core fans have been updated to ensure that calls to the
fan.turn_on
servicemap
percentage
orpreset_mode
tospeed
for backwards compatibility.For developers
The core issues we are solving is:
Custom fan integrations should add the
@fan_compat
decorator toasync_turn_on
orturn_on
function to ensure backwards compatibility:Example:
The function signature for
async_turn_on
is now:async def async_turn_on(self, speed: str = None, percentage: int = None, preset_mode: Optional[str] = None, **kwargs) -> None:
The function signature for
turn_on
is now:def turn_on(self, speed: str = None, percentage: int = None, preset_mode: Optional[str] = None, **kwargs) -> None:
Developers that are creating new integrations should review the updated fan entity model documentation at https://developers.home-assistant.io/docs/core/entity/fan
Proposed change
At its heart this PR adds support for a new method on fans,
async_set_percentage
(and its sync counterpart).The goal is to provide a gradual transition and allow the existing interface to continue working by detecting when
async_set_percentage
andset_percentage
have been overridden and provide a backwards compatible interface.If a device supports
async_set_percentage
then it doesn't need to implementasync_set_speed
- HA provides a mapping function that convertsmedium
into a percentage.If a device does not support
async_set_percentage
then a mapping function will translate calls to that method into reasonableasync_set_speed
calls.The
speed
attribute will always be available - using a mapping function if only a percentage is available.A new
percentage
attribute is added and will also always be available - again using a mapping function where needed - turninglow
into33%
etc.The mapping function is dynamic and tries to accommodates fans that don't follow the spec properly (e.g. they have added extra speeds) using a similar mechanism to the one in
homekit
.The PR ports demo fans to the new API to test it out.
Type of change
Example entry for
configuration.yaml
:# Example configuration.yaml
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: