Shlage FE599NX - Relock after manually pressing unlock button?

Looking to automatically re-lock after 20 seconds or prevent the lock from manually being unlocked.
Does anyone have experience with this particular lock model? I am under the impression that manually pressing the unlock does not sent unlocked event to WebCore. I did try writing a pretty straight forward script in WebCore, but it only seems to work if user unlocks door using code. I am already using the new Z-Wave device handler for this lock. I also see many people using a contact sensors closed event to trigger the lock. The problem is that someone from the inside can walk up and just press unlock without opening the door. I want to prevent the door from unlocking manually all together if at all possible.

It is not possible on that model to prevent The door from unlocking manually from the inside. That’s a safety requirement in most places in the US for locks sold for residential use so that in the event of a fire anyone inside can get out without having to know special codes or have a special key. This is a requirement for residential buildings where someone sleeps.

Is this on your regular home? Or on a shed or outbuilding?

You should be able to lock it again after one minute, but anything under one minute gets tricky on a Z wave system as messages can and do bounce around the mesh for a little bit. You can try it and see how it works.

Thank you for the reply… the part of your statement that confuses me a bit, (and trust me… I understand the entire fire code thing), is the part about not being able to keep it locked due to fire hazard. This lock has 2 physical buttons on the inside, lock and unlock. From the inside, even if the lock is in locked mode, anyone can still open the door from the inside. The only bearing the unlock button has is it keeps the lock open from the outside until the physical lock button is pressed again or Smarthings triggers the lock routine. Now I guess you can understand why I don’t want the unlock button pressed! Anyone can enter the building without entering a user code!! (Not good :frowning:)

My apologies, I misunderstood. From the statement above, I thought you wanted to prevent someone from opening the door. I understand now that you meant to prevent them from putting it into the unlocked mode. I don’t know if that’s possible or not, but hopefully someone else will.

Otherwise, I would think you could just put a little plastic box over that part of the lock and prevent access to the two buttons that way.

That’s actually a good suggestion… I was thinking to take it apart and remove the physical button all together. Your feedback gives me another option to consider! Thank you!

1 Like

If you’ve recently paired the FE599 with your hub then you won’t receive some events due to a bug in the hub firmware. You can read about it here and send an email to ST support about it so they can prioritize fixing the bug. Push Notifications for Schlage Lock Not Working (April 2019)

After it’s fixed you can set it up as you explained or use an app like LUM which has a customizable auto relock option.

1 Like


I actually purchased your product and changed the device handler, also have repeaters setup near each lock, (have 3 of these total). Only 1 of these is on an entry door to an apartment building. I verified that unlock messages are indeed reaching the hub/webCore, but it looks like when someone manually presses the unlock button on this lock… this is the scenario where there is no event! I am actually using LUM as a backup to the webCore script, and have it set to relock in 1 minute. Noticed this did not work either when someone physically presses the unlock button on the lock.

Is this what you were referring to in the April 2019 th article regarding some events not functioning? When I unlock this lock using the Smarthings App… I can see the events hitting the hub and eventually the webCore script does it’s thing and re-locks the door.

Any advise is appreciated! What am I missing here…

Yes that the firmware hub bug. The ST zwave firmware engineers are aware of the bug which is related to the new hub auto encapsulation feature. However the fix “priority” is based on the number of users who report it :slight_smile:
Report it to ST support along with the reference ticket number mentioned in the above link so they can tag it together which will help then prioritize the patch.

Will do Rboy! Thank you for the clarification… keep up the great work!