[ISSUE] The operation after a refused write is not paced

Chiusa Adatta ai principianti
#1,642 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, devtools

Direzione di ricerca

L’issue indica BaseLock._execute_locked come punto di ingresso della temporizzazione e dice che i test di regressione sono stati scritti in #1638. Leggi prima quel metodo e i test correlati, poi riproduci una scrittura rifiutata seguita da un’altra operazione. Il lavoro è completato quando ogni operazione inviata al lock aumenta il ritardo di temporizzazione, comprese le scritture rifiutate, e il test di regressione verifica l’intervallo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
What happened?

Lock Code Manager spaces operations on a lock by its minimum operation delay (2 s by default), but it only records the time of an operation when the call succeeds (BaseLock._execute_locked updates _last_operation_time after the call returns). A write the lock refuses is still a round trip to the device, yet the next operation goes out immediately.

Measured with the real 2 s delay and a lock that refuses one set: gaps between operations reaching the lock were 2.0 s, 0.0 s, 2.0 s, 2.0 s. A lock that keeps refusing gets its next command with no spacing each time.

Expected: every operation that reaches the lock, refused or not, counts toward pacing.

Steps to reproduce the issue
  1. Set up a lock with two slots out of sync.
  2. Make the lock refuse the first slot's set (for example a Supervision Fail, or a Zigbee lock rejecting the code).
  3. The second slot's set reaches the lock immediately after the refusal, with no 2 s gap.

Reproduced in the test harness while writing the regression tests in #1638.

Home Assistant Version

2026.9.4

What version of Lock Code Manager are you running?

main after 6.0.1

Lock make and model

Any (provider-independent; in BaseLock).

Anything else?

Related: #405, #532 (pacing), #1638.

Lingua principale
Python
Stelle
114
Fork
20
Merge medio
5h 32m
PR unite (30g)
158

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di raman325/lock_code_manager

Tutte le issue di raman325/lock_code_manager

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.