[RELEASE] Universal Enhanced Z-Wave Lock Device Handler for Schlage, Yale, Kwikset, IDLock, Popp, Danalock, August Pro, Keywe, Philia, Samsung

Tagging @Aaron - if any of the ST engineers are interested in investigating this. Some of the users report the issue clear after a simple reboot/z-wave repair but it would be worth investigating and are impacting beamable devices (including thermostats we you would have seen in my eMail to ST support as well).

@eskdale, we have two babies who sleep throughout the day… as long as they’re not woken up by “PASSAGE MODE ON”

Yes - I just tested it - even if it’s in silent mode it insists on announcing passage mode on - can’t see any way around that without a firmware change to the lock. Wasn’t a problem for me as I find that reassuring that I can get back in or it reminds me to lock it as appropriate. But I can understand your issue. I have another Yale z-wave lock on a wooden door and this lock if you enable passage mode (autolock off) it stays that way indefinitely. Where this lock always turns autolock on every time you unlock it and there is no way to change this. Personally I think it is poor design (Firmware) from Yale, I don’t understand their thinking on this especially as the two models behave differently.

@rboy Is it possible to add an option to execute an action on a succesfull unlock only if a given mode is active?

I can find this fuctionality on the “lock by keypad” option but not on the unlock option.

Usage: There would be no need to execte a ‘welcome home’ action if somebody is allready home (which would be indicated by the mode) - only if you are the first to arrive home.


The feature already exists in the latest version (05.03.00)

Past week or so my device stopped responding to commands from the lock not sure if anyone else is having same issue. I reached out to @RBoy via email as well.

Could you perhaps guide me a little? :blush:

I’ve looked through the options several times but I only find this option on the “locking” action.

Sure do post the follow up on the user MGMT thread, this one for the lock DH.
Under the name is an option “while in this mode”. If you don’t see it you may not be on the latest version.

1 Like

Yes there has been lots of talk about it with the new hub firmware. Beaming devices are losing connection leaving it as a one way channel. Report it to ST support. Then exclude and repair your lock.

I have removed now I’m unable to re add…

Thank You.

Patrick Mjoen
Please excuse any typos.

Check out the discussion posts on this issue above (I posted the link in my
last post). Reboot your hub to get it to pair.

Anyone who hasn’t voted here, please votes. Your votes are important and help us make the product better:

I can’t seem to find a link to vote - I’ll keep looking but commenting here for my 4 cents worth…

I’d think that having the DH default to having the extra capabilities and allowing someone to easily comment them off would be the best option.

Having to remember to comment/uncomment for every update would be difficult and probably break something that would take a while to fix each time. Especially if it is 6 months or so between releases. The update would be more complicated than necessary. Worst case of having them on is that they show up in places as options to pick but, while that is a little clutter, not the end of the world. Also, if a person didn’t want to see them they could turn off the feature by commenting it out. All existing uses would always continue to work properly after upgrades and the only time you would notice anything would be when you were setting up a new automation or if they were shown on the device page (although a lot of devices have extra things on them (thermostats, for example) and I’d think that people would be used to look at the property or two they are interested in and ignoring the others.

Okay do vote here, click on the “link”

I’ve noticed a potential omission in the DH…

You’ve made it possible to get an alert if the Lock is Jammed, but it doesn’t do anything about it? I would have liked to have it try to unlock, then lock, if it entered the jammed state.

Also, I tried to create a CoRE piston to change the YaleRelockTime variable on the device, but this variable appears not to be made available to ST.

Couple of things:

  1. When a door reports jammed, it isn’t able to lock (unless it’s a false positive which can happen if you lock the deadbolt too slowly), so no point in unlocking and relocking, it’ll just drain the battery.
  2. The job of a DH is to interface with the lock, not make use cases (i.e. do anything about an alert), that’s the role of SmartApps (e.g. CoRE or Door Lock User Code Management etc)

Ah ok, thanks for the clarification.

I was just confused because when you add the lock, it asks you what to do if… etc…

I installed a Schlage BE469 last month, battery is still reporting 100% in the app. The motor is used about twice a day. There is nothing in the smartthings app or IDE device events that the lock is reporting battery level just lock or unlocked and by what (manually or app). I am using lock user management V05.03.00 and DH V03.01.02. Did I configure this correctly?

That fine. The system will poll the lock or the lock will update when the
battery level changes. If there is no change it won’t show up in the events

Well it finally just did that, now 99% Wow this is doing good!


1 Like