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

[ISSUE] A homeowner's user named with a slot number is treated as Lock Code Manager's

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

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

Research direction

Start with parse_tag, which reads a bare-number user name as Lock Code Manager's slot tag, then read the change from #1722 that limits this for the Z-Wave JS release. The same guard is still missing on the Z-Wave JS set path, where slot 3 can adopt a homeowner's user named 3, and in the Matter release, which also falls back to a bare number when the firmware rejects the name's characters. Done means a bare-number user is adopted or deleted only when LCM would have written that exact name on that lock, with tests for both cases.

Written by the indexing model from the issue text.

Description

bug
What happened?

Found while reviewing #1722.

Background: parse_tag reads a user named just a number, e.g. 3, as Lock Code Manager's tag for slot 3. LCM really does write that bare form when the lock's name limit can't fit lcm:<slot>:. A homeowner can also name their own user 3 in the vendor app, and LCM can't tell the two apart.

#1722 fixed this for Z-Wave JS release: a bare-number name only counts as LCM's when lcm:<slot>: doesn't fit. Two other places still have the gap:

  • Z-Wave JS set path: writing slot 3 can adopt a homeowner's user named 3. LCM renames it to lcm:3:… and writes its PIN onto it. A later release then deletes that user, along with any other codes the homeowner put on it.
  • Matter release: the same digit gap. The length check from #1722 isn't enough here, because Matter also falls back to a bare N when the lock's firmware rejects the name's characters, not only when the name is too long.

Expected: LCM only treats a bare-number user as its own when it would have written that name itself on that lock. It never adopts or deletes a homeowner's user because the user's name happens to be a slot number.

Steps to reproduce the issue
  1. On a Z-Wave User Credential lock whose name limit fits lcm:3:, create user 7 named 3 in the vendor app, with PIN 5555.
  2. Configure LCM slot 3 and turn it on.
  3. LCM adopts user 7, renames it, and replaces PIN 5555.
Home Assistant Version

dev (found in code review)

What version of Lock Code Manager are you running?

feature/clean-room-core

Lock make and model

Z-Wave User Credential CC locks; Matter

🤖 Generated with Claude Code

https://claude.ai/code/session_0147zKneN1dB51wr1z5orrDQ

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.