Fan entity speed settings about architecture

[cdce8p]

@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.

[schmittx]

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 discrete speed values like SPEED_LOW, SPEED_MEDIUM, SPEED_HIGH, 0001, 0002, etc.
• SPEED_OFF would be deprecated to prevent confusion, state should be used to show STATE_ON and STATE_OFF
• A new attribute,mode or operation_mode (like climate), would be added to indicate auto, smart, manual, etc.
• A section would be added to the dev pages to explain the attributes and expected values for each domain

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].

[balloob]

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.

[cdce8p]

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:

1. New fan platforms must support speed_pct
2. Change frontend (use slider instead of dropdown)
3. Deprecation and later removal of speed and speed_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

[balloob]

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?

[itineric]

2. 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.

[sknsean]

any news on this?
Can anyone point to a place where the discussion is ongoing?

[sknsean]

Is there at solution for this? Since the closing :-)

[mime29]

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.