I’ve been using keymaster with my yale YRD226 for literally years. It’s been 100% solid (although the entity proliferation did always seem odd…) So when it died after HA 2025.08, i decided to just wait it out and see what happened.
I had a little time today, and I decided to fix it. I started by just trying to do the “easy thing”. I’ve only got one lock, it’s got a solid connection to the controller, I only have 7 PINS (so far) and i am not using it for anything fancy. So maybe I could avoid the whole wpie and start again?
Turned on pre-release, upgraded to 1.04b, restarted a couple of times, and went to see what kind of a mess i made.
It worked perfectly first time out of gate. All of my settings moved over, all of my notifications and automations still work, the new lovelace page was a quick cut and paste.
I did turn off the advanced date and day of week options after i verified everything was working. Everything STILL seems to be working. It does look like i need to go delete a bunch of the “not provided” entities that resulted from flipping that switch. I’m just going to let it roll through a few more reboots and days, and next time I have a spare minute I’ll clean that up.
I was ready to do the entire “take off and nuke it from orbit” path that others have had to do, but so far seems like I’ve dodged that bullet. I’ll keep an eye out for wierdness but i thought I would applaud your work to date.
I’m still on HA 7.4, too many breaking chances in HA 8+ for me. Everything works beyond perfect at HA 7.4, but it is good to know that you got HA 8+ working for you.
On the topic of the orphaned entities, when I added the ability to disable them I wasn’t able to find a clean way to clean-up the entities at the same time. So, yes, they are there, but you can easily remove them by going to your entities page and then filtering for Unavailable / Not provided. I would also recommend to add a filter for the Keymaster integration. Once you’ve done that you can enable the bulk select and select all entities and then bulk delete. All the entities that can be removed will be, you’ll still have some there after but those are expected as several of the entities are marked unavailable if certain conditions are not met.
Just did exactly as you suggested. For fun I looked around a little bit before I deleted anything. I had 2283 entities total (wow have I gone a little crazy with the home automation?!?!) of which 503 were “not provided”. Of those, I deleted 273 that were associated with keymaster (mostly the advanced stuff I disabled and don’t use). I did notice a handful of entities that were “automation” types, but not provided.
I happen to have 7 active Pins, and these look like automation for pins 8-10 which would obvs not be provided because I don’t use them.
Is it best practice to delete those too, or will that screw me up when I inevitably use the next few slots?
(in the absence of advice to the contrary, I’m just going to leave them. I’ve learned with HA and Zwave to suppress my OCD urges…)
All of those automations can go away too. If it has keymaster in the name and is not associated with the integration then it’s from your prior installation as every entity is now properly associated with the keymaster integration.
The only ones you will want to keep around would be any automations and or scripts that you created that are for keymaster (such as notify scripts)
If it won’t go away, then the integration is providing it and it’s in an unusable state because of certain logic (for instance, the number of uses counter is not available unless the toggle for it is enabled)
Hmm the issue I’m seeing is the device status on the cards gets stuck… I don’t know if its a real problem or the dashboard not updating or something… I have locks with status like deleting, disconnected, adding, synched. But they seem stuck… I’ve waited at least 2 hours and they won’t change.
And if I look at the Z-wave JS UI logs I see a lot of these constantly. Is it normal for those to be constantly showing or is something else going on? Sorry, don’t know much about how HA works. Just moved from ST
2025-08-31 20:15:48.023 INFO Z-WAVE: [Node 011] Value updated: 99-0-userCode-2 =>
2025-08-31 20:15:49.310 INFO Z-WAVE: [Node 011] Value updated: 99-0-userIdStatus-3 0 => 0
2025-08-31 20:15:51.437 CNTRLR [Node 011] Timed out while waiting for a response from the node (ZW0201)
2025-08-31 20:15:52.752 INFO Z-WAVE: [Node 011] Value updated: 99-0-userIdStatus-3 0 => 0
2025-08-31 20:15:52.753 INFO Z-WAVE: [Node 011] Value updated: 99-0-userCode-3 =>
2025-08-31 20:15:52.840 INFO Z-WAVE: [Node 011] Value updated: 99-0-userIdStatus-3 0 => 0
2025-08-31 20:15:52.841 INFO Z-WAVE: [Node 011] Value updated: 99-0-userCode-3 =>
2025-08-31 20:15:52.930 INFO Z-WAVE: [Node 011] Value updated: 99-0-userIdStatus-1 0 => 0
2025-08-31 20:15:52.930 INFO Z-WAVE: [Node 011] Value updated: 99-0-userCode-1 =>
2025-08-31 20:16:06.100 INFO Z-WAVE: [Node 007] Value updated: 99-0-userIdStatus-1 0 => 0
2025-08-31 20:16:06.637 INFO Z-WAVE: [Node 007] Value updated: 99-0-userIdStatus-3 0 => 0
2025-08-31 20:16:09.028 INFO Z-WAVE: [Node 012] Value updated: 99-0-userIdStatus-1 0 => 0
2025-08-31 20:16:10.389 INFO Z-WAVE: [Node 012] Value updated: 99-0-userIdStatus-1 0 => 0
2025-08-31 20:16:10.389 INFO Z-WAVE: [Node 012] Value updated: 99-0-userCode-1 =>
2025-08-31 20:16:10.560 INFO APP: GET /health/zwave 301 0.302 ms - 162
2025-08-31 20:16:12.316 INFO Z-WAVE: [Node 007] Value updated: 99-0-userIdStatus-3 0 => 0
2025-08-31 20:16:12.317 INFO Z-WAVE: [Node 007] Value updated: 99-0-userCode-3 000000 =>
2025-08-31 20:16:12.904 INFO Z-WAVE: [Node 007] Value updated: 99-0-userIdStatus-1 0 => 0
2025-08-31 20:16:12.904 INFO Z-WAVE: [Node 007] Value updated: 99-0-userCode-1 000000 => 000000
2025-08-31 20:16:14.689 INFO Z-WAVE: [Node 012] Value updated: 99-0-userIdStatus-2 0 => 0
2025-08-31 20:16:17.190 INFO Z-WAVE: [Node 012] Value updated: 99-0-userIdStatus-2 0 => 0
Help with notification on entry of individual user.
I have upgraded to the latest Beta. Rather than updating I deleted the old install and reinstalled making the change of my lock name from Frontdoorz to Frontdoor.
If I turn on Lock Notification (in the top badges) and notification for the user slot set up I DO get a message.
Can someone please remind me how to see the name of that user.
Hi Andrew and all:
Thanks for all of your helpful notes posted here. I have several observations that I noted when migrating my two Schlage BE469ZP locks that were configured as a primary and secondary lock set.
Like everyone else, I discovered that many of the features of Keymaster didn’t work after upgrading to 2025.8.x. I have read through several of the threads dealing with issues with the new code branch…and wanted to relate my experience. I decided to uninstall and do a clean replace of Keymaster. Even though I did delete the integrations via the normal expected method (which did mostly work), indeed I had to take out MANY entities that were left behind abandoned. So I think that most people should expect to review their entities prior to reinstalling …to ensure a truly clean installation.
I basically followed the steps listed by @oblivioncth in his post at ISSUE: "Z-Wave integration not found" in logs since HA 2024.8.0 · Issue #463 · FutureTense/keymaster · GitHub, with the additional steps of garbage collection I described above.
I turned on the switch for the latest beta, and obtained v0.0.1.0-b4
I then proceeded to setup my primary lock with 6 code slots, and with one of the two advanced features turned on (“Enable the advanced date range feature” - i occasionally use this option). I then proceeded to let it settle out. Observations in my environment were as follows:
The “sync status” was generally incorrect at first, or vacillating between “deleting” and “disconnected” in what appeared to have been non-uniform patterns for each code slot.
Rather than wait around… I disabled all code slots… and let them all try to delete and stabilize out to “disconnected.” This worked for some slots, but not others. It appears it did work for slots that had no code previously…but often didn’t for slots that were filled.
I then reset each filled slot with a name and the code I knew was present in that slot… (as others have said, backup your configurations!). Shortly after, the 3 previously filled slots quickly updated to “Synced” and stopped changing.
I then set the other empty slots to something temporary…and they also then updated and settled out to “synced.” Note that it did take some time for all of them to settle out. I did this to ensure that all slots were completely synced up with the new integration…and that no ghost code slots were possible.
Finally, I reverted the slots I didn’t want filled to disabled … and they eventually updated to “Active” = “Off” and “Sync Status” = “Disconnected.” But this took some time to settle out too (i.e. >10 min… and I am running on a Proxmox VM, of latest HA OS fully updated, with a generous amount of resources assigned).
At this point I decided to add the 2nd lock to the mix, which I wanted to be a “child lock.” I followed the normal published directions. The synchronization status took a long time, and I was still not convinced all was well (even though my old codes were working). Some of the slots were not reporting as “Synced” or “Disconnected” in a stable status.
I decided to override each of the 6 slots to be set manually within the child lock…in exactly the same way I had done above….as if it was a stand alone lock.
Once it was stable and validated by testing codes, I then un-checked the “override parent” setting for each slot… and then it updated the child lock to exactly the same status as the parent. This happened fairly quickly…but did take a few minuets to settle out.
My takeaway from this experience is that it is possible that I had any number of several of the described circumstances present (i.e. old settings, cache issues, etc. described on the github threads referenced). However by basically forcing a clean state that included setting all slots configured to something temporarily, and then reverting them to the desired state….I eventually got the system back to a fully synchronized state that appears to be consistently working as expected.
Hopefully my observations might be translatable to others using child locks. Perhaps it could also lead to some initialization steps for child locks given the codebase is being overhauled.
I also have a few lingering questions about feature implementations in the new codebase:
The autolock feature does seem to work after getting it to turn on and off at least once. It was slow to update in the new lovelace card code…but did work after being a little patient.
a. Where can you see the countdown timer for the auto-lock status once it has begun? In the older version there was a display of this countdown on the card. I realized this omission as I needed to try and troubleshoot the next item…
b. On my system, the countdown clearly does not reset when I open the linked door as it used to do in the prior codebase. Is this a known issue, or should I open up a bug report? I would really like to confirm this behavior by observing the timer …and test it carefully….so if anyone can point me at it….that would help a lot!
Test Case: Set timer to 30 minutes for day. Unlock door. Open door and close it. Wait 15 minutes. Open door again and close it. Currently lock will “auto-lock” 30 minutes after the first un-lock event independent of the linked door open/close actions. Previously it would have reset the timer if the linked door sensor indicates that the door opened again. The timer was visible in the lovelace card so you could visibly verify the behavior. The timer would in fact reset repeatedly until the door was closed and un-locked for a full 30 minutes without state change…which is what logically makes it a useful feature to have enabled. Its current state is actually disruptive as it locks on me mid-way through doing some chores in/out of the house.
c. The maximum time the auto-lock will allow to be entered is now 100 minutes. In the older codebase it allowed a user set value of at least 120 min (my previously configured setting). Was there a reason for this new limitation?
Just an FYI
I upgraded my Pi4 to Pi5 with OS 16.2, Core 2025.8.3 and Z-Wave Server 3.2.1 and installed Keymaster v0.1.0-b4.
I have 3 Schlage BE469ZP locks and operating properly with Keymaster beta version.
I have only up to 4 User entries and they are able to sync, delete and disconnect multiple times without any issues. I have not used schedules yet.
Came here looking for the countdown timer too. Assume we’ll see it further along in the beta as it wasn’t an area of focus yet. I’m just happy so far to have a fully working keymaster again.
I would like to implement an automation when a user enter a code to unlock the Schlage connect, Alexa devices will announce a message with the user name and a greeting. I am still on Version v0.0.98. Thank you in advance!
There are a few ways you could do this, but here’s one.
Keymaster makes an event everytime a lock changes state. Find the name of the event, and put it in events under developer tools. Watch the event while you trigger the lock. You’ll see the event data.
You could make the automation trigger on the event, and make a condition for the automation that the event data contains the code you’re looking for. You could put a few conditions under an OR if you want it to continue for a few different codes. Then further down you can use the name from the event data in another template that is your TTS message.
If you go track down that event data and post it back in a code block, I bet someone can help you with some of the templating, if you need it.
I think this is simple but never got an answer last time I asked. I simply want to create a notification when a particular user unsets the lock to gain access. It is my user on slot 2. So I know how to create noticiations, etc, but I cant find what the entity is that changes state. Can someone please advise?
I’m still on 0.1.0b4, but I use “keymaster_lock_state_changed” as a trigger to an automation I use to figure out how the lock was unlocked. That should work…but maybe the latest update changed that?
