Add locked state to Cover

[farmio]

Context

Many cover devices can be locked in a defined position so that automations or hardware buttons can't trigger movements.

• awnings and blinds are retracted when a wind sensor detects to much wind
• roller shutters shall not cover an open door
• motorized windows shall be closed when a rain sensor detects rain

Proposal

Adding a property (eg. is_locked) to cover.py to indicate if the cover can be moved currently.

Consequences

The frontend could visualize the locked status so that movement buttons can be deactivated when cover is locked. When the locking condition is over some devices can resume to the last defined condition (eg. a timer triggered 50% when the cover was locked will be considered when it is unlocked) so it may be good to distinguish between actual position and desired position.

[TinusK]

I think this is a very welcomed addition. I wondered why it is not possible to lock a cover in HA. It is very cumbersome to add al sorts of conditions to cover automations in HA. And I also would like to block my cover controls of our sunscreen when it rains or is very windy.

[iMicknl]

This would be a good addition for the new Somfy TaHoma component as well. Currently you would need to have a look at the attributes of the entity; and integrate this in all automations.

(cc @tetienne & @vlebourl)

[da-anda]

while touching the architecture, would it be possible to also add some more attributes to covers? In many/most KNX blind/cover actuators you can configure auto-shading (based on the orbital position of the sun and depending on the room temp - at least mine can do that) or have something like a "ventilation" mode the covers move to once a window/door is opened. It would be nice to have attributes for this kind of thing so that you can more easily see what's going on. Right now it requires a lot of additional binary_sensors in order to see if a cover is locked or in any automation state.

[frenck]

@da-anda Please keep the architecture issues on topic. If you have a feature request for Home Assistant, please use the community forum. Thanks 👍

[da-anda]

@da-anda Please keep the architecture issues on topic. If you have a feature request for Home Assistant, please use the community forum. Thanks 👍

sorry, was not aware that attributes are not part of the architecture discussion. But if I may still add something to this issue, in KNX world not only covers can have lock states but also lights, switches etc, and I assume in other bus system it is not much different. So it might make sense to support lock states in more/all HA entities and not just covers.

[spacegaier]

I like the idea of having such a locked/read-only flag in the Entity model, for those scenarios where the entity is not "unavailable", but an external factor currently prevents interaction. Prime example the wind speed or rain alarm from OP.

If we introduce such a flag into the model, the frontend can react to it and disable the action buttons (e.g. to move a cover or switch something on/off).

Looking at it from a bus system perspective such as KNX it would indeed make sense to even have that in more entities, to accurately reflect the state in HA, if due to a lock a light may not be switched on or off currently.

[marvin-w]

Would it help the decision making process if I provide the needed changes to the core and frontend to support the architectural change in terms of adding support for the cover entity? Maybe this could then even be integrated in the alexa and google home integrations.

[spacegaier]

The alternative to purely handle that in the frontend (e.g. by allowing a cover card to specify a separate binary sensor that indicates the lock state) doesn't feel as robust, since if e.g. an automation is attempting to move a cover during the wind alarm, nothing will happen but the user cannot clearly see why. If it were controlled by the entity, it could add a logbook entry ("Moving not possible due to lock state") and that would help with automation debugging/tracing.