Add speed attribute to cover integration

[Bascht74]

Context

Currently the cover integration supports many different types of covers and shutters. To control them, there are the specialized services for this, including cover.set_cover_position and cover.open_cover. These can be used to control and position the covers.

In the meantime, more and more manufacturers are starting to offer two speeds for their cover motors. Mostly it is called "silent mode". An example is Somfy (RS 100 io) or also Elero (RolMotion). The sense behind it is that basically all automatic controls are done in "silent mode" (speed doesn't matter, noise does), while manual controls by humans can be done fast (speed does matter).

Two examples:

1. in the evening the covers should close in the whole house and all motors are controlled at the same time. This makes a lot of noise in the house. In Silent mode, this is hardly noticeable - despite all motors being controlled. Same in the morning, which prevents you from waking up due to the noise generated by all covers.
2. a person wants to open the cover to the terrace. Of course, this should be done quickly and is therefore carried out at the fast speed.

Especially in apartment buildings with multiple households, the possibility of activating silent mode in the morning and evening is very useful, as this means that all people living there are not disturbed by the noise of the covers of their neighbors. In Germany, for example, DIN 4109 was created especially for this purpose (also includes sound insulation for electrically operated shutters).

Current state in Home Assistant:
The current cover integration allows in principle the control of the devices, but not the choice of the desired speed.

Proposal

Extension of the cover integration by the possibility to select the speed (slow/fast) for all services (e.g. open, close, set_cover_position).
(So far I have only seen these two speeds in practice, more levels don't really make sense either. The choice to make here is: silent oder fast, not to balance those two out like with fans)

Example for a service call:

    - service: cover.set_cover_position
      target:
        entity_id: cover.demo
      data:
        position: 50
        speed: slow/fast

If the "speed" attribute is not specified, the default speed is used. If speed is specified and the device integration does not support different speeds, the attribute is ignored.

If a SUPPORT_SLOW_SPEED flag is added as well it should do nothing to existing integrations that doesn't support different speeds.

Consequences

Until now, integrations have to find their own way for speed selection. E.g. the official overkiz integration did exactly that:
https://github.com/home-assistant/core/blob/58883feaf69f5204c73812283fc7509ce5cb3c0c/homeassistant/components/overkiz/cover_entities/vertical_cover.py#L168).

By including the speed in the cover integration, a uniform standard for it would exist and the standard HA services would be usable.
Furthermore, including a speed attribute in the cover integration itself would create the possibility that other projects can include this either.

So far, I have often observed that HA has jumped on topics concerning important issues such as energy.
This proposal is, in effect, about noise abatement. Therefore, I hope that the proposal is really considered, as noise control is an important factor in people's quality of life :-)

P.S.:
There is a older entry about it (#602), but it was never really discussed to the end. As more and more producers are jumping in that train, and integrations start to implement it outside the cover integration, I think it makes sense to bring it up again and explain the purpose and advantages it a bit further.

[elupus]

I think this make sense. Can you summarize a list of integrations/motors that could make use of this type of addition?

[ntindle]

Looks like it's numerous integrations now having issues with this

[Bascht74]

Hi elupus,

I think of the official integrations that a lot of people use, it would potentially be:

• https://www.home-assistant.io/integrations/overkiz -> There are already covers that support two speeds (quiet/fast), and many people use this integratoin (myself included). E.g. the somfy RS 100 io motor supports two speeds. Maybe also motors from other manufacturers supported by overkiz, but I don't know them personally.
• https://www.home-assistant.io/integrations/homematic/ -> There is an option to set the speed of the motors for "automatic drives" and "manual drives", e.g. here https://www.contronics.de/download/dokumente/erfal-Homematic-IP-Akku-Funk-Antrieb-DE_EN.pdf.

for maker solutions it would be of course also possible, if the suitable hardware is available:

• https://www.home-assistant.io/integrations/cover.command_line/
• https://www.home-assistant.io/integrations/cover.template/

Furthermore there is a potential for newer motors which can be controlled by esphome / Tasmota. The prerequisite would be that Tasmota / ESPHome supports it (a chicken and egg problem).
One can use e.g. https://www.elero.com/en/products/electrical-drives/rolmotion-m
for this. I have currently implemented it with Tasmota itself and added a custom command for it via Berry as I am switching from Somfy to this other brand.

There could be more if you count integrations that are not used by many people or custom integrations.
E.g. Hella offers such a motor as well: https://www.hella.info/de/produkte/onyx-r-silent-motor#Mehr-Komfort and for this there is an integration: https://github.com/muhlba91/onyx-homeassistant-integration

[ntindle]

We can add switchbot curtains to this list now

[lightheaded]

Namely, SwitchBot Curtain 3

[ScottG489]

SwitchBot Blind Tilt would be another device. It has an option in the native app for a "silent" option, which it sounds like would apply here.

[tetienne]

Such new attribute will really ease the Overkiz integration. Many people ask for the silent mode before we implemented it. First using a virtual switch (not allowed) then by duplicating a cover to force this mode and by exposing a specific service.

In addition to cover.set_cover_position, I will suggest also to add this attribute to cover.open and cover.close.

Device option doesn't exist yet, but it can also be a solution for this silent mode.

[quenthal]

This would also help enormously Switchbot Curtain 3 integration. With Curtain 3 (and for some extent, Curtain 2) support slower, but quieter opening/closing of curtain. This is already implemented in the backbone, but they need to be exposed as desribed here for the cover -methods as attributes.

[lightheaded]

Thanks for initiating the discussion! What's needed for this to move forward?

[gjohansson-ST]

I'm only wondering here if we should limit to a specific set of speeds, why not similar to preset maybe have some default ones but the implementation can expand/set what they need?

[otsoni]

I was thinking the same thing. But should it be some kind of limited set of enums or something or should there be possibility for numeral value also?

[gjohansson-ST]

Don't see a reason to include numerical speeds so I think this proposal should limit itself to list[str].
More or less a copy of preset. I'll update my comment above to outline the proposal more extensively.

[sandervandenberg]

If a device manufacturer decided to implement a completely variable speed setting, you'd need to change the code again. Would love to see a numerical value (0-255?) and in addition to that a limited set of enums which just translate to that numerical value.
Then in the implementation for a specific device one can specify if it supports a numerical value, or enum values (and which), or both.

[codyc1515]

The same is true of Zigbee motor covers. These includes devices such as Aqara Roller Shade Driver and Aqara Curtain Driver. However, I would suggest that this functionality should be a little more open ended as Aqara devices, and likely others, support low / medium / high speeds.

Many climate entities also have something similar like "Boost" / "Eco" modes aka. "Fast" / "Slow" fan modes so it would be good to retain flexibility in that regard.

[snoack]

Is there any plan to allow configuring a default speed either per device or globally? After all this is not like a fan that sometimes you want to run on high and sometimes on low, but usually if people prefer to open their curtains (or whatever cover) slowly/quietly or rather fast they prefer to do so all the time.

[sandervandenberg]

Not all the time... I'd like to open my curtains very slowly, like a wake-up-light, before I get up in the morning. But I'd like it to close faster when the sun starts shining into the window to keep temperature down. Or to open it quickly when I want to open the window behind it.

[DennisOtto-dev]

Since this discussion has gotten a little quiet, I wanted to ask about the current status.
Are there any plans to add a speed configuration to the cover entity?
What is currently needed for development to continue?
Is there already an approximate implementation date so that we can benefit from it?

Thanks in advance! :)

[sanderlv]

Is there any progress on this?