Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[ISSUE] A homeowner's Matter code at a turned-off slot's index suspends the slot

Open
  • Is something wrong?
#1,695 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@raman325 is already working on this.

Since Oct 15, 2026.

  • #1702 by @raman325 — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start from the core code that maps a credential index to a slot's occupancy, and from the clear path that removes only LCM-tagged users and returns False. The slot_suspended repair is raised after 3 failed clears. Reproduce with the fake Matter lock: create an untagged user at index 3 with slot 3 turned off, then check that the slot reads in sync. Done means the off slot reads clear, the untagged code is reported as foreign, and set-path adoption still works. This depends on the unmerged #1694, so confirm its status first.

Written by the indexing model from the issue text.

Description

bug
What happened?

Found while reviewing #1694 (the feature/clean-room-core fix for #1518). It only happens once #1694 is in.

On a Matter lock, a homeowner's own untagged user ("Mom") may hold a PIN at the credential index matching an LCM slot that is turned off. #1694 makes sure LCM's clear never deletes Mom's code. That part works.

The slot itself gets stuck, though:

  • The read maps Mom's credential to the slot by its credential index, so the slot reads as occupied by its own code.
  • The clear only removes LCM-tagged users, so it finds nothing to remove and returns False.
  • After 3 tries the slot is suspended with a slot_suspended repair saying "a code may remain". That repair can never be resolved, and it calls Mom's code the slot's own.

Expected: an untagged user at a slot's credential index counts as someone else's code on the lock, not as the slot's own. The turned-off slot reads clear (in sync), and Mom's code is reported separately, like any other code LCM doesn't manage.

Constraint: we can't just stop mapping untagged users by index. Set-path adoption needs that mapping: a pre-tag LCM user is adopted and tagged on the next write. So this needs a new kind of reading, e.g. "occupied by an untagged user at this index", that the core treats as foreign when the slot is off and as adoptable when it is on.

Steps to reproduce the issue
  1. On a Matter lock, create user "Mom" with a PIN at credential index 3 through HA's own Matter fabric. Mom is untagged.
  2. Configure LCM slot 3 on that lock, with its user turned off.
  3. Let sync run.
  4. Mom's code stays on the lock, as it should. But slot 3 never reads in sync, and after 3 clear attempts it is suspended with an unresolvable slot_suspended repair.
Home Assistant Version

dev (test harness)

What version of Lock Code Manager are you running?

feature/clean-room-core with #1694

Lock make and model

Matter (reproduced with the fake Matter lock)

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ej3snRj69NSu2qB2b9td9J

Dominant language
Python
Stars
108
Forks
18
Avg merge
2h 7m
Merged PRs (30d)
130

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raman325/lock_code_manager

All issues in raman325/lock_code_manager

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.