ISSUE: Code slot with advanced Day of Week settings stuck in "Connecting"/"Disconnecting"

[smizles]

Describe the bug
The "PIN Status" for a code slot with advanced Day of Week settings enabled is perpetually stuck in "Connecting" (during available time period) or "Disconnecting" (disabled time periods). This status remains stuck even after toggling the "Enabled" and "Reset Code Slot" switches. I have monitored the debug message logs from the Zwave controller, and I can see standard codes being disabled and enabled when I toggle the "Enabled" switch, but nothing happens after I reset the advanced code slot and simply toggle it to "Enabled" without any advanced settings specified after the reset.

Environment (please complete the following information):

• OS: Home Assistant OS 6.1
• Type of system that HA is running on: RPi 4 8GB
• Home Assistant version: core-2021.6.6 / supervisor-2021.06.8
• Hassio/Docker/Core? I believe this is supposed to be the same as above? (i.e. core-2021.6.6)
• Component version: v0.0.51
• Z-Wave integration name: zwave_js (with Zwavejs2MQTT as supervisor w/ MQTT disabled)
• Lock make and model: Yale YRL256 & Yale YRD256

Logs
The error doesn't appear in the Zwave logs because the enable/disable state does not appear to be communicated. Please let me know if there is a Keymaster-specific log location that might help diagnose this issue.

Screenshots

Additional context
Let me know if there might be any useful info in the underlying Zwave logs. I didn't see anything for the problematic code in question, but the other standard codes appear in the log files. I can scrub the codes out if that is helpful somehow. Please let me know.

[smizles]

EDIT: The screenshots above were taken after toggling the "Reset Code Slot" switch. The same behavior described above was happening when I had Saturday & Sunday disabled and Monday-Friday set to Start = 07:00 and End = 17:00.

[firstof9]

Try upgrading to the latest version and see if the issue persists.

[raman325]

are you using the HA addon for zwavejs2mqtt or your own container?

[djbr22]

I have the same issue, although it's stuck in an "adding" state, even on the latest 0.56 update. Using Z-Wave JS. Parent lock is a Schlage BE469 and child lock is a Kwikset 888.

2/5 (slots 4 and 5) are stuck "adding" on the parent lock. Interestingly, it still syncs new pins to the child lock correctly, and all 5 slots of the child are Connected and accept the newly changed parent lock codes.

I have tried manually changing, deleting, resetting the code slot(gets stuck on deleting) toggling the code on/off, and removing the door from Supervisor, but it doesn't fix the incorrect status So, I guess what I'm saying is, is that I don't think it has to do with it being a Day of the Week field you enabled. For one slot, I tried clearing it through Developer Tools > Services, but receive an "unknown error" for that slot. For the 2nd slot, it doesn't clear the "adding" error but I don't receive that error.

service: zwave_js.clear_lock_usercode data: code_slot: '4' target: entity_id: lock.touchscreen_deadbolt

Edit: Since the functionality of the "adding" or "deleting" status seems to be hit or miss but still adds/deleted/syncs correctly, I just changed the state under Developer Tools > States for the entity 'sensor.connected_frontdoor_4' to Connected. Changing that lock code afterwards stills reverts it to Adding, though. But, since the backend functionality still works, it's not an issue for me since it's only a status message.

[smizles]

I have the same issue, although it's stuck in an "adding" state, even on the latest 0.56 update.

I just started having this issue with a child lock with a code stuck in the "Adding" state:

The original code slot I had problems with was #6, which I toggled reset on then left abandoned. This new problem occurs on code slot #7, which is the slot I used as a replacement for #6. The weird thing is that the code is correctly added and properly functioning on the parent lock, but now the child lock isn't syncing (opposite of my original problem). I only noticed this after upgrading to v0.0.56, but it's possible this was occurring before the upgrade since it was a new code slot that hadn't been used before the upgrade.

I think my next step is to tear it all down and start over from scratch like @FutureTense said to get a 'clean' state. Anywho, I suppose things like this are why the versions for this integration start with 0.##, right?

[firstof9]

You may want to just wait for 2021.8.x version of Home Assistant

[smizles]

You may want to just wait for 2021.8.x version of Home Assistant

Is there something coming related to smart locks or zwavejs in 2021.8.x core? Apparently I don't know how to keep up with what features are coming soon 😞

[raman325]

zwave-js 8.0.0 introduced a change where user codes will not get queried automatically, which would break keymaster if you do a reinterview. When 2021.8 launches, we will have the ability to query for user codes when needed and added support to the refresh codes service for zwave_js locks

[smizles]

I deleted my Lovelace views for both locks and deleted the contents of /packages/keymaster to "freshen things up," but the integration keeps saying "Name already in use." What else do I need to do to clear the remnants of the old locks out to finish reinstalling this integration? I briefly tried naming it another name, but the UI seemed to be stuck in a user input error by that time. Here's a picture of the error when I try to reproduce it:

...and here's a screenshot of the contents of my /packages/keymaster folder:

[smizles]

I still haven't figured out the naming conflict error, but I uninstalled and reinstalled the Keymaster integration and created new locks named lock_front and lock_back. I set up the front lock first, but when I started readding the codes #3 & #4 were stuck on "Adding". This persisted after restarting Home Assistant. When I tried disabling code #4, it got stuck on "Deleting". The weird thing is that I added a code in slot #5 during the initial work flow, and that code appears as "Connected," so the integration must have skipped over those two problem slots?

Also, when I added the back lock and selected the front as the parent lock, none of the names or PINs populated in the Lovelace view and the codes from the parent lock are not working on that lock.

This "spring clean" process has made a real mess out of my locks, and I'm about to go out of town... 🤦‍♂️

[smizles]

