Haven’t heard of any issues with our driver. Schlage locks have a few firmware quirks, they don’t always respond the way you expect it to (the 369, 599 and 468/469 each have different issues). There are specific order of events that need to be followed for different parameters. You’d expect that if Z-Wave standards were to be followed it would just work as documented/specified but it doesn’t in real life unfortunately.
3 Likes
@RBoy Do you have any notes on Parameter 15 (Auto lock) on the BE469ZP? Can you see if your driver is doing anything in particular (as a workaround) to ensure the driver gets updated with the correct status when the auto lock parameter is changed?
If you were using his old DTH from the previous architecture, you can install his Legacy Edge driver for no cost to do some testing.
Okay, the replacement lock arrived today and no surprise, it is still using firmware 0.11.0 although a manufacturing date of 03/20/2024. And no real surprise but I’m getting exactly the same symptoms where a change to the AutoLock setting (either from the ST app, or AWA) goes through to the lock but never gets reported back to the driver.
I really wish I could get an answer from @RBoy on what firmware issues they noted for the Schlage BE469 (firmware 0.11.0) specifically related to parameter 15 (AutoLock) and how they were able to work around it with their driver?
One possibility is that his driver either doesn’t rely on getting back the report from the lock and instead does an explicit call to get the state. Another variation on that would be to wait for a period of time and if the lock doesn’t report back within a certain time period, then query the lock’s status. It seems pretty clear to me that the lock is not behaving the same for that parameter as it does for the others and that there is clearly a difference in behavior of the same model lock with different firmware.
I know I’m coming late to the party, but this thread is one of the ones I came across while searching for my problem of “This device hasn’t updated all of its status information…”.
Yesterday I replaced my Schlage Camelot Connect lock for a Schlage Century Connect lock (purely decorative, not functional, reasons). And since then I’ve been getting that status message, and many of the settings are not available in the ST App.
I am using Phil’s z-wave lock ph edge driver. Swiping in the app many times over the last 18 hours has done nothing. So I re-added my old lock to experiment. It too began to display the message, even though it has worked fine for years. Then I found this discussion thread.
I found that if I “activated” features on the lock itself, they began to appear on the app. Then I tried activating features in the MySmartThings/advanced web app and that started to clear up settings too. I also checked my 2 locks at my cottage and found that they are using z-wave lock ph BETA edge driver and have been working fine for 2 years.
Anyway, I managed to get everything active on the old lock, but the new one still won’t turn on Auto Lock in the ST app. Note that clicking on the button in the web app does actually enable the feature in the lock, and you can disable it from the web app. However, the status of the setting does not appear in the attributes section of the web page (but it does for the older lock).
I tried switching to the Beta edge driver, but that didn’t do anything to help.
Then I noticed that the old lock is firmware version 0.10.9 and the new one is 0.11.0. So is this the source of the problem? Firmware? And if so, since there is a scarcity of the Z-wave locks (I can only find it on Amazon, not Home Depot Canada where I bought the original ones), I can only assume Schlage is moving away from it, which means they won’t be fixing a firmware problem for that model lock?
First, to help with settings in the ST app, go to the preference screen and change query lock code to off (false) and I also set code length to 4. Then save the settings.
That should at least get the screen matching the Advanced Web App because it will final refresh all the settings and changes made to either the AWA or in the app should then auto refresh in the app.
The issue does seem to be that the lock itself (with firmware 0.11.0) does not fire off a confirmation when the Autolock setting is changed (either manually at the lock or via changes in the app or the AWA).
Given mine was on 0.11.0 from several years back and Schlage even sent me a recently manufactured one with the same firmware, they don’t seem to acknowledge it’s an issue and certainly aren’t fixing the firmware anytime soon.
The workaround is relatively simple. If you ever change the Autolock setting in the app, you have to manually initiate a parameter refresh by pulling down from the top of the screen. That should get the app back in synch. Fortunately I’m not changing the setting that frequently so it’s not a big deal to me anymore.
I still wish @rboy would confirm he encountered the same issue with this firmware and his driver until he did some sort of workaround in his driver code. If he could explain that workaround, maybe the same change could be made here.
Now that @csstup is maintaining this driver, perhaps he can create a workaround for the autoLock setting issue by doing a refresh after the autoLock command is sent by the driver. A bit of hack, but it should resolve the problem. I’d whip up a version that could be tested but I’ve been working on a new feature for this driver that isn’t ready to be out in the wild yet.
I can’t make changes in the app. Mine is “greyed out”. I can only change the settings at the lock itself or on the web. Not that I change it. It’s just another annoyance that I get the error message every time you go into the details of the lock.
I didn’t pick up support for Zwave Lock PH. I don’t use smart locks and don’t have any to test with.
Someone else with lock interest should pick that up if Phil is tied up for small fixes.
Looks like I’ll be the one then 
I’ll create another fork of the repo separate from the one I’m doing the new feature in and see about adding a refresh when the autoLock command is issued.
1 Like
Note: When I click the autolock button in the web app, it does send the command to the lock, but even the web app does not show the word autolock in the value column of the attributes section of the web page (or the value off if I click the off button). So will adding a refresh enable that attribute in the ST app even if the web app remains a blank value?
Neither the webapp not mobile app get updated because the lock isn’t sending a report after receiving the configuration command. Sending a refresh will force the lock to send its current configuration and thus update both apps since both rely on the same API.
3 Likes