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

Oh, okay, that’s good then. I haven’t been bothered by the chimes but have been wondering what they were.

I haven’t updated the Z-Wave adapter to 1.6 myself, but I’ve seen 1.6 when browsing the IDE, so I’ve been assuming it has 1.6. Do you know what that “partial fix” were supposed to “fix”?

I’ll try to disable to audio notifications and see what that does in practice, otherwise I’ll make sure ID Lock knows.

I’ve updated to the latest version 04.07.02 and now me and my wife get push notifications after every code unlock. I’m not seeing any setting to disable these. Is there a way to do so?

Its probably coming from SmartLocks Guest Access. It’s a ‘feature’ of the new lock manager smartapp.

1 Like

Yes sir you’re right… push notifications being mandatory on that smartapp seems like an oversight :/.

So I just did the delete the DTH, create a new one and update. i didn’t disconnect from ST, just chawed the device type when done. Now, every time I enter a user code, it beeps six times before locking/unlocking. Is something wrong? Do I need to do something else? I tried going into the app on both the classic and new version and edit/save. Still beeping and delaying the lock/unlock by about 6 seconds.

EDIT: After further testing, it is only happening on one of the two locks. Not sure why.

Universal Enhanced Z-Wave/Plus Lock Device Handler - Version 04.08.01

  • Patch for a firmware defect in some locks models (Schlage Connect/BE46x, IDLock 150, Yale keyless) which cause out of order event delivery leading to incomplete notification details
  • Fixed a bug in the stock SmartThings device handler which causes missing information for notification events caused by z-wave mesh delays

If you are using one of the identified lock models above and are experiencing missing user (name) notifications while unlocking/locking, then update to this version of the device handler.
NOTE: While the device handler cannot recover packets not delivered by the mesh/lock, however this update can recover information from packets delivered out of order which lead to incomplete/incorrect notifications.

Please make sure that your lock is within 20ft of a buffering device/repeater for best performance and reliability.

2 Likes

My backdoor lock (Kwikset 910 I believe) looses connection. It’s definitely something with the radio. Anyway, I have it hardwired on a wall wart going into a SmartPlug and I just turn the SmartPlug off then back on to reset it. This works for a week or so then it’s back offline.

I noticed that in webCoRE there is an “Unknown” state. This state is also seeable (if that’s even a word) in Classic App SmartLocks Home Page and in the New App it shows offline. However, webCoRE seems to not be able to detect when the status is “Unknown”…

I wanted to execute this simple Piston but so far a nogo. Any ideas?

Hi, I have the Schlage BE469ZP and just migrated to the new Smartthings app. The icon for the lock device always shows unlocked even though its locked ! Is there something I could do or it’s a known bug?

Instead of lock unknown, I would trigger the piston by the device going offline, like this

1 Like

I understand that the missing tiles are a limitation of the new app. Is there a means of getting the missing features to the settings page? I see settings for Yale, kwikset, Danalock and IDLock but not Schlage?
Looking for Vacation Mode specifically for the BE469.
If not, would activating via keypad mess anything? I know LUM doesn’t like manual code entry.
Thanks!

We’re working closely with SmartThings to bring the “advanced” UI custom controls (auto lock, vacation mode, alarms etc) to the new app UI. There a few issues in the new app UI which ST is working on sorting out.
The DTH itself is completely functional with the new app,it’s just the UI that is lacking “custom controls”. The DTH settings page is fully functional in the new app (relock time, volume level, motor control etc - these are lock brand specific, Schlage doesn’t any configurable options here, see the first post for a full list of features for each lock brand).
In the meanwhile you also change the “settings” directly on the lock or use the Classic app UI. Lock “settings” (vacation mode, audio, alarms, auto lock etc) changed directly on the lock will sync with the DTH (which can be viewed from the Classic app UI until the new app UI is ready).
Only user code programming should NOT be done directly on the lock to avoid conflict with SmartApps.

2 Likes

Updated to this version. Names still not showing in History, just locked and unlocked.
Schlage BE469

P.S. Though names showing in Messages and Notifications

The details missing on the History page a known bug with the new ST app. We’ve reported it to SmartThings and they’re working on a fix for it.

1 Like

I’m having issues with the BE469NX, it’s detected as a ZWave device, I set the Handler to " Universal Z-Wave Lock With Alarms" and setup the smartapp.
I cannot control the lock remotely and pin doesn’t seem to come accross.
As recommended, I set the number of user to 0, but that doesn’t delete my code I used to have before the migration.
I cannot control it though, and logs say “Device with MSR null, AutoLock feature not supported”
I also have a Z-Wave plug (for buffer), like 5 ft away.

Any idea what could be the issue?

SmartApp Lock logs seems normal, but there is nothing else:
12:30:25 PM: trace The date/time on the hub now is Mon Sep 07 2020 12:30 EDT
12:30:25 PM: warn READ THIS BEFORE PROCCEDING: IT IS NORMAL TO SEE DEBUG MESSAGES EVERY MINUTE, IT CONFIRMS THAT THE APP IS HEALTHY AND RUNNING IN THE CLOUD. IT DOES NOT COMMUNICATE WITH THE LOCK UNLESS YOU SEE A MESSAGE BOX SAYING 'REQUESTED LOCK TO XXXXX

