Feature: suppress_stop_at_limits

[marcpbailey]

Problem:

When cover_time_based hits its internal calculated limits (0% or 100%), its auto_stop_if_necessary()
function unconditionally fires the cover.stop_cover service down to the underlying cover_entity_id.

For momentary switch/template setups where the end positions are hardware limited, this can result in the stop command firing unnecessarily. This can cause the physical hardware to either jolt, reverse, or get out of sequence since the hardware intrinsically stops itself at physical limits.

Proposed Solution:

Introduce a boolean configuration parameter suppress_stop_at_limits (default false to maintain backwards compatibility). When true, and only applicable when cover_entity_id is defined, the stop command is suppressed only when the cover reaches the 0 or 100 boundaries, allowing natural time-based stops at any arbitrary intermediate percentage (e.g. 50%).

[clintongormley]

hiya

This issue is resolved in PR #51 (which is a big rewrite) through two complementary mechanisms:

1. External movement detection

When movement is triggered externally (physical buttons, wall switch, app), the integration sets _self_initiated_movement = False. When auto_stop_if_necessary() fires, it detects this and skips the relay stop entirely — it just syncs the internal position tracker without sending any command to the hardware.

2. Endpoint run-on time

For HA-initiated movements to endpoints (0% or 100%), the integration no longer fires an immediate stop when the calculated position is reached. Instead:

1. The position tracker stops immediately (internal bookkeeping)
2. The motor keeps running for endpoint_runon_time seconds (default 2.0s), giving it time to physically reach the hardware limit
3. The motor hits its physical limit and stops itself naturally
4. Only after the delay expires does the stop command fire — at which point the motor is already physically stopped, so it's a no-op

The stop after the run-on delay is effectively a state-sync mechanism, not a motor control action.

Summary

Scenario	Main branch	feat/ui-sync-rewrite
External trigger → endpoint	Sends stop (problematic)	No stop sent — just syncs tracker
HA-initiated → endpoint	Immediate stop (problematic)	Delayed stop after run-on — motor already at physical limit
HA-initiated → mid-position	Immediate stop (correct)	Immediate stop (correct)

The combination eliminates the unnecessary stop commands that were causing jolts, reversals, or sequencing issues on hardware-limited setups.

[marcpbailey]

Hey there - thanks Clinton. I was actually having trouble figuring out whether to do a PR on the HACS released version or the main branch because of that massive PR #51. It will wait and see if it does the same thing as my trivial and discrete modification. I also noticed issue #14 but that seemed to get a bit murky; my fix is/was more surgical.
Patience, I must have. I won't bother with the PR now until you publish and I'll merge (if needed at all any more) and test.
Thank you for all the massive contributions. It's a super useful little mod; it's a shame there are so many forks! People seem to fork rather than go to the effort of PR.

[clintongormley]

It's a super useful little mod; it's a shame there are so many forks! People seem to fork rather than go to the effort of PR.

Yeah exactly, I didn't want to create another one. But I got a bit OCD about Fixing All The Bugs! 😆

[Sese-Schneider]

This is now available in v4.0.0-beta.1.
Please report any issues!
Thanks, @clintongormley