Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[ISSUE] Turning a slot on takes over a homeowner's code at its index without warning

Chiusa
  • Qualcosa non va?
#1,697 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Start with the slot-adoption logic that writes to an untagged user at a credential index, as introduced in #1518 and changed by #1696, and the core store's wrote hash from M5a. Check how the Matter and Z-Wave User Credential paths decide adoption when a slot is turned on. Done means turning on a slot whose index holds an untagged user raises a repair and leaves the user and PIN untouched, while LCM's own tagged codes still adopt normally.

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

Descrizione

bug
What happened?

Found while reviewing #1696, the feature/clean-room-core fix for #1695. This isn't new: it has existed since adoption was introduced around #1518.

On locks with user records (Matter, Z-Wave User Credential CC), writing a slot adopts any untagged lock user that holds a PIN at the slot's credential index. LCM renames that user with its lcm:<slot>: tag and overwrites the PIN. This is how LCM takes over its own codes from before it tagged them, but it can't tell those apart from a homeowner's code.

After #1696, a homeowner's code at a turned-off slot's index is correctly left alone: the slot reads off and in sync. But when that slot is turned back on, LCM adopts the homeowner's user, renames it, and replaces their PIN. Nothing warns first.

The options flow and allocation (#1693, #1696) already refuse to offer such an index to a new slot. Turning on a slot that's already configured skips that check.

Expected: LCM adopts an untagged user only when there's evidence it's LCM's own:

  • the core store remembers LCM writing that slot on this lock (M5a's salted wrote hash), or
  • on Z-Wave, user_id == slot with a matching pre-tag write record.

Otherwise the slot is held with a repair along the lines of "someone else's code is at this slot's index on ; remove it or move this user to another slot". No overwrite.

Steps to reproduce the issue
  1. A configuration has slot 3 on a Matter lock, with its user turned off.
  2. The homeowner adds their own user with a PIN at credential index 3, through HA's Matter fabric or the vendor app.
  3. LCM reads slot 3 as off and in sync (correct after #1696).
  4. Turn slot 3's user back on.
  5. LCM renames the homeowner's user to lcm:3:… and overwrites their PIN.
Home Assistant Version

dev (test harness)

What version of Lock Code Manager are you running?

feature/clean-room-core with #1696

Lock make and model

Matter; Z-Wave locks with User Credential CC

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ej3snRj69NSu2qB2b9td9J

Lingua principale
Python
Stelle
112
Fork
20
Merge medio
2h 53m
PR unite (30g)
140

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.