Repository navigation
Covers: end a timed run at the stop status, not the stop write (#466) #705
Description
Follow-up from the review of #647 (replaced by #702).
Problem
A timed run is anchored at the direction echo and ended at the stop write (cover.py: _auto_stop, _track_write, _freeze_position). The motor runs from the relay switching on until the stop frame reaches the relay, so the booked run can be shorter than the real one.
Measured on a MyHOMEServer1 (15.2 s shutter), 50 % → 51 %:
- UP written at +0.00 s
- direction echo at +0.49 s
- HA's stop written at +0.93 s, 0.4 s after the echo
- booked: 0.4 s (53 % from 50 %)
If the stop takes as long to reach the relay as the direction frame took to produce its echo (~0.5 s), every timed run books about 0.5 s less than the motor ran. On a 15 s cover that is ~3 % per run.
Proposal
When the stop status arrives after our own stop write, end the run there instead of at the write, and re-anchor the position from stop status - start anchor.
Not in #702 because it touches the stop path of every timed cover, not only the floor.
What is missing
- The timestamp of the stop status after HA's stop write, from a debug log, to see how large the gap is. If the stop status follows the write by about the same ~0.5 s, the correction is real; if it arrives almost at once, the current write-time end is fine.
- Gateways that do not relay the stop status must keep the current behaviour (end at the stop write).
Activity
fix(cover): update where guard and issue 302 assertions for stop stat…
fix(cover): achieve 100% test coverage on stop echo handling (#705)
gdluck commentedon Oct 15, 2026
Data point from an F461 (firmware 2.0.11) with an F411/2 shutter (5.1 to 5.9 s end stop to end stop), two runs of the same sequence today, timestamps taken on the client at the socket write:
*2*0*05##follows Home Assistant's stop write by 0.064 to 0.120 s (16 stop writes over the two runs: 0.087 / 0.064 / 0.070 / 0.070 / 0.087 / 0.086 / 0.080 / 0.089 and 0.081 / 0.090 / 0.070 / 0.071 / 0.095 / 0.103 / 0.070 / 0.120);*2*1*05##/*2*2*05##follows the direction write by 0.13 to 0.23 s (34 writes, one 0.71 s outlier when the ACK itself took 0.64 s).So on this gateway family the write-time end is within ~0.1 s of the real stop (about 2 % of a 5 s run), and the ~0.5 s gap measured on the MyHomeServer1 does not apply. If the correction is implemented, the F461 would sit in the "stop status arrives almost at once" branch. The timed capture (
issues_probe.jsonl, writes with write/ACK times and every following event) can be added to the trace corpus if useful.GreenGrassBlueOcean commentedon Oct 15, 2026
@gdluck Thank you very much for capturing and sharing these timing measurements on the F461 + F411/2 plant!
The 64–120 ms stop latency (vs the ~480 ms observed on MyHomeServer1) is a really valuable benchmark for gateway variance across the Legrand family, and confirms that #707's dynamic stop status re-anchoring correctly adapts to fast-echo gateways.
We would love to add your
issues_probe.jsonltrace file to our test fixture corpus (undertests/fixtures/traces/issue_705/) alongside the trace from #714. Could you share or attachissues_probe.jsonlhere (or in a gist / PR)? We'll wire it into the replay test suite.gdluck commentedon Oct 15, 2026
issues_probe_txt.txt
FINDINGS_issues_on_plant_md.md
fix(cover): end timed runs on stop status instead of stop write (#705)
fix(cover): update where guard and issue 302 assertions for stop stat…
fix(cover): achieve 100% test coverage on stop echo handling (#705)
feat(cover): introduce stop latency fallback and measured hardware tr…
fix(cover): end timed runs on stop status instead of stop write (#705)
fix(cover): update where guard and issue 302 assertions for stop stat…
fix(cover): achieve 100% test coverage on stop echo handling (#705)
feat(cover): introduce stop latency fallback and measured hardware tr…
Interstellar0verdrive commentedon Oct 17, 2026
The missing number, from my MyHomeServer1 (timed shutter, the same one as the 15.2 s case): after Home Assistant writes
*2*0*<WHERE>##, the stop status*2*0*<WHERE>##follows the write by 34 to 47 ms (15 stop writes today, median 42 ms), and it is the only status that follows a stop. The integration's debug log and the bus monitor give the same times.So the ~0.5 s I measured is the direction side only: the direction echo
*2*1*<WHERE>##comes 0.48–0.49 s after the direction write, while the stop status is practically immediate. On this gateway too, the write-time end is within ~0.05 s of the status, as @gdluck found on the F461 (64–120 ms). I never measured a ~480 ms stop latency, and I would not use that figure for the MyHomeServer1.Two consequences for #707:
One caveat that applies to both measurements: a stop status 40 ms after the write is most likely the gateway relaying the command, not a confirmation that the relay contacts opened. The bus cannot tell the two apart, which is also why the start side keeps a motor-start delay. If the run really does book short, the missing time is on the start side (relay pick-up after the echo), not on the stop side.
fix(cover): align stop fallback and pin exact provisional assertions (#…
Merge pull request #707 from OpenWebNet-HA/fix/issue-705-timed-cover-…
GreenGrassBlueOcean commentedon Oct 21, 2026
Resolved in PR #707 (
6135ae59) and verified with live hardware traces in PR #753 (0f7ae38d), incorporating the stop-status latency measurements from both F461 (@gdluck) and MyHomeServer1 (@Interstellar0verdrive).