Just got back in town and my system is still stuck in limbo. Is this issue on anyone else's radar? I have 3 of 5 codes appearing as "Connected" on my parent lock, and the other two codes still appear as "Adding" despite numerous restarts, and a couple of minor home assistant core version updates (2021.8.5 to 2021.8.8 since my last post). My child lock still shows no information synced from the parent lock despite two codes appearing as "Connected" even though I never touched any of the toggles. I'm on Keymaster version 0. 0.61, which is the latest version correct?

Also, I thought I did a clean uninstall-reinstall, but I couldn't rename my locks to the same names they had before. Is there any information in the docs about how to properly uninstall the Keymaster integration? I just spent 20 minutes digging around without finding anything, but I did delete my previous lovelace views, the contents of config/packages/keymaster as well as the folders themselves, and the Keymaster integration from HACS via the "Uninstall" button under the hamburger menu.

Here's a bunch of screenshots:

• Parent lock lovelace view:
  
  

• Child lock lovelace view:
  
  

• Keymaster info on my HACS tab:
  

[raman325]

Sorry, lost track of this one. So two questions:

1. For the PINs that are stuck on Adding, did you try the PINs on the lock? If so, did they work? If not, next question
2. Can you try using the zwave_js.set_lock_usercode service to set the PIN on the lock? What happens to the PIN status after you do that? Does the PIN now work? If the PIN doesn't work, that likely means there's an issue with the lock itself.

[smizles]

Hi @raman325, thanks for checking in and apologies for the delayed response. I had mixed results and went over it several times, but this is roughly what I was able to figure out.

1. For the PINs that are stuck on Adding, did you try the PINs on the lock? If so, did they work?

I had mixed results. 2 of 3 pins that were stuck on "Adding" worked on the parent lock, but none of them worked on the child lock. However, they weren't listed as "Adding" on the child lock and they code slots were all blank. Oddly two slots were selected as "Enabled", but I never manually toggled anything on the child lock so this must have been some sort of propagation from the parent lock.

2. Can you try using the zwave_js.set_lock_usercode service to set the PIN on the lock? What happens to the PIN status after you do that? Does the PIN now work? If the PIN doesn't work, that likely means there's an issue with the lock itself.

I think this might be a major clue to what the problem is. From the Zwavejs2MQTT control panel, I noticed some of the slots for the codes that were stuck in "Adding" had old codes still in them. I manually changed the code status partner property next to each of the stuck code slots from "Enabled" to "Available", which also purged the code slot when I was watching the Zwave debug log (sorry I don't have a copy of the data handy, but I can painstakingly extract it from the "store" log if it's pertinent to prevent this bug from appearing in the future).

I have since gotten this working again by the following actions and observations:

1. Digging through old issues on GitHub, I found your comment about properly uninstalling the integration from a related issue back in May ([Feature Request] LockManager uninstall procedure #137 (comment)). I was able to delete the current locks with modified names following your instructions (the version I named lock_front and lock_back). However, I noticed I still had a bunch of input helpers for the previous versions I had originally named back_door and front_door, and I couldn't delete them via that procedure because the integration never found them. In hindsight the entities might have been disabled in Home Assistant? That would explain why I couldn't re-add the locks with the same names I had previously used.
2. After uninstalling the keymaster integration and deleting the contents of /packages/keymaster, I was able to manually remove the extraneous input helpers and other related entities from the previous install by manually scrubbing and removing all relevant entries in these files (roughly 9,000 lines of code combined): /config/.storage/core.config_entries, /config/.storage/core.device_registry, and /config/.storage/core.entity_registry. After that I saved a copy of the modified files with a different name because Home Assistant overwrites them with the old values after rebooting. Then I turned off Home Assistant, removed the SD card from my Raspberry Pi, plugged it into a spare Raspberry Pi I had running Octopi (with some modifications like VNC enabled and a window manager installed) by using a USB adapter for the SD card, deleted the original files with the standard name listed above, renamed the newly modified files with the correct standard name, then removed the SD card, reinserted it into the RPi for Home Assistant, and voila no more trace of the old helper entities.
3. In hindsight I remember setting up the integration for the child lock after completely installing the parent lock, copy-pasting the lovelace raw editor code, and configuring the relevant user codes. This worked in an earlier version of keymaster when I upgraded from 0.0.33 to 0.0.51 to initially setup the child lock functionality (I had previously configured everything for my back door and was able to just delete the lovelace view for the front door, select the back door for the new parent lock drop-down in the integration configuration, click submit, then copy-paste the code into the lovelace raw editor and everything just worked). Once I upgraded to version 0.0.52 or 0.0.56 (can't remember) to 0.0.57 to 0.0.61 then to 0.0.62, I think propagating the code from an existing parent lock to a new child lock broke somewhere along the way. I say this because the codes in my child lock were completely blank like the picture above until I added a new code to slot 6 on the parent lock, which then propagated the code to slot 6 on the child correctly. I believe this was the only working code on the child lock when I tested it, but this was around the point I noticed the stale codes in the Zwavejs2MQTT control panel I mentioned in a previous point.

After finally getting a clean install everything seems to be working again, so someone smarter than me might want to close this issue. However, unless something in the code for handling the advanced day of week settings (or relevant zwavejs functionality) was changed between version 0.0.51 and now, I would hesitate because that was what caused my codes to get stuck in the "Adding" status in the first place. Also, the quirk with adding all locks to the integration prior to creating the lovelace views and setting the user codes should probably be added to the documentation to prevent similar issues. Finally, I know it is tagged as "work-in-progress", but I would like to bump the feature request for adding clean install instructions to the documentation because I couldn't find the proper procedure directly on the wiki for the life of me and that drastically exacerbated the issue (#137).

Thanks again to @raman325 and @firstof9 for your patience and all of your help!