Lock Code Manager Issues:
When trying to add a code to a lock that already has that code, Lock Code Manager just says "failed" without any idea why. After a perusal of the logs:
dev:27032019-08-22 01:25:41.886 pm infoFront Door Lock user code not added, duplicate[6:0xF]
(If I have to go to the logs to find out why something failed, it's not very user friendly. The program should check if the code already exists, and trap it as a user entry error).
When trying to add a new lock code, the following error message shows:
In the meantime, I just went into the device status page, and set the codes manually.
Curious, are those lock codes that exists because you entered them originally from lock code manager? Or do they exist because you entered them at the lock?
LCM is expecting the lock driver to already have any codes downloaded from the lock, given the error that the driver reported it would seem that the driver didn't get the codes from the lock when it installed.
need more info:
which lock is this?, and after installing it what if anything was contained in current states lockCodes?
Don't post the lockCode info if there were any actual codes shown...
The lock is the zwave plus Kwikset Smartcode 880.
I entered these lock codes via the Device Status page.
Furthermore, on the right side of the Device Status page, these codes are shown.
I think that if you play around with the LCM you will notice a number of errors.
Part two of question I asked was if when the lock originally joined if it fetched any codes from the lock.
Mike, I honestly don't think so, because this is a new lock that I put on specifically for Hubitat compatibility (it works really well).
Then why did the lock report that there was a code in use?:
Because it was already programmed in the lock from the device status page.
I can't find any docs for this lock (or really any mention of an 880 at all), but I wouldn't be so sure that a new lock doesn't have any codes. All I've used come with one or two pre-programmed codes, and I find LCM works much better if I erase all of them first (manually from the device page by going through every slot just in case works for me, but the lock itself might also have a way).
The actual lock is the Kwikset Smartcode 888:
Surely the LCM should work with the lock to determine what codes are already present on the lock before bombing out with an "unexpected error"! That's not very user friendly.
Do you mean with this lock? I've played around with LCM plenty and don't find a significant number of issues. There's a limitation to its capabilities, sure. Errors? Not sure exactly what you are referring to.
I'm in agreement with @bertabcd1234 that you will have better success in general with LCM if you factory reset any new lock, and then enter the code only from LCM.
[Edit] Sorry, just saw your earlier post. It's a compatibility issue. I don't envy the task of trying to write one app that covers so many variations in these locks. Even within a single manufacturer line there seems to be locks that work fine and the next model from the same manufacturer has issues. However, if wipe the lock first with a factory reset, and you don't try to add the lock codes from anywhere but LCM, are you saying it's still an issue?
No it's not. Small team. The Hubitat Elevation hub only just started selling to the public over a year and a half ago. You're not new here. You know this is a work in progress. They know it's a work in progress. Who said anything about polished? And finished? The hub will never be "finished". It's not a bridge. Why so aggressive? They work like dogs.
A softer approach is in order in my opinion.
My comment from before still stands.
A Lock Code Manager program should understand what is currently on the lock, should it not?
In my humble opinion, any program which throws off an "unexpected error", and causes the user to debug the code by looking at the logs, is not a "finished" or "polished" program for a consumer oriented product.
Yes, I suppose that you're right. Patience is definitely required for "new" products.
And, especially a product that has come so far, so fast, as Hubitat.
OK. The approach has got to be patience, patience, patience.
(I counsel young adults to use that approach, so I should use it myself!)
I will try and go back to the drawing board, and document exactly what's causing the error, and try and show how to reproduce the error. That way the team will have all the info that's required to squash these bugs.
yeah, that's my point, and so far you're unable to remember if it was able to fetch any codes from the lock or not when it first was setup...
It's obvious that it didn't, since the lock refused the code you sent to it via the driver, the only way this can happen is if the codes didn't download from the lock in the first place, and that's a whole other issue and can vary from manufacturer to manufacturer and mesh to mesh.
If the driver didn't get the codes from the lock, LCM sure isn't going to get it.
LCM gets the codes from the driver, the driver is responsible in getting them from the lock...
I will try to duplicate the error (tomorrow) via the following process:
- I will get rid of all codes on the lock (I assume that I can do this via the device status page).
- I will use LCM to put in new lock codes.
- I will execute LCM again, this time with a duplicate code.
If there is an "unexpected" error, at that point, then I will be able to document that, and we can move forward from there.
Is that an acceptable process?
Thanks for taking the time to check this out, LCM and the lock driver won't let you enter a duplicate code, neither of them will even attempt to send it to the lock.
I'm more interested in what happens when you add a new code directly on the lock.
If that new code doesn't show up in the driver after a few seconds, then thats the real problem.
If the code does show up, then it would be almost impossible to figure out what happened the first time you did it and it failed...
That's precisely the point.
If I can reproduce the error, and document the circumstances under which it occurred, I presume that you can fix it, for it surely is a bug.
I will start on that process tomorrow.