Thanks for you great apps!
@RBoy My lock has issue since March 1st. When I add new users, it always says “user code is not added” My lock is Schlage BE469. Device handler is v0402.07 and Lock user managerment v07.07.06.
I tried reboot hub and schlage lock, but no luck. Recently I can’t add any new user to the lock, but the existing user code works. Would you please advise.
Some folks have seen increased communication timeouts during the past week due to platform load issues (some of ST’s shards/servers seem to be running slower). One option is to increase the programming retry limit in the advanced settings section to say 10. The better solution would be to add a buffered repeater to avoid these latency/timing related issues. See this topic for more details: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?. See the note at the end for more tips on how/where to place the hub and buffering repeater.
I tried search through to see if this was discussed…
My guess is that it’s not possible to auto unlock my iris keypads when disarming SHM through my phone app or actiontiles? There are times I use my phone and times I use the keypad but they get out of sync. I assume I would need to use a routine on my phone to do this?
The arm/disarm state is controlled separately from the locked/unlocked state when used remotely (ie not via keypad) so that it gives folks more control over the keypad usage. (This is controlled by the keypad DTH FYR).
For example, many folks synchronize garage doors with the keypad locked/unlocked state. In such a scenario when SHM changes to disarmed and if the DTH were to automatically change the state to unlocked, it would also end up opening the garage door.
It would help to understand how you’re trying to use the keypad and why you would like the locked/unlocked state to change along with the SHM state when used remotely.
I think I follow. I guess it’s more of a visual thing for me. I have 2 keypads and they’re only used to arm/disarm my system. So when I “lock” the keypad, I’m not really locking anything. But actiontiles and ST reports the keypad as “locked”. So when I open up the ST app and just hit “disarm”, my keypad still reports and shows as locked.
Maybe my setup is wrong? I was basically looking to use the keypads as “arming” keypads only. But eventually I hope to add locks. It makes complete sense that you would not want to auto-unlock them.
You’re using it fine. The SHM and Lock are separate functions/feature of the keypad DTH as you’ve seen and not related to the SmartApp.
I’ll add this feature request to Keypad DTH to give the users an option to synchronize the lock and SHM states in the DTH options for user who only want to use one and not the other feature.
@RBoy I’m having an issue with Door Keypad Lock actions… Though not sure if it is just a notification glitch…
I have a action set to run my Goodby routine when the lock is locked with the keypad, but NOT if some people are present and NOT if in some modes. I also have the notify on keypad lock toggle set to off. Even when these exclusions are true I still get the “Front Door Lock was locked via keypad, running actions in 45 minutes” push notification.
It’s was a minor notification quirk when using delayed actions. It should had said “Checking for actions in XXX minutes”. It’s been patched in the latest update. Thanks for letting us know.
Do note that the Notify on Keypad Lock toggle in the Keypad Lock actions page applies to lock/keypads events which are generated without a user code (e.g. Schlage Lock n Leave, Yale One Touch Lock and Iris v3 ON buttons). If a user code is used to lock then the notifications options are taken from the individual User configuration page.
I have an unlock action set to turn on 2 sets of lights whenever my Schlage lock is unlocked via keypad. The issue that I’m having is that the unlock action doesn’t always work consistently. Also, it seems when the action is not working, I also fail to receive notifications of the lock being unlocked. I’m using the app along with the device handler and I also just added a range extender. Any tips or advice would be greatly appreciated.
They’re both linked to receiving the event from the lock. If the lock event doesn’t reach the hub then it won’t notify you and consequently won’t trigger the actions either. This is the most common FAQ when using locks in a Z-Wave mesh. The best way to avoid lost events is to add a buffering device which will hold the events from the lock until the hub is ready to receive them. Distance of the buffering device to lock vs hub to lock is also important for the buffering to the effective.
You can find a more detailed explanation of how it helps/works and how to setup/place the device on this topic: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?
I have an Aeotec range extender within 10 feet of my lock.
Using your LUM app along with your DTH. As of yesterday, I replaced my old Kwikset 912 with a Schlage FE599NX. Installation and inclusion was easy. Setting up LUM and the DTH were likewise easy. I have a couple of questions:
- The lock is reporting that access codes have been limited to (4) digits. Can this be changed via LUM. It doesn’t seem to be. Just asking.
- After entering a code and then opening the door is causing the door to relock within 2-3 seconds. I previously (with the Kwikset) able to disable that function and then use webCoRE to relock the door at any amount of time I choose. Is there any way to turn the auto relocking off - or even adjust it. Again, I don’t see that function in LUM. Just asking.
The pin code length can only be set via the physical lock for Schlage locks.
The DTH reads it (if you’re using the Enhanced Z-Wave Lock DTH) and reports it to LUM so that it can inform the user. Do note that when you change the pin code in your Schlage lock it also erases all codes. If you’re using the Enhanced DTH then it will detect this change and inform LUM which will reprogram all the codes otherwise you’ll have to reprogram them again (assuming they are the correct length).
The auto lock time on Schlage locks is fixed in the firmware but can be turned on and off via the Enhanced DTH. The LUM app implements a customizable software auto relock which can be programmed via the Door Open/Close Actions page. If you’re using the Enhanced DTH, LUM will do a sanity check to ensure that the hardware auto lock feature is disabled before it allows you to use the software auto relock to prevent conflicts.
Thanks for responding.
Thanks for pointing me toward manual keypad programming to do this. However, although I was able to find the ability and the key presses needed to change the length of the user codes on other Schlage locks, the FE599 does not seem to have this ability. At least (and I’d be happy to be wrong), I was unable to find it anywhere. I even tried using what works on the other locks but it didn’t work on the FE599. None of the FE599-specific information I found showed that this was possible.
On this one, the DTH doesn’t seem to show me anything to turn auto-lock off on it’s main screen or under the ‘gear page’. The main screen only shows the following tiles:
- Code Entry On/Off (vacation mode)
- Audio On/Off
- Battery Strength
And, just in case, here’s the IDE info from the lock:
Data * MSR: 003B-634B-504C
- manufacturer: Schlage
- networkSecurityLevel: ZWAVE_S0_LEGACY
Raw Description zw:Fs type:4003 mfr:003B prod:634B model:504C ver:43.37 zwv:2.64 lib:06 cc:85,73,72,98 sec:62,63,80,71,70,86,20
You’re right, I mixed up the FE599 with a different model.
- The FE599 doesn’t have auto lock. It’s an electronic latch with a relock that’s triggered about 3 seconds after it’s unlocked using a code. This can’t be changed, it’s how the lock is designed. The only way to leave it unlocked is to press the unlock button on the inside or unlock it remotely. Keep in mind that even if it’s unlocked, once a valid code is entered on the keypad it’ll relock itself after about 3 seconds.
- It also has a fixed code length of 4 digits unlike other Schlage locks
No worries. I understand.
I’d rather have 6-digit codes but I’ll live with the 4-digit codes. At least the lock has individual buttons for each digit as opposed to the doubled-up buttons on the Kwikset it’s replacing. This reduces the chance of getting lucky with keypresses.
As for the 3-second auto lock, I think that’s OK too (since I have no choice). In addition, I note that by manually pressing the unlock button on the inside of the door/lock, the lock will stay unlocked indefinitely. So, I’ve written two webCoRE pistons:
- The first automatically relocks the door after 5 minutes of being unlocked. It then checks up to five times to ensure that the lock has actually been locked.
- I then created an ‘override’ virtual switch that keeps the door unlocked for two hours - relocking it automatically after the two hours expires. It also includes the 5x confirmation to ensure it’s been locked
So, I have a full range of security/convenience solutions in spite of the auto-locking inflexibility within the lock. An automatic 3-second locking when entering a user code and then the 5-minute and two-hour automatic relocking based in webCoRE.
Thanks again for your time and great apps and DTH’s.
BTW, I installed this lock on Friday and it has performed perfectly in every instance since then and hasn’t fallen offline at all. It’s a big change from the increasingly flaky Kwikset 912 I’ve been fighting with for many months - even after replacing the Z-Wave module.
There’s another issue with Kwikset locks. They won’t accept two codes that use the same key combination. For example if you try to program 1234 and 2134, even through they are different codes some of these locks like the Kwikset 888/910/912 will reject the second code because it can’t differentiate between them when the user enters the code because they are sharing the same key press order.
To put it in context, a 10 button keypad can generate 10,000 unique 4 digit codes, a 5 button keypad can only generate 625 unique 4 digit codes.
Also see this topic for another issue we discovered with the 910/912 locks regarding programming issues:
I agree about this issue. It’s another one of the reasons I went to 6-digit user codes on the Kwikset but am OK with 4-digit codes on the Schlage.
From another thread, it appears that Kwikset Support says that when the lock drops off the network and a yellow light shows next to the ‘A’ button in the 912 Lever Lock and 910 Deadbolt Lock (that we know of) , it indicates that it’s possibly a bad motherboard. Not good.
Ran into a problem. The door would unlock itsself after being locked. Every time you locked it it would unlock. Discovered the door switch was louse and the manager thought the door was open. Disabled the unlock option. And fixed the sensor.
But this is major security flaw if someone shakes or forces a door and the sensor opens the door would unlock for them. Basicaly all you have to do is force the door open so the sensor opens and wait for the door to unlock.
This option needs to be removed. And everyone needs to be warned to turn it off…