I’ve been using several Schlage zwave locks for years now, with the last couple of years using the @philh30 driver for Schlage 468/469 locks with the @h0ckeysk8er modifications. Today I noticed a lag between when I touch the circle on the ST tile to open or close the lock, and when the lock actually opens or closes. Sometimes it doesn’t even complete the task at all. Sometimes it does it, but the circle spins for another 5 seconds before the tile status updates.
Yet, if I press the tile from my Sharptools dashboard, the lock opens or closes almost as soon as I receive the green “Command Sent” confirmation.
If Sharptools is just sending codes to the SmartThings engine, how is it executing things more reliably than ST itself. Is there some change happening for the locks? I saw the notice of changes coming for the SLGA Service, but that’s scheduled to be complete in December. Will the SLGA changes cause a failure in using this version of the lock driver such that I will have to switch back to a gerneric ST driver? That would be unfortunate, because Phil’s/Bruce’s driver provides far more information that I am using in Sharptools.
Anyone else experiencing strange results with Zwave locks?
Thanks. I do have one installed on my phone, but it’s not active. Also, I have several Zwave light switches, and they respond almost immediately.
I rebooted the hub last night from the web app, and the locks seem to be responding better from their own tile. But the reaction to the “Lock All” button in the SLGA tile in the Life section is still very slow.
I also have Schlage z-wave locks. I am using the standard z-wave lock driver. I don’t notice any delay. On the flip side, I have had problems with delayed actions with some zigbee lights. Sometimes up to 5 seconds between button press and action.
Since it’s working almost immediately from Sharptools and not from the mobile app, I’m guessing it’s something between the app and the ST cloud. The driver isn’t invoked until the command is received at the hub from the API.
Also, I believe Sharptools is likely hitting the public API vs the app which uses a private/Client API. That could make a difference.
The manual lock/unlock functions should still work. And changing settings would still work. What would change is a few things
when SLGA goes away, there will be no way to maintain lock/pin codes for locks using existing 3rd party drivers (without modifications)
the current Z-Wave Lock PH driver provides the name of the user who unlocks the lock via the lockCodes capability. Since they are deprecating SLGA, I expect lockCodes will be deprecated as well so that function will no longer work
existing 3rd party drivers would have to be updated to support the new lockUsers and lockCredentials capabilities that replace lockCodes and the presentation would have to be updated to support adding lock users and pin codes on the device card directly vs a centralized app. @rboy has indicated they have made the necessary changes and will time an updated release of their driver to the production release of the stock driver
What you would likely loose by using the stock driver is the ability to modify the Schlage settings of the lock in a convenient fashion. You could always switch back and forth between the 3rd party driver and the stock driver, but that typically results in loss of pin code names, but perhaps not in the new stock driver implementation. You could also use a 3rd party Z-Wave configuration driver like those that both Phil and Mariano developed, but again, not nearly as convenient.
I might take a stab at updating Phil’s driver to support the new capabilities and presentation, but it might be easier to take the Schlage settings customizations and re-add those to the stock driver to create an altogether new driver.
I’ve been knee-deep in my day job and stage managing a show and haven’t spent much time lurking around here but might have some free time in the upcoming weeks to tinker around. Will let know if I come up with something.
The functions that depend on the lockCodes capability and SLGA will stop working. See the topic that @jkp posted.
That being said, I started work today on porting the Schlage features to the current version of the stock driver. It should be pretty straightforward since Phil had isolated them outside of the code of the lock driver and handlers. I’m hoping to have some time later in the week and next weekend to devote to getting it working. Will keep folks updated on my progress.
Status update. Have just about finished porting the Schlage features including Lock Activity (formerly Code name used to unlock) to the legacy handler section of the stock driver. This means that locks still using lockCodes and SLGA have the features from Phil’s driver but on the new stock driver base. Next will be replicating all of that onto the new code branch that utilizes the new lockUser and lockCredentials capabilities. While I’ll be able to unit test that code branch, I won’t be able to fully test the mobile app and driver behaviors until they give us access to lock migration.
One benefit to come out of adding the Schlage features to the legacy SLGA code branch is that you can now trigger Routines based on not just who unlocked the lock, but on any lock activity and optionally who performed (if applicable).
Sounds good to me, but then I’m just a dumb end user.
Quick question for you though. When you fixed up Phil’s driver a couple of years ago, and I don’t currently remember what it was, possibly a refresh bug in the lock, I enrolled in your Test Channel and installed the Z-Wave Lock BP driver from your Test Channel. When I look on the web at the channel information today, it has the Unenroll button (as I would expect, since supposedly I am enrolled). When I click the Available Drivers button, on the next screen it shows Z-Wave Lock BP but with an Install button. I thought that driver was already installed. My phone ST app shows I have Z-Wave Lock BP version 2024-07-19T22:59:00.735142616 installed. Am I in danger of losing control over my locks as you update stuff?
Well, dummy me forgot that you (and maybe others) might still be using my original patched version of Phil’s code that did the extra configuration report for autoLock since the lock isn’t generating it. When I started development of this new version of the driver, I removed the old one with the same name from my channel. You’ll be fine as long as you don’t Uninstall the current driver or delete it from your hub via the AWA or the CLI. The new driver has a different driverId and version so even though they have the same name/label, they are functionally different drivers.
If you decide you want to try the new version, there won’t be any going back to my previously patched version, however (you could of course use Phil’s version that doesn’t have the autoLock fix). That being said, I updated the method used to generate the configuration report for the autoLock to be more intelligent and not just blindly send a request for every autoLock event on every lock. It now waits to see if it gets back a report and if not, then generates a request.
I’ve exercised the legacy code path pretty extensively and feel the features are solid and ready for testing. I am also about ready to release a version of the driver that will allow you to emulate the migration to the new lockUser and lockCredentials constructs, however, without UI support in the mobile app yet because ST controls the presentation. You can create lockUsers and lockCredentials in the AWA and CLI and as part of migration simulation, I copy over your existing lockCode names to the new construct (which is what I expect ST will do).
Also, remember that should you install this new driver and move your lock to it, it will reset the code names to be the defaults of Code 1, Code 2, etc just like Phil’s driver did/does. So, be sure to write down which name belongs to which code slot so you can update them in the AWA using the nameSlot command. You can use the copy icon to get the array of values for lockCodes.lockCodes and it will look like this:
{"1":"Test 1","2":"Test 2","3":"Test 3"}
Also, a migrated lock will have an array of lockUsers:
