[Feature Request] Per-lock slot numbers for users

オープン
  • 何か問題がありますか？
#1,739 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
backend

調査の方向性

Start by tracing slot storage and lookup in model/config.py, model/queries.py, config_flow.py, and init.py, then review the existing migration path and the per-lock worker in sync/worker.py. The issue describes changes across configuration, allocation, lookups, events, cards, diagnostics, and automations, so map those surfaces before estimating the work. Done means users hold a slot per lock, existing configurations migrate without lock-side changes, and the listed user-visible surfaces work with per-lock slots.

索引モデルが issue の本文から書いたものです。

説明

enhancement
Problem Description

Each user holds one slot number (CONF_SLOT) that is used on every lock in the configuration. Lock Code Manager picks it when the user is added, as a number free on all of the configuration's locks at that moment. That shared number causes the hardest limits left in the "you don't pick slots" design:

  • Allocation needs a number free on every lock. The more locks in a configuration, and the more unmanaged codes they hold, the fewer numbers qualify.
  • Adding a lock is refused (existing_codes) when the new lock already holds codes at numbers the configuration's users hold. The numbers were issued before the lock joined, and renumbering a user would mean rewriting their code on every other lock.
  • A smaller lock constrains the configuration (slot_out_of_range): a user on slot 30 can't be added to a 20-slot lock even if it has free slots.
Feature Description

Give each user a slot number per lock instead of one shared number.

The 7.0 engine is already per lock, so most of the stack needs no change:

  • one LockWorker per lock with its own slot table (sync/worker.py);
  • the lock_code_manager.core store is keyed per lock;
  • queries already take a lock: slots_configured_on(hass, lock), configured_owner(hass, lock, slot);
  • tags (lcm:<slot>:), events and attribution are read per lock;
  • Matter already decouples the slot from the device credential index, and Akuvox/Schlage have no indices at all (the slot only lives in the tag).

What would change:

  • Config: a user holds {lock: slot} instead of CONF_SLOT, with a migration that copies today's number onto every lock (no lock-side change on upgrade).
  • Allocation: pick a free slot per lock; adding a lock picks free slots on that lock instead of refusing with existing_codes; slot_out_of_range goes away.
  • Lookups: "user on lock" replaces "slot" as the key in model/config.py, model/queries.py, config_flow.py, __init__.py (CONF_SLOT is read in ~17 places).
  • User-visible surfaces built on "slot N": event entity code_slot attribute and slot-based automations, the lock codes card's per-slot rows, the user card, the duplicate check across entries (slots_already_configured), diagnostics, and the slot section strategy.
Anything else?
  • Risk is mostly in the migration and in automations that assume the same code_slot on every lock; this needs its own upgrade note.
  • A user's slot number could still default to the same number on every lock when one is free everywhere, so most configurations would look unchanged.
  • Out of scope for 7.0.0; a candidate for 7.x.
主要言語
Python
スター
112
フォーク
20
平均マージ
2時間 57分
マージ済み PR（30日）
158

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

raman325/lock_code_manager のほかの issue

raman325/lock_code_manager の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。