Removing a lock code from a Schlage Connect lock: "Code Position"

I tried to use the Lock Code Manager to remove a code from 1 of our 3 Schlage Connect locks.
The request has been pending for 2 days now, and I can see this under the lock itself:
requestedChange : {9={code=null, name=null, status=D}}
The code still works on the lock. I have cycled the power on both the lock and hub.

I think I should just give up on LCM (again) and configure the locks individually. Here is the lockCodes array:

{"1":{"name":"code #1","code":"????"},
"2":{"name":"code #2","code":"????"},
"4":{"name":"Sam & Nick","code":"0000"},
"10":{"name":"code #10","code":"????"},

( I have replaced the literal numbers with zeros for this post, everything else is literal)

I deduce that the target code to remove is "10" by the process of elimination. Even thought the code was added using LCM, the numbers are being echoed as question marks.

My question is: What INTEGER do I enter as the "Code Position" when running the deleteCode function?

  1. Do I enter 10 (even though that looks like a string in the array, not a true position index)?
  2. Do I enter 7 (because it's the 7th entry in the array)?
  3. Do I enter 6 (because the indexes for these arrays start at zero, like in Java)?


P.S. Here's an entry in the lock's logs, now doesn't that make sense?
"UserCodeReport- unable to enter code, it is in use on the lock codes array"

The position number, although it looks like a string, is the number (in quotation marks) leading the open curly bracket. So, yes, 10 is the lock code integer value for the entry "10":{"name": "code #10","code":"????"}

Thanks @ddalder, although this just leads me down a rabbit hole of more questions.

Why then (a hypothetical question really), did the Lock Code Manager add this to the requestedChange for the lock - when I tried to remove the user's code there?
{9={code=null, name=null, status=D}}

Considering that there is NO "position 9" to remove, I also wonder if the "pending job" for this user in LCM (and the requestedChange above) is therefore doomed to remain pending.... forever? :ghost: :jack_o_lantern:

I would suggest then (to nobody in particular), if ddalder's answer is correct, that the tooltip label for this command just explain this, if even by adding some quotes as a subtle hint:
Code position "number" to delete.

It is actually in the Hubitat driver capability documentation.

deleteCode() takes a single integer argument corresponding to the code slot number. Whereas setCode() takes three arguments of which the first is an integer and both the others are strings.

I've got 3 Schlage deadbolts and found that Lock Code Manager periodically resulted in unpredictable behaviour, including pending actions. This seemed to come about after I added the third one. With a limited number of both locks and users, I decided to just manage each lock independently through the device settings.

Some of the "quirks" I had resulted in factory resetting the three locks, removing the Lock Code Manager app and starting fresh. There may have been other options, but as mentioned, this wasn't a great deal of work. Removing and adding the lock did, of course, eliminated the pending action(s).

1 Like

Of course! SMH. That!
Then I hereby amend my suggestion (to nobody in particular), that the hub's device page contain a link to the capability documentation of the selected driver / type, maybe like this

The code still won't delete. Since I was probably going to need to do a factory reset and re-pairing anyway, I decided to change over to a Kwikset Home Connect 620.

OMG, what a pleasant experience when compared to the Schlage! I followed the community's suggestions (find device by brand, ignore the sticker and pair it close to the hub, select YES for the security option), and bada bing. No delays, no endless initializing, no code-setting lags, and no "failed jobs" to date.

So that's my solution: Same location, same topography, different brand. That's probably not gonna help future searches... sorry.

1 Like

I can certainly understand your frustration. Perhaps I'm a little biased. Many, many years back my brother was a locksmith. Kwikset brand locks (at least at the time) simply didn't have a reputation for being either as secure or well constructed as Schlage. At the time, the generally accepted order of product quality was Schlage, Weiser, Kwikset (of these three brands). Of course Kwikset now owns Weiser.

For my case, Schlage was a little more important because of other non-electronic locks at my residence. This was the only brand that I was able to have keyed alike for all my various locks. To avoid having multiple physical keys, this was the best solution in my case.

I considered Yale locks as well, but it still all came back to keying all locks to a single key. Otherwise, there's a reasonable chance I may not have stuck with Schlage Z-Wave products. I also considered Schlage Zigbee locks, but especially with the global supply chain issues, I had better luck finding a winning lotto ticket on the ground.

One big lesson I did learn was that if the Schlage lock doesn't pair, or doesn't complete the process fully, is that subsequent attempts often don't work. When I had a problem, a ghost node would appear and without removing it first, subsequent attempts were futile. Once in and working, I've really had no issues at all. It's just a case of finally getting there.

1 Like