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 or read_only) 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 also distinguish between actual position and desired position (#966).

[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)

[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.

[shbatm]

In addition to the OP's comments, this would also be good for things like:

• Multi-entity devices which need the "master" power turned on before controlling sub-devices, power strip with master relay, sprinkler system with a master valve, etc..
• Entities requiring a safety or other means of disabling, but they are still otherwise "available" (e.g. fireplace control).

[bachya]

I'm a fan of this concept being applied to entities in general.

Another example is RainMachine, which has switches to denote programs/zones (with corresponding services to enable and disable them) – when they are disabled, I could see this new state being the appropriate one (i.e., the switch can't be used directly, but it's still "available" to be enabled). home-assistant/core#59262

[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 to get appropriate feedback when moving a locked cover.

[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.

[henfri]

Hello,

I also think that this feature is very relevant.
@marvin-w has offered to look deeper into it (not sure, whether that offer is still valid three years later ;-)
But would such change be supported by the core-developers? @frenck

Greetings,
Hendrik