Add support for fan preset modes

[finity69x2]

Describe the problem you have/What new integration you would like

add a configuration option to allow the use of defined preset modes for fans that support them.

Please describe your use case for this integration and alternatives you've tried:

adding preset modes to ESP based fans would allow more flexibility than just supporting percentage speeds.

Additional context

[nagyrobi]

I think this is deprecated from HA side... originally they supported speeds as presets, but it was changed to percentage.

[scotty1395]

From what I understand, speed_list: is deprecated but preset_modes: isn't? ESPHome populates speed_list: off, low, medium, high but leaves preset_modes: null.

[voed]

Any progress on this?

[millerm1993]

I'm also interested in this!

[ChristianNewton]

I'm also interested in this!

Me aswell, I would love if this could get some more attention!

[Robbe-B]

Same, is there already any alternative in the mean time ?

[mill1000]

I think this is deprecated from HA side... originally they supported speeds as presets, but it was changed to percentage.

Here's what the HA dev docs say about fan entities and preset modes. https://developers.home-assistant.io/docs/core/entity/fan#preset-modes

I may take a swing at this if I find enough time.

[mill1000]

I've taken some steps to start implementing this.

• How does everyone plan to use this function?
• What fan components are you using? (e.g. speed fan, h-bridge, etc)

[nagyrobi]

I use speed and binary fan. For the speed ones, I use percentage 0-100 so there are practically 100 speed levels to choose from...

[ChristianNewton]

I've taken some steps to start implementing this.

• How does everyone plan to use this function?
• What fan components are you using? (e.g. speed fan, h-bridge, etc)

Hey, thanks for helping work on this! I'm using the Tuya fan component. It works very well, I just wish that there would be an easier way to control it other than 0-100, since it is only 4 speeds.

[mill1000]

Hey, thanks for helping work on this! I'm using the Tuya fan component. It works very well, I just wish that there would be an easier way to control it other than 0-100, since it is only 4 speeds.

Does setting speed_count not achieve that already?

[flyize]

I've taken some steps to start implementing this.

• How does everyone plan to use this function?
• What fan components are you using? (e.g. speed fan, h-bridge, etc)

Would this allow me to go back to using low, medium, and high - even though I have a 4 speed fan? That's really what I'm hoping for. Using percentages only is unnecessarily confusing to anyone else in my house. Everyone understands low, medium, and high.

[mill1000]

Yes, although that is considered to be an improper use of the function and is better handled via other means (in Home Assistant).

[flyize]

While I totally get that I can work my way around this developer-imposed HA limitation, it seems insane. People intuitively understand low, medium, and high (especially for voice assistants!). For more advanced use-cases, use the percentages.

So in short, thank you for possibly bringing this back!

[filmkorn]

I use a speed fan component in an esphome replacement of the broken brains of a smart air purifier - see https://github.com/filmkorn/air_purifier

How does everyone plan to use this function?

I'd like to reimplement the preset modes provided by the original integretion (VeSync):

• auto: based on the current air pollution)
• sleep: basically lowest speed setting)
• manual: Which the VeSync integration no longer explicitly supports, but it switches to manual mode when you select one of the three speeds of the air purifier. Unsure where this automation is implemented but I'm thinking this could be done through esphome automations.

All I want is to have this component to support preset modes as enum on the same entity so I don't have to navigate through 'related' entities to find the mode I have currently implemented as separate entity (select component in esphome).

What fan components are you using? (e.g. speed fan, h-bridge, etc)

speed fan like this

output:
  - platform: esp8266_pwm
    pin: D1
    frequency: 1000 Hz
    id: pwm_output

fan:
  - platform: speed
    output: pwm_output
    name: "Air Purifier"
    id: air_purifier   
    speed_count: 10

[mill1000]

FYI this feature was released in ESPHome 2023.12.5, and HomeAssistant just added support in 2024.1.0

[flyize]

@mill1000 I'm a little confused. Where do I define these presets? I see in the ESPHome docs where they are referenced, but not where they are defined.

[mill1000]

For a speed_fan or hbridge_fan it would looks something like this

fan:
  - platform: speed
    name: "Test Fan"
    id: test_fan
    # ...snip...
    # Define desired preset modes here
    preset_modes: 
      - Auto
      - Sleep
    # Write automations for preset modes here
    on_preset_set:
      then:
        lambda: |-
          if (id(test_fan).preset_mode == "Auto") {
            // Auto preset enabled
          }
          else if (id(test_fan).preset_mode == "Sleep") {
            // Sleep preset enabled
            // Maybe set the speed to super low here
          }
          else {
            // No preset enabled
          }

