keymaster

Summary Add Local Akuvox (`local_akuvox`) as a supported lock provider for keymaster, enabling code slot management and event handling for Akuvox door controllers. ## Changes ### Akuvox provider (`providers/akuvox.py`) - Maps keymaster slots to Akuvox users via `[KM: ]` name tags - Handles webhook events: valid_code_entered, relay triggered/closed, input triggered/closed, invalid_code_entered - CRUD operations for user codes via local_akuvox service calls - Filters cloud-sourced users (source_type '2') from management - Accesses Akuvox coordinator via `hass.data` (not `runtime_data`) ### …

Excerpt saved from GitHub on 2026-10-23.

Akuvox E18C firmware may return `source_type="local"` instead of `"1"` for locally-created users. The previous strict equality check against `"1"` silently skipped all local users on affected devices. ## Changes - Tagged `[KM:XX]` users always pass `_is_local_user()`, if Keymaster created it, Keymaster manages it regardless of `source_type`/`user_type`. - Invert source_type logic: instead of matching known-local (`"1"`), we now exclude known-cloud (`"2"`). Any other value (including `"local"`, `"1"`, or future firmware strings) is treated as local. - Update tests to cover the new tag-bypass …

Excerpt saved from GitHub on 2026-10-23.

Problem The Akuvox provider filters local vs cloud users by checking `source_type == "1"`. This works for A08S and E18C models, but the X916 firmware does not populate `source_type` at all (returns `None` for all users). This causes the provider to skip every user on X916 devices, breaking user code management entirely. Observed symptoms on X916: - `async_get_usercodes()` returns empty list - `async_set_usercode()` always calls `add_user` instead of `modify_user`, causing `FAILED` errors when a user already exists - `async_clear_usercode()` silently does nothing ## Solution Replace the inline …

Excerpt saved from GitHub on 2026-10-23.

Describe the bug # What happens The per-slot control switches (Enabled, Limit by Number of Uses, Use Date Range Limits, Use Day of Week Limits, the per-day and time toggles, etc.) are created with no `entity_category`. By default the HomeKit bridge exposes every switch-domain entity that isn't hidden or categorized, so all of these get added to HomeKit as writable switches. Because they're writable from HomeKit, an Apple Home scene/automation (or a bulk "turn on" action) can flip the limit toggles on active slots. On my locks this turned on the date-range/day-of-week/use-count limits for …

Excerpt saved from GitHub on 2026-10-23.

Are you deadset on the fingerprint requirement? If not, Kwickset 620. Works quite nice, use keymaster integration with HA via HACS.

Excerpt saved from the Arctic Shift Reddit archive on 2026-10-23.

I have our z-wave schlages hooked up to HA and use keymaster to manage codes, auto-lock, etc. I wouldn't have it any other way.

Excerpt saved from the Arctic Shift Reddit archive on 2026-10-23.

HA Core 2026.6 adds zwave-js-server-python 0.71.0, where locks that advertise User Credential CC may no longer expose legacy User Code CC values. Keymaster then cannot find slots and PIN set or clear operations fail with NotFoundError. This keeps backward compatibility with guarded imports and probes each Z-Wave JS node after connect. Locks without the new API, unsupported credential CC, or probe errors continue through the legacy User Code CC helpers. Locks with User Credential CC use user_id = slot number and credential slot 1 for PIN credentials. Behavior matrix: - old HA without …

Excerpt saved from GitHub on 2026-10-23.

Summary This PR adds a ZHA (Zigbee Home Automation) lock provider implementation for Keymaster, enabling PIN code management and real-time keypad lock/unlock event handling for Zigbee locks integrated via native ZHA. ## Proposed change A new `ZHALockProvider` is introduced in `custom_components/keymaster/providers/zha.py` following the `BaseLockProvider` design. - Uses `zha.set_lock_user_code` and `zha.clear_lock_user_code` services for code management. - Implements an optimistic cache (`_usercodes_cache`) for lock codes, since ZHA does not support retrieving PIN codes from locks. - …

Excerpt saved from GitHub on 2026-10-23.

I had the same problem with my Schlage BE469ZP's back on an older version of zwave_js. For me this problem is ended up being caused by an incomplete inclusion when using S0. For whatever reason, my locks just refused to properly transmit the usercodes during the inclusion process. After zwave_js added support for S2, I re-included my locks using S2 and this problem went away entirely. It might be worth excluding/reincluding to verify that S2 security is used instead of the legacy S0

Excerpt saved from GitHub on 2026-10-23.

Describe the bug FE599 locks --> When locking/unlocking via code and/or manual, no notify events are being triggered and sent to mobile device. Works fine for BE649ZP locks Environment (please complete the following information): - Z-Wave integration name: zwaveJS - Lock make and model: FE599 Logs Paste your error logs here. Screenshots none available to show

Excerpt saved from GitHub on 2026-10-23.

Summary Fixes Schlage refresh spam for HomeKit-created resident PINs by treating untagged `HomeKit-*` code names as unmanageable before keymaster assigns virtual slots or attempts add-then-delete tagging. Schlage exposes only code names and PINs, with no provenance metadata, so name matching is the only available mechanism for this provider. ## Proposed change The Schlage provider now keeps a module-level tuple of compiled unmanageable name patterns, starting with a case-insensitive `HomeKit-*` prefix match. Tagged `[KM: ]` codes always remain keymaster-managed, even if their friendly name …

Excerpt saved from GitHub on 2026-10-23.