Proposal: Support bidirectional close tilt for covers

[raman325]

Background

Both vertical binds and horizontal venetian blinds can tilt in two directions, which means that they have two states that could be considered closed. The tilt functionality in the cover platform does not handle this case and expects close tilt to be a single state.

Proposal

• Add an additional feature for CLOSE_TILT_ALTERNATE which allows for a secondary tilt (blind slats can close in two directions)
• Consider adding an optional direction attribute with an enum that's either UP_AND_DOWN or LEFT_AND_RIGHT. This can be used by the frontend to decide how to display the close_tilt and close_tilt_alternate service
• add a close_tilt_alternate service or update the close_tilt service to accept an optional parameter that specifies direction somehow

In #908 before this proposal was split out, @starkillerOG suggested alternate names for the new feature - I don't have a strong opinion on what the name should be. What I was thinking is that we preserve the existing features and services to handle closing in one direction, and add a new feature and service to handle the second direction, but I am open to alternate suggestions on that too.

[bdraco]

When we considering changing the entity model we need to know which integrations would benefit from the change since we want to avoid making architecture changes for one-off cases.

There are probably a lot of cases that could apply to https://www.home-assistant.io/integrations/hunterdouglas_powerview/ but I don't have any of these devices so I'm not the best person to give input here.

[ZephireNZ]

This issue has come up as part of implementing Close Up/Down in SwitchBot Blind Tilt: home-assistant/core#96539

My initial approach was to simply allow user to configure the default close direction for the integration per device, but bdraco (rightly) pointed out that it should ideally be a UI feature and change to service calls.

Based on your own proposal, and discussions with bdraco, my proposal would be:

• Add a feature flag CLOSE_TILT_MULTIDIRECTIONAL
• Add an entity attribute directions that lists possible close directions. This mirrors the way eg fan works to support arbitrary preset modes.
• Add an optional parameter direction to service cover.close_cover_tilt so user can specify up/down/left/right/etc from above. Default behaviour when direction is not provided would be integration specific (as it currently is).
• In the UI, if the above feature flag is set then show buttons for each close mode (eg Close Up, Close Down, etc) based on the attribute options. This again mirrors the way that fan works in the UI for preset modes. We can mirror the way alarm works with the tile card and give user ability to show/hide buttons if needed.

[ZephireNZ]

When we considering changing the entity model we need to know which integrations would benefit from the change

I did a review of integrations implementing close_cover_tilt and how its library handles the close command.

Integrations that would benefit from multidirectional close:

• esphome - currently hardcodes 0% as closed, 100% as open but ESPHome itself does not define what is open/closed
• hunterdouglas_powerview - library currently hardcodes tilt of 0% for closed and 50% for open
• mqtt - MQTT currently defines only one closed position based on config
• soma - SomaConnect supports flag close_upwards but this is not currently used in library
• switchbot - library supports close up/down but it is unused
• template - would enable simpler custom venetian/vertical blinds with multidirectional close without custom scripts
• velux - library currently hardcodes tilt of 50% as open and 100% as close
• zwave_js - was recently changed to use a close/open "target" from Zwave, could be expanded to support multiple close targets

Integrations that don't appear to support multidirectional close:

• acmeda - not true tilt, uses same API as close_cover
• bond - calls library API to close with no direction
• deconz - device does close tilt one-directional (0 open to 100 closed)
• dynalite - calls library API to close with no direction
• fibaro - device does close tilt one-directional (100 open to 0 closed)
• homematic - device does close tilt one-directional (1.0 open to 0.0 closed)
• homematicip_cloud - device does close tilt one-directional (0.0 open to 1.0 closed)
• knx - device does close tilt one-directional (0 open to 100 closed)
• motion_blinds - library limits tilt rotation to 0-180 degrees, not sure if this is a device limitation or library
• overkiz - calls library API to close with no direction
• rfxtrx - not true tilt, uses same API as close_cover
• tasmota - calls library API to close with no direction

[starkillerOG]

Motionblinds tilt 0 is closed on one direction, 180 is closed the other direction and 90 degrees the slats are horizontal so open.

Bidirection would therefore benefit Motion Blinds.

[vexofp]

I can second that this would be useful for ZWave. I have a bunch of iBlinds window blinds motors to which this would apply.

Specifically, these and similar devices expose the "Horizontal Slats Angle" property of ZWave's Window Covering command class. This property includes the notion of two "closed" states, one at either end with "open" being halfway in between (SlatsStates.CLOSED_1 and .CLOSED_2 in zwave-js-server-python). The ZWave integration currently maps Home Assistant's notion of closed to one of the two states, hard-coded arbitrarily.

I think it would be great to expand Home Assistant's notion of closing to encompass such double-ended devices. The design proposal above seem like they would cover such devices well! 👍

[Lonestar10]

Has any of this been implemented in ZWave? I cannot use iBlinds properly because the state appears as "unknown."

[vexofp]

