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.

[Dennis-Otto]

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?

[lachezar-gizdov]

Wandering the same, it's been awhile since any update?

[EDelsman]

I would really like this discussion to come to a conclusion. It's been here almost 2 years. The switchbot PR has been held back because of this. I now have 9 cover entities that would benefit, from Somfy, Switchbot and Aqara. If I read correctly the only thing left to choose is between an int and an enum. I would opt for an approach similar to fan, which allows for both presets and speeds. Consistency is nice, and the implementations can borrow from the example.

[samtate]

This is getting a little silly now, 4 months since the last sensible comment and still no decision, holding back already programmed useful features from devices people have.

[Bascht74]

Hi @bdraco,
as a switchbot user and core developer, could you help us out here how to get to a decision in this case?
This would help some integration developers to implement this feature in a right way an not working around it.

I hope that you don't feel offended because I tagged to you directly.
However, we really need an impulse to continue or to end the whole thing.
So, I hope it might be OK in this case. Thank you in advance for your help & wisdom :-)

[bdraco]

Hi Bascht74,

I don't actually use SwitchBot in production, and I've only been helping out with it because of my involvement with Home Assistant's Bluetooth stack so I'm not the person to advocate for this as I don't have any devices that support a speed.

One thing I would note that is this were to move forward, I'd recommend implementing the speed as 1-100 or a percentage so control can be normalized across devices and users don't have to figure out if one cover calls it slow, one calls it quiet, one calls it gradual, another calls it fast etc.

I also note that there are multiple requests to enumerate which integrations could use this feature but that isn't explained in the opening text or how each integration could use it which is likely not helping to move this forward as anyone who might be interested has to go digging through this to understand how it could be used.

[PhillyGilly]

I would like to be able to pass SPEED to my Velux Blinds. I can't use the HA cover control for Bedroom Blinds because it opens/closes the blinds at DEFAULT which is FAST (and noisy), so I have to run the native Velux controls in parallel to open the blinds in the morning in SILENT MODE. I Can see the the SPEED variable in the py code, but I need the HA cover control to be able to accept the input.

[Landcross]

So, I just bought some motorized curtain drivers and was surprised about it not being able to select the speed from Home Assistant. And then found this thread.

Why is it taking 2 years to come to a conclusion on this? C'mon everyone. We're simply talking about a cover speed here, not some plan to fire a rocket to the moon. Excuse my bluntness, but that's how I view it from someone not really familiar with HA Architecture discussions 😅

From reading the thread above, I quite like the idea from @bdraco on using a percentage and letting specific integrations handle the translation from percentage to whatever it is that device supports. Someone also mentioned the Fan entity. As far as I understand a percentage setting makes it also alligned with the speed percentage in the Fan entity. In fact, like @EDelsman mentioned, can't we just use a similar setup as the Fan entity? With a speed percentage and optional preset modes?

Again, I'm definitly not an expert on this so take my thoughts with a tub of salt, but to me that sounds like the best way forward: configurable and also alligned with the setup of other entities. No need to reinvent the wheel right?

Who do we need to make a final decision on this?

[bdraco]

Who do we need to make a final decision on this?

The proposal should be updated to incorporate the feedback from this discussion and include a summary of the integrations that could benefit from it. After that, a rough prototype implementation should be created to validate whether the proposed approach is viable.

We also need to explore if there is only a speed needed for open/close operations or if any integration allows controlling the tilt speed as well.

[bdraco]

@Bascht74 I think this is a good proposal and once we could likely approve once its updated to include the above.

[wollew]

So, to summarize, the proposal would be to add both speed presets and percentage to open/close/set_position and possibly tilt operations. As in the Fan entity, there would be optional CoverEntityFeature.SET_SPEED for percentages and CoverEntityFeature.PRESET_MODE for presets.

Integrations mentioned so far that could support this feeature are:

• Aqara
• Overkiz / Somfy
• Homematic
• Switchbot
• Velux (which is why I came here, I recently opened add Select platform to support changing cover open/close velocity. core#151594 without knowing about this proposal)
• a few custom integrations
• anything else?

[Gunni]

Throwing myself into the hat for switchbot curtain 3 speed control.