~Or if you wanted an auto mode that sets fan speed based on a sensor...~ See comments below.

sensor:
  - platform: adc
    name: Test Sensor
    # ...snip...
    on_value:
      then:
        lambda: |-
          if (id(test_fan).preset_mode == "Auto") {
            // Set fan speed based on sensor value
            auto call = id(test_fan).make_call();
            call.set_speed(x/10);
            call.perform();
          }

[nagyrobi]

Or if you wanted an auto mode that sets fan speed based on a sensor...

This is exactly what I need!

But unfortunately it doesn't work because as soon as you change the speed from the sensor it automatically exits the Auto preset. Actually this preset thing is pretty useless this way... It exits any preset if you change the speed.

Additionally it would be nice to have a way to select a default preset (to use when node boots). Currently it starts wit no preset selected, but if you choose a preset you can't go back to "no preset"...

[mill1000]

Or if you wanted an auto mode that sets fan speed based on a sensor...

This is exactly what I need!

But unfortunately it doesn't work because as soon as you change the speed from the sensor it automatically exits the Auto preset.

You're right, it won't as is. Probably need to revisit.

Actually this preset thing is pretty useless this way... It exits any preset if you change the speed. That is actually desired behavior, if the change comes from a front end (i.e. Home Assistant changes the speed).

Additionally it would be nice to have a way to select a default preset (to use when node boots). Currently it starts wit no preset selected, but if you choose a preset you can't go back to "no preset"...

You could add a "None" preset to the list. (Or maybe even an empty string ""?)

[filmkorn]

But unfortunately it doesn't work because as soon as you change the speed from the sensor it automatically exits the Auto preset.

I can confirm, the preset_mode value is lost when I set the fan speed through fan.turn_on.

I'm wondering if the mode could also be shown on the web UI (more of a nice to have)?

Edit: There seems to be no Action that allows to set the preset mode. I'm thinking fan.turn_on could use a preset_mode configuration parameter?

[mill1000]

It's a hack but you might be able to work around the issue by setting preset mode in the call. e.g.

sensor:
  - platform: adc
    name: Test Sensor
    # ...snip...
    on_value:
      then:
        lambda: |-
          if (id(test_fan).preset_mode == "Auto") {
            // Set fan speed based on sensor value
            auto call = id(test_fan).make_call();
            call.set_preset_mode(id(test_fan).preset_mode); // Copy preset mode into call so it won't get cleared
            call.set_speed(x/10);
            call.perform();
          }

[jesserockz]

https://developers.home-assistant.io/docs/core/entity/fan/?_highlight=fan#preset-modes

Manually setting a speed must disable any set preset mode. If it is possible to set a percentage speed manually without disabling the preset mode, create a switch or service to represent the mode.

A speed should not be set with a preset. Internally the fan component platform for example speed should be controlling the output based on preset if it is set, otherwise based on the manual speed.

[nagyrobi]

The whole concept is wrong. Should not <> Must not.

It's contraproductive to implement such limitations to narrow the possible use cases.

[flyize]

I agree. It's completely illogical, but this is the hill that some internal dev folks seem to want to die on.

[nagyrobi]

NB. not ESPHome devs afaik. I have no problem with HA limitations if they want to go a certain route, but since this is technically a separate project, which is also meant to be compatible with other tools (moreover, could be used standalone), this limitation shouldn't apply so strictly...

[mill1000]

Current implementation aside, what is the use case for allowing the user to change speeds and keep a preset active?

[nagyrobi]

A quick example is above, you have a preset "Auto" where speed itself is set based on some other, automated logic, and you have a preset "Manual" where the speed is set by hand.

There should be an option to disconnect any relation between presets and speeds. Let us have this dealt etirely custom.

[mill1000]

A quick example is above, you have a preset "Auto" where speed itself is set based on some other, automated logic,

Support for this behavior was intended. I don't think jesserockz's comment was meant to invalidate this function.

and you have a preset "Manual" where the speed is set by hand.

Well that is just not having a preset set at all.

[nagyrobi]

No, the problem is that there can't be a manual preset. Can't switch to no preset, once a preset is set. Eg. You can't exit Auto mode...

I need a well differentiable preset, which is clearly visible and checkable against.

It's all over-complicated and over-constrainted.