Fan entity speed settings
cdce8p opened this issue · 9 comments
This issue was triggerd by home-assistant/core#14351 which was / is adding HomeKit support for fan entites.
During the work on the PR @schmittx and I noticed that the current way we assign fan speeds
is overly complicated and not really practical for things like HomeKit, Alexa or Google Home.
Current state
Each fan platform creates a list of supported speed settings, the speed_list
, and setting the speed
value requires to pass a string
that exists in the list.
The most popular entries to speed_list
are:
STATE_OFF
orSPEED_OFF
SPEED_LOW
SPEED_MEDIUM
(sometimes)SPEED_HIGH
Others include: auto
and smart
The dyson
platform taking a special case with: 0001
, 0002
, ... , 0010
and AUTO
Problem
Secondary platforms expect a) consistent values and b) most often percent instead of a string. In addition (c) the speed setting is mixed up with the current operation mode.
Solution?
- The
speed
attribute should change to anint
value between[0, 100]
. The conversion should be handled by each platform individually. auto
,smart
,off
, (maybemanual
) should get their own attribute:mode
/operation_mode
?
Their might be things that I've missed, especially how to cover this change in the fronted, but since the current way is somewhat all over the place we decided (at least for the homekit component) not to support the speed setting (for now).
I definitely agree that some improvement needs to be made for fan speed
, it's too inconsistent
currently.
My concern with using an int
value between [0,100]
for speed
is that it's not clear how many discrete speed
options there are for the entity.
An alternative approach might be:
speed_list
would contain only discretespeed
values likeSPEED_LOW
,SPEED_MEDIUM
,SPEED_HIGH
,0001
,0002
, etc.SPEED_OFF
would be deprecated to prevent confusion,state
should be used to showSTATE_ON
andSTATE_OFF
- A new attribute,
mode
oroperation_mode
(likeclimate
), would be added to indicateauto
,smart
,manual
, etc. - A section would be added to the dev pages to explain the
attributes
and expected values for eachdomain
With the above approach; secondary platforms, like HomeKit, that use percentage-based speed can read the length of speed_list
to determine the correct interval step between [0,100]
. This would allow for a more intuitive interface for users when using secondary platforms (ex. Home app with HomeKit). Secondary platforms can also read operation_mode
to set an appropriate mode characteristic.
Finally, this approach may be less of an overhaul from the current architecture and therefore easier to implement than changing speed
to an int
value between [0,100]
.
We should definitely specify the speed constants that are allowed to be used. Dyson would need to map their 0001 etc to one of our values.
I was thinking about this issue again. What if we use an approach similar to the light brightness
parameter, by defining an additional speed_pct
?
Some advantages:
- Full backwards compatibility
- We don't need to limit ourself to just 4 predefined mode => better support for dyson
- Each component can implement the conversion itself. It might make sense to move the most dominate one to a
util
class though.
I would imaging that a future roadmap could look something like this:
- New
fan
platforms must supportspeed_pct
- Change frontend (use slider instead of dropdown)
- Deprecation and later removal of
speed
andspeed_list
To better illustrate my idea, I will post a link to a WIP
PR shortly.
Update
Link to the PR: home-assistant/core#15030
I rather have a hard cut off, not sure why we wait to make the breaking change if we are going to make a breaking change?
- Change frontend (use slider instead of dropdown)
Even if many fans use percents to define speed internally, many of them are "step-based", meaning that 1->20% = speed 1, 21->40% = speed 2, etc.
So I dont think that using a slider in all cases is a good idea.
any news on this?
Can anyone point to a place where the discussion is ongoing?
Is there at solution for this? Since the closing :-)
@sknsean Unfortunately, I don't have time to implement any of it. And besides the issue has probably been stale for far too long. Maybe someone else will pick up this topic in the future.
Any discussion about this topic somewhere?
Homekit allows to slide up and down the ON/OFF button. It seems that on Apple's side it's do-able.
That would free us from using the AC remote control at all.