docs(keymaster): swap step order so keymaster entry is removed before LCM takes the lock Previous order had LCM configured while keymaster's entry was still active for the same lock -- both integrations run drift detection and periodic sync, so they would fight each other for that window. Frame the migration as per-lock: delete the keymaster entry first, then add an LCM entry for that lock. Users with several keymaster-managed locks can migrate one at a time and leave keymaster installed for the rest. Promote the "remove keymaster entry" step before "install LCM" and "add LCM entry"; reframe the up-front warning around the conflict window rather than just the leftover-PIN gotcha. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

raman325 committed May 11, 2026

docs: add migrating-from-keymaster page Walks through the practical steps to move from keymaster to LCM: the PIN cleanup situation (keymaster does not call clear_usercode on slot or entry removal), feature mapping (notifications/access-count/date-range/day-of-week limits map to LCM blueprints and condition entities), a 10-step migration procedure, conversion recipes for each keymaster restriction type, provider parity, and what doesn't translate (the auto-generated Lovelace dashboard, autolock entity model, entity naming). Wired into the Getting Started section in both the sidebar and the home page. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

raman325 committed May 11, 2026