DTH Logs:

12:50:43 PM: warn Unknown device with MSR null, keypad state not available
12:50:43 PM: warn Device with MSR null, Alarm feature not supported
12:50:43 PM: debug Getting configured user pin code length
12:50:43 PM: debug Getting Alarm Level
12:50:43 PM: debug Getting Device MSR
12:50:43 PM: trace Current user pin code length 0
12:50:43 PM: warn Unrecognized device. Contact developer with MSR null
12:50:43 PM: debug Refresh called, Device MSR is null, FW is null
[zw:F, type:0000, mfr:0000, prod:0000, model:0000, ver:0.00, zwv:0.00, lib:00, endpointInfo:[]]
12:31:07 PM: debug Getting configured user pin code length
12:31:07 PM: debug Getting keypad state
12:31:07 PM: trace Current user pin code length 0
12:31:07 PM: trace [DTH] Executing ‘doConfigure()’ for device Z-Wave Device
12:31:07 PM: warn Unsupported device with MSR null, cannot query pin length
12:31:07 PM: debug Getting configured user pin code length
12:31:07 PM: warn Unsupported device with MSR null
12:31:07 PM: trace Z-Wave Device: Configuring lock settings
12:31:07 PM: trace [DTH] Executing ‘doConfigure()’ for device Z-Wave Device
12:31:07 PM: trace [DTH] Executing ‘configure()’ for device Z-Wave Device
12:31:07 PM: info Z-Wave Device: Resetting door tampering activity sensor
12:31:07 PM: info Z-Wave Device: Resetting smoke alarm sensor

type:0000, mfr:0000, prod:0000, model:0000, ver:0.00, zwv:0.00, lib:00

That means the lock didn’t pair properly with the hub due to packet loss (interference, lack of buffering, weak signal) or latency causing the hub to timeout. Try these steps (don’t skip any):

  • Exclude the lock
  • Reset the lock
  • Reboot hub (or power it down for about 10 minutes if you suspect issues with the Z-Wave mesh)
  • Reboot your internet modem (this reduces the latency)
  • Change the lock batteries (half used batteries sometimes can cause packet loss since the voltage drops below the operating level during the pairing process due to heavy load)
  • Bring the lock within 3ft if the hub and then pair it using the Scan nearby button (don’t use the brand name option as that disabled remote programming for some locks)

After pairing adding a buffering repeater between the lock and the hub for optimal performance: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub? - #2 by RBoy

Thanks @RBoy, I tried that without much success.
I found the manual and performed a factory reset (unplug battery / Press outside Schlage button / plug the battery) and this helped to repair correctly.
I thought everything was pairing just fine because I had a new “Zwave” device when pairing, but this time it was detected as a Schlage immediately.

I am trying to update the Device Handler for my locks from 4.00.02 to the newest 4.08.02 as I believe there are some bug fixes that are relevant fo me. I recently switched from the Classic SmartThings app to the new App and do not like how the default for the locks in the app is to display the “Contact Sensor” vs “Lock” which I understand is fixed in the newer handler.

I created a new Device Handler in the IDE and named it. I edited the device in the IDE and changed it to this new device handler with the updated code. When I go back to the SmartThings app, I cannot open the device… it just says it cannot communicate with the device and to contact support. I manually unlock the lock and looked in the IDE And see that it is picking up the state change so I decided to use the Classic App and sure enough I can see the status and control the lock. For some reason, the new App does not like the device handler. I reverted the change and went back to the old device handler version and I am able to see the status and control the lock in the new app.

what am I doing wrong here?

Thanks

EDIT
Maddie @ rboys support responded to my email -

There’s no issue with the device handler. The new app breaks devices when migrating from the Classic app. You’ll need to exclude the lock, delete the device handler and then reinstall it and pair it again to clear the platform cache.

I will was hoping to avoid having to do this, but i will try it and hopefully this works.

when doors are unlocked with code, can we disarm ST home monitor and run a scene.
I have option to disarm honeywell alarm only.
forgot to mention i migrated to new ST app…

Hey all, switched to the new ST app a while back and all was good. The Smart Lock Guest Access was automatically added to my smartapps when I completed the switch. It seemed to be controlling the lock/unlock function but all my codes were still working so I left it alone. Today my daughter reported her code not working so I deleted the guess access app. I also have 2 versions of the @RBoy app for some reason. One has my 4 codes one doesn’t. I tried updating the app code in IDE and I have no control over the lock, none of the codes work, etc. What should I do? This is a Schlage BE469 and the device has never been removed from ST.

If both the apps are programming the same lock at the same time, then one is erasing users while the other is adding users (remember one app can’t see what the other app is doing) and that’s what’s messing it up. You should only have one app program a lock at one time as explained in the LUM FAQ document. Clear all your codes and start over with a clean slate. Remember that schalge does not allow you to reprogram existing codes so make sure you clear all codes before reinstalling the app or follow the Clear Codes Procedure in the FAQ document.

2 Likes