Add speed attribute to cover integration #789
Replies: 14 comments 15 replies
-
|
I think this make sense. Can you summarize a list of integrations/motors that could make use of this type of addition? |
Beta Was this translation helpful? Give feedback.
-
|
Hi elupus, I think of the official integrations that a lot of people use, it would potentially be:
for maker solutions it would be of course also possible, if the suitable hardware is available:
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). There could be more if you count integrations that are not used by many people or custom integrations. |
Beta Was this translation helpful? Give feedback.
-
|
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 Device option doesn't exist yet, but it can also be a solution for this silent mode. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for initiating the discussion! What's needed for this to move forward? |
Beta Was this translation helpful? Give feedback.
-
|
I'm only wondering here if we should limit to a specific set of speeds, why not similar to |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Since this discussion has gotten a little quiet, I wanted to ask about the current status. Thanks in advance! :) |
Beta Was this translation helpful? Give feedback.
-
|
Is there any progress on this? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Throwing myself into the hat for switchbot curtain 3 speed control. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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_positionandcover.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:
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:
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_SPEEDflag 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.
Beta Was this translation helpful? Give feedback.
All reactions