I believe that's what I used--but maybe you have an idea.
It's painful to delete and add all the codes, as that only seems to work well when the hub is right next to the lock (and it can be slow).
However, it is extremely easy to accidentally delete codes using Lock Manager because the confirmation buttons and the other buttons move dynamically--so where you expect a next, you get "Delete" a fraction of a second later as I recall.
The lock in question has a direct link--and is only 15-20' from the hub.
The lock in question is a schlage and you'll have much better luck if you have a device that supports beaming. I'm unsure if the C7 does better with that, but I have an aeotec repeater and have had zero troubles with my schlage lock. But, I have a C4. Unless you have a zniffer and can confirm that your lock is, in fact, not bouncing around through a repeater and not missing calls, then you could go with it, but I can't confirm that the new 700 chip is supporting beaming any better as I don't have one. I have done a lot of research on z-wave and flirs devices need a source that beams. Period. This could be the cause of your errors. And you might not have to delete your codes and start over. That's your call. I can only communicate what I know to be true in my environment.
The locks actually do seem to be communicating to the Hub OK for the most part--just that some actions seem to be picky. I've got a housefull of Z-Wave Plus light switches/Dimmers, some very close--I thought they also could act as beaming devices. In any case, where I've put Aeotec RE 7s, nothing used them. And, as for this one lock, the nearest electrical outlet isn't much closer than the hub itself 
So are you able to confirm this with data? I have a schlage that communicates through my aeotec 6 repeater that is 30 feet away on the other end of the house. So, you can't predict what device your lock will truly like without being able to see the routing. If nothing is using your repeater then relocate it to about 5 feet from your hub or until you can see that things are using it. Again .. can only be confirmed by a zniffer.
I get my normal events without problems and the lock/unlock commands seem to work.
I'm looking at the C-7 Z-Wave routing table.
Have you tried removing the code from lock manager, and then deleting the code from the device page itself, finally adding back with lcm?
Edit - or perhaps remove all codes from the lock through lcm and starting from scratch?
suggested that above. Just trying to make sure that it's the only route to take.
Seems like the most likely route to a fix to me. I was curious if it had been tried.
As an FYI - Based on recent experience setting up 5 Schlage BE469 locks (older, non-plus).
If you change the code length (e.g., from the default length of 4 to a new length, say 5), then the Lock Code Manager doesn't seem to work right and will give an error message about the code slots already being in use.
What I had to do to get my locks working was to first install the "Super basic Z-Wave parameter tool", and switch each lock to use that as the driver. Then I checked that each lock was correctly set for 5 digit PINS (parameter 16) - for unknown reasons, setting the PIN length from the "normal" driver didn't always work. I then went back tot he "normal" driver and deleted the existing PINs from slots 1 and 2. After that, the Lock Code Manager application worked fine.
I might have to go the route of deleting all the codes. It's painfully annoying.
Thing is, the name IS in the list--it is just at the end instead of the front.
Since the mapping of the codes<>names is NOT done by the lock itself, that means it's either in the driver or the Lock Code Manager.
If the checking routine is only going to look for "code 1" in slot 1 of the array--then the routine building that array should keep it "sorted" in order.
Maybe I need to write a driver that just zaps the list.
Tried doing a code fetch from the device page? Maybe it'll fix the array?
^this...
LCM is stupid (intentionally) in that it simply reads whatever each locks lockCode event is.
@mike.maxwell So, when the name IS present in the "lockCodes" array for the lock, what is reading the code number and deciding if there's a name or not?
In my case, the code is absolutely IN that array--it's just that "code 1" is NOT in the first position of that array (code "2" is in the first position). Something is apparently expecting the entries in that "lockCode" array to be in "numerical order by slot".
I'm not following this, please pm me a screen shot of the lockCodes (with encryption disabled) as shown on the device page for this lock.
the ordinal position of the codes is irrelevant, it's treated as a map so the order doesn't matter.
Yes the driver will not change the code length. You can also change the code length from the keypad and set the driver accordingly.
BTW: In my case, I'm NOT changing code lengths.
But, to be clear, the driver does indicate it can change the code length (see control, below) -- it just didn't seem to work reliably.
This is also being discussed on the hubconnect thread.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
