Lutron shades open/close operating sub-optimally

[cbw]

The problem

My environment is a Homeworks QSX system with a mix of Palladium and Sivoia QS shades. Behavior is observed on HA Core 2023.8.2 (but is not new).

I believe there's a mismatch in behavior of how HA handles "open" and "close" commands on Lutron shades. While it does result in the expected outcome of the shades opening or closing, it has some odd side effects:

• when the shade starts moving, it nudges, pauses, then continues motion (versus the expected smooth motion)
• when the shade completes the open/close operation, if it appears on a keypad button, the LED for that button remains lit (indicating the shade is still in operation)
• presses to that button don't behave as they should – for example, if you opened the shade in HA, the first button press on the keypad has no action, then pressing it again will close (assuming an open/stop/close/stop mode for that button)

This behavior is not exhibited if you explicitly set a shade level (such as 0 to close, or 100 to open).

One approach I experimented with was changing the async_close_cover and async_open_cover functions to set explicit shade levels versus calling _smartbridge.lower_cover() and _smartbridge.raise_cover() however this has the negative side effect of the "stop" button in the HA UI not functioning. We could remove the CoverEntityFeature.STOP to fix that, but that seems sub-optimal as well.

Experimenting with the Lutron app, they don't seem to have the concept of "latching" the open/close like HA does – the buttons on the shade control view allow you to open, nudge up, go to favorite, nudge down, and close. If you hold nudge up or nudge down, it exhibits the same "nudge, pause, continue" as async_close_cover/async_open_cover do, however when you release the nudge up/nudge down buttons, the shade stops (i.e., they don't expose a "stop" button, they stop motion whenever you release the nudge button.

My hypothesis is that we're leaving shades in this weird state because we're essentially holding the "nudge" button indefinitely without sending a "stop" command. Maybe we should hold some state and when the ReadResponse subscription update comes for the shade zone that it's finished opening or closing, send a stop command?

This still doesn't solve the jog/pause/continue issue, but at least it doesn't leave keypads in an invalid state. Unfortunately with the Cover entity not exposing different controls to the user for jog vs. full open/close, options may be limited without changing that.

What version of Home Assistant Core has the issue?

core-2023.8.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

lutron_caseta

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @swails, @bdraco, @danaues, mind taking a look at this issue as it has been labeled with an integration (lutron_caseta) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `lutron_caseta` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign lutron_caseta` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

lutron_caseta documentation lutron_caseta source _{^{(message by IssueLinks)}}

[bdraco]

Looks like https://github.com/home-assistant/core/issues/78971

I don't have any of the affected devices so I can't help beyond code review for this one.

[cbw]

Yeah, reading through that issue, seems to be the same behavior (I've just also noticed the keypad issue, which is something likely unique to QSX or RA3). @danaues do you have shades on your RA3 system?

I don't mind coding up a solution, I'd just like to get concurrence from the maintainers on direction since it could approach in a behavior change for shades.

[bdraco]

The solution offered in that issue is probably fine if the case where the shade moves in the wrong direction from the time between the commands being sent can be overcome

[cbw]

Sounds good, I'll put together a PR this weekend.

[peterxrock]

I have the same issue, if any testing is needed. My shades wouldn't move at all after a while, so I have them set up via Designer instead of HA.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.