iBlinds state showing as unknown is actually due to #908 , and not in particular anything to do with being bidirectional. They only report "tilt" and not "position", and currently Home Assistant's cover entity state is based solely on position.

I tried to jump-start discussion of some different potential solutions over in that other thread, but never got much traction. 🤷 I also prototyped some of the different proposed solutions in some branches (1C, 2A). Personally, I have been running the 1C option at home for a few months now and generally happy with it.

[BradleyFord]

Smartwings blinds via Zigbee2MQTT are fixed in terms of 0 to 100. But what is zero depends on if your blind rolls over the front or back of the roller.

…

On Sat, Jul 15, 2023, 18:39 Brynley McDonald ***@***.***> wrote: When we considering changing the entity model we need to know which integrations would benefit from the change I did a review of integrations implementing close_cover_tilt and how its library handles the close command. Integrations that would benefit from multidirectional close: - *esphome* <https://www.home-assistant.io/integrations/esphome> - currently hardcodes <https://github.com/home-assistant/core/blob/62c5194bc8928eb8591ad07b61a28f4d0c05b0e1/homeassistant/components/esphome/cover.py#L119-L125> 0% as closed, 100% as open but ESPHome itself does not define what is open/closed - *hunterdouglas_powerview* <https://www.home-assistant.io/integrations/hunterdouglas_powerview> - library currently hardcodes <https://github.com/sander76/aio-powerview-api/blob/8dceb352c864a24236782638544f0e9865af8421/aiopvapi/resources/shade.py#L128> tilt of 0% for closed and 50% for open - *mqtt* <https://www.home-assistant.io/integrations/mqtt> - MQTT currently defines only one closed position based on config <https://github.com/home-assistant/core/blob/62c5194bc8928eb8591ad07b61a28f4d0c05b0e1/homeassistant/components/mqtt/cover.py#L615> - *soma* <https://www.home-assistant.io/integrations/soma> - SomaConnect supports flag close_upwards <https://support.somasmarthome.com/hc/en-us/articles/360026064234-HTTP-API#:~:text=morning_mode%20%3D%200/1-,close_upwards,-specifies%20the%20closing> but this is not currently used in library - *switchbot* <https://www.home-assistant.io/integrations/switchbot> - library supports close up/down <https://github.com/Danielhiversen/pySwitchbot/blob/2db1006e5f8be8212737b3c8eb4cff22eabc5a0b/switchbot/devices/blind_tilt.py#L55-L63> but it is unused - *template* <https://www.home-assistant.io/integrations/template> - would enable simpler custom venetian/vertical blinds with multidirectional close without custom scripts - *velux* <https://www.home-assistant.io/integrations/velux> - library currently hardcodes <https://github.com/Julius2342/pyvlx/blob/2649f1c7ed221971a662bb272fbf653136571d23/pyvlx/opening_device.py#L177> tilt of 50% as open and 100% as close - *zwave_js* <https://www.home-assistant.io/integrations/zwave_js> - was recently changed to use a close/open "target" <https://github.com/home-assistant/core/blob/62c5194bc8928eb8591ad07b61a28f4d0c05b0e1/homeassistant/components/zwave_js/cover.py#L239> from Zwave, could be expanded to support multiple close targets Integrations that don't appear to support multidirectional close: - *acmeda* <https://www.home-assistant.io/integrations/acmeda> - not true tilt, uses same API as close_cover - *bond* <https://www.home-assistant.io/integrations/bond> - calls library API to close with no direction - *deconz* <https://www.home-assistant.io/integrations/deconz> - device does close tilt one-directional (0 open to 100 closed) - *dynalite* <https://www.home-assistant.io/integrations/dynalite> - calls library API to close with no direction - *fibaro* <https://www.home-assistant.io/integrations/fibaro> - device does close tilt one-directional (100 open to 0 closed) - *homematic* <https://www.home-assistant.io/integrations/homematic> - device does close tilt one-directional (1.0 open to 0.0 closed) - *homematicip_cloud* <https://www.home-assistant.io/integrations/homematicip_cloud> - device does close tilt one-directional (0.0 open to 1.0 closed) - *knx* <https://www.home-assistant.io/integrations/knx> - device does close tilt one-directional (0 open to 100 closed) - *motion_blinds* <https://www.home-assistant.io/integrations/motion_blinds> - library limits tilt rotation to 0-180 degrees, not sure if this is a device limitation or library - *overkiz* <https://www.home-assistant.io/integrations/overkiz> - calls library API to close with no direction - *rfxtrx* <https://www.home-assistant.io/integrations/rfxtrx> - not true tilt, uses same API as close_cover - *tasmota* <https://www.home-assistant.io/integrations/tasmota> - calls library API to close with no direction — Reply to this email directly, view it on GitHub <#912 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOZ77JRYNZHYGHTJYI7U3XQJ6PZANCNFSM6AAAAAAYTIO6XI> . You are receiving this because you are subscribed to this thread.Message ID: <home-assistant/architecture/repo-discussions/912/comments/6455659@ github.com>