Closing of cover at sun set recognized as manual override

[isi07]

Hello,
can you help me to understand what is causing ACP to recognize my covers in status "manual override", when ACP is driving the covers down in the evening at sunset.
I am using new version 2026.8.1 and don't think I have observed such behavior with prior version - but not 100% sure.
Is anything wrong with my configuration or can I improve to avoid this behavior?

ACP is recognizing the manual override even through there was no manual override from any user.
The cover closed as commanded by ACP.

When I click the small but to stop the manual override, ACP just changes the display and cover does not move, because it is where it should be.

Thank you very much
Christian

config_entry-adaptive_cover_pro-01KQ87NGRR77ECY13WMT29KBJW.json

[jrhubott]

Christian, I looked at the diagnostics you attached, and the timeline on the 10th shows exactly what's happening. ACP sends the close command at sunset, when the climate handler hands off to the default/sunset handler. Five seconds later the command-grace window expires, but your cover's position sensor still reports 100, it hasn't started moving yet. The override check runs right then: target 0 against a reported 100, delta 100%, well past the 3% threshold, so it gets flagged as manual override. The cover doesn't actually start moving until a couple of seconds after that, roughly 6-7 seconds after the original command went out, past the 5-second grace window.

It's a timing mismatch. COMMAND_GRACE_PERIOD_SECONDS is hardcoded at 5.0 and isn't user-configurable, and your motor apparently needs more than that to start responding. It shows up at sunset specifically because that handoff is the day's biggest position swing; the small intraday tracking nudges are quick enough to land inside the 5-second window and never trip this.

This isn't new in 2026.8.1. grace_period.py and the override classifier haven't changed since v2026.7.0, so you're probably just noticing it now rather than hitting an actual regression.

Don't bother raising transit_timeout to fix it. Yours is already at 20s, but that setting only kicks in once the cover is confirmed in transit, and this override fires before the cover is ever observed moving. It never gets consulted.

Clearing the override doing nothing visible is expected too, not a second bug. The cover's already sitting exactly where ACP wanted it, so there's nothing left to move.

Yeah, this is a bug. I've added your reproduction to #1139 (#1139) and broadened its scope to cover this. The fix will be to ignore a position delta when the reported position hasn't actually changed since the command was sent.

Until that lands, turn on "Only engage manual override from Adaptive Cover Pro commands" under Automation → Manual Override. It makes ACP ignore external state changes entirely, so a stale reading can't trip a false override. The catch: your own manual adjustments won't register either unless you drive the cover through ACP, via the Proxy Cover Entity or the companion Lovelace card. And with that option on, use the adaptive_cover_pro.stop service instead of cover.stop_cover.

For details, see the Troubleshooting wiki page.

[isi07]

Hi Jason,
thanks a lot for your reply and your incredible work for this integration.
My covers are of type Homematic IP and I use the integration homematicip.ocal
https://github.com/SukramJ/homematicip_local

This integration is applying command throtteling, when many commands shall go at same time over the RF interface.
Which is the case in my installation. At the end of the day all my covers on ground floor are commanded at the same time by ACP to close.
I believe the throtteling in the homematic integration is then causing some covers at the end of the queue to overrun the ACP grace period of 5 seconds.
I am now trying to reduce the throttel time in the homematic integration.
Maybe this can improve the situation already.
And then I wait for the fix for #1139
Many Thanks
Christian