I have tried everything, but 2 out of 3 of my Schlage Connect BE469ZP locks report the wrong open/close status. When the lock is closed (manual & thru ST), status in ST shows open. Same when lock opened, ST reports closed. The 2 doors in which not working are 3 point lock systems with special adapter for Schlage locks. When compared to the door w/schlage deadbolt that does work, the position of the thumb turn is different. On door that works thumb turn is 0 deg when unlocked and 90 deg toward door jam when locked. On doors that don’t report correct state, the thumb turn 0 deg when locked, and 90 deg away from jam when unlocked. So like the exact opposite from door that works. I would have thought when the lock goes thru it’s initial setup after a factory reset in which it locks itself, unlocks itself, it would learn orientation of lock, unlock status. I have exhausted all recommendations online. Unpaired lock, did factory reset, paired again, then entered User Code A on keypad, which is part of setup that closes and opens lock (which I assume detects it’s open/close orientation). Have done this multiple times with same result. I securely pair lock to ST using DSK code successfully and as published. The locks join perfectly and recognized in ST. I’m using the stock ZWave Lock Driver which works flawlessly with one of the locks. I have latest drivers and Aeotec hub. All 3 locks were installed by builder and installed per manufacturer. My batteries are fresh and showing 99%, so I’m totally stuck. Any help would be greatly appreciated.
Hi, @Lash
Can you confirm you’re using SmartThings drivers, please?
Also, can you open support access to your account, and share the names of those devices, please?
- Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
- Enable support access to your account:
- Go to the SmartThings Web (my.smartthings.com)
- Log in to your Samsung Account
- Select Menu (â‹®) and choose Settings
- Toggle on Account Data Access
- Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again
Thankyou. I’ve given permission to account data access as well as my email is same for forum & smarthings. The device names for Bellaire Home are Garage Entry, Front Entry, & Kitchen Entry. Only the Garage Entry reports correct status, but all 3 are Schlage Connect Z-wave smart locks Model BE469ZP. I have confirmed all using Smartthings Z-Wave Lock Driver version: 2024-12-17T18:00:48.572636846. Any help would be greatly appreciated and will monitor for any responses by y’all. Kind Regards, Mark
Just to add. We have a call into the manufacturer of the doors 3-point lock system with the special linkage to accomodate Schlage locks. We are seeing if the thumb turn orientation can be adjusted in any way similar to the deadbolt on Garage Entry door (90 deg toward door jam - locked, 0 deg away from door jam - unlocked. I highly doubt it can be adjusted as like the lock only one way to install it. Thanks.
Hi, @Lash
So, the engineering team mentioned that the driver should reflect what the device is reporting which means it isn’t caused by a configuration in the driver. We can confirm this by opening the driver logs and then controlling the device to see which value the physical device is sending.
To get them, you need the following:
- Set up the ST CLI and run the command below:
smartthings edge:drivers:logcat
- The CLI will prompt you to select from which hub and driver you want to listen to events
- Then, send commands to the devices so they get registered there
- Copy those logs in a file and share them with us, you can send it to build@smartthings.com.
We’re not sure what you mean by “special adapter for Schlage locks”, but if the issue is caused by the way it was installed, the solution would be to create a custom driver that handles the reports differently.
Hi nayelyz;
I sent the logs to build@smartthings.com. If you need anything else, please let me know.
As to your question about special adapter for Schlage locks. For the 3 point lock system to work with the Schlage connect smart lock, the door manufacturer has physical linkage hardware to adapt the lock for that 3 point locking system. It’s just not a dead bolt, but pins at top and bottom of door. This really shouldn’t be an issue as you turn the thumb knob towards the door jam to lock and away from door jam to unlock. Thanks again for your help. Mark
Hi Nayalyz;
I sent you a more simplified log file to build@smartthings.com concentrating on a single lock that fails to report proper lock/unlock status in ST app. This time I took the simple actions of locking and unlocking from smartthings app. In email I gave some detail of the order in which actions taken, and the results.
Hope this helps clarify your question.
Thanks for the information, @Lash
So, in the logs, after the command you sent which is to “unsecure” the device, we see a report from the physical device identifying the “alarm_type=25” which is translated to “unlocked” (here’s the driver code where it is done).
The engineering team mentioned that these devices seem old since they’re using the AlarmV1 Command Class. The code I mentioned above comes from the Groovy days, which means it’s been working as such for a long time.
Since the device is reporting the “unlocked” status, despite it’s physically “locked”, I was thinking if it could be due to the current status known by the platform and the command sent to it. So, please help me test the following:
- Go to the Advanced Users app - Devices
- Find the lock device and enter its details, and go to the “Commands” section.
- Verify which is the current status of the physical device (locked/unlocked)
- In the Advanced Users app, click on the command that would send the opposite status to the device.
- Check the action in the physical device and if the correct status is reflected for the capability, which can be seen in a section above called “Attributes” (You can also check the app).
Note: Just to clarify something, the command “unsecure” sent is because, the current “known” status is “locked”, so, the only possible next status is “unlocked”. That’s why we need to send a command through the API, since we can chosee which one to use.
The lock was physically locked before I went into Advanced ST App, yet in the Kitchen Entry attributes section showed “unlocked” with a time stamp. I then sent the command “unlatch” and the lock did not physically respond. When looking at attributes section it still shows “unlocked” with the SAME timestamp. I then tried sending “unlock” command, resulting in the same exact result. The app said both commands sent successfully, but had no impact on the physical lock, status or timestamp of that status. So ST thinks lock is already unlocked when commands sent to unlock it, even though physically it is locked.
I then sent “locked” command, and the lock responded by physically unlocking. When I look at attributes the lock now shows
(Continued) status of “unlocked” with the timestamp now updated. So again it’s reporting exact opposite to what the physical state of the lock. The problem starts with ST reporting the wrong status the physical state the door is in. So when you send commands, you have to send the exact opposite command than the physical state of the door is in. So strange as I’ve tried over and over with factory reset to get the lock to report it’s current correct physical status with no lock. When it goes thru it’s setup routine of locking/unlocking, it sends the wrong physical status from the very start when joining in ST. Ugh!!!
Sorry. The beginning of (continued) text is wrong. It should read “(Continued) status of “locked” with the timestamp now updated”. It’s so confusing trying to explain. It is simple though. Whatever the physical status is of the lock, locked or unlocked, ST shows the exact opposite.
That is only true in the app. In the API, we can send any command we want, the difference would be that, if the device reports the same status as before and an event is issued with the same value without forcing a state update, it will be ignored. I think that’s what is happening in this case since the timestamp isn’t updated.
We can also confirm seeing the driver logs, so, if you capture them and describe me what you do and see in the physical device, I can help checking them again.
If the device keeps reporting the opposite, then, we would be confirming the issue is in the physical device side. So, what you could do is:
- Create a copy of the SmartThings driver,
- Edit it to add custom handlers to translate the messages differently.
Nayelyz;
Thankyou. Whether command submitted from API or app, it’s the exactly the same results as you predicted. I think you are onto the solution to create a custom driver from the Z-Wave lock driver and applying to only those 2 locks.
Can you help with instructions on how to do that thru the API. I’m a novice using the API. I really don’t know how to copy the existing Z-wave driver and renaming and then editing. I’m sure once I see the code I’ll be able to figure out the logic, but how do you start with copy and rename. Once I save, I suspect I’ll be able to select that new custom driver for the two locks that need the opposite commands sent to lock/unlock.
Kind Regards;
Mark
Here’s a tutorial:
And here’s the stock Z-Wave lock driver:
Haven’t paid attention to this thread, but from what I’ve gathered, you would have to switch the emitted events.
Yes, it should learn the orientation in the initial calibration after a factory reset. The lock will report the correct state afterwards.
Are you sure, you did that right?
First, you would need to download the repository @Andreas_Roedl shared above, but you need to go to the root directory:
Where you can select to download the code as a Zip file, for example:
Once you download the file, extract it in the location of your preference.
To edit the code there, I suggest you use a code editor like Visual Studio Code because it can show you if there’s a syntax or duplicates errors.
- Open the driver’s folder in Visual Studio, we would need to change the driver’s package name which is in the root directory - File: “config.yml” so it doesn’t confuses with the one from SmartThings when you assign it to the devices.
- Go to this path:
“drivers/SmartThings/zwave-lock/src/zwave-alarm-v1-lock” and open theinit.luafile in the last folder.4. - Find the conditions for alarm type 24 and 25. Which is what we saw your device reports:
Usingctrl+Fcan help you look for the text easily.
First search for “elseif (alarm_type == 24) then”. Below this line you’ll see the value of “locked” is set. Change it to “unlocked”, for example:
event = capabilities.lock.lock.unlocked()
Then, search for “elseif (alarm_type == 25) then”. Change the line below to be set as “locked”, for example:
event = capabilities.lock.lock.locked()
- Once you’re done, you need to package, assign the driver to a channel and install it in your hub so, you need to configure the SmartThings CLI first.
- Create a driver channel using this command:
smartthings edge:channels:create
Remember you need to copy the channel ID for the final command of step 6.
- Then go to the Advanced User’s app to get the Hub’s device ID and copy it
- Finally, construct this command by replacing the values where it corresponds:
smartthings edge:drivers:package "complete-path-to-the-driver" --channel=channelId --hub=HubId
Please, let me know if you have any questions.
The problem with this approach is that the working device(s) will sooner or later use the modified driver and report the “wrong” state. Preferences would solve that, but that’s a lot of work.
There are several old (DTH era) threads here regarding this issue and in one of them it was solved by running a Z-Wave Repair.
I’d go as far and replace one of the non-working devices with a new one to see if it’s a hardware issue.
Thanks. I am absolutely positive the factory reset was completed correctly. This is happening on 2 of the 3 identical locks I have. The 2 reporting the wrong status are 3 point locking systems, the one that reports status correctly a simple deadbolt. So I know it’s not due to faulty locks. The 2 locks work perfectly except for reporting the opposite status than lock is physically. It’s funny, because during the factory reset, the lock goes thru it’s routine of locking and unlocking to what I thought, like you, is trying to figure out the orientation. Schlage responded by saying they don’t support their locks for 3 point locking systems with special linkage to accomodate their lock. I wish I would have known before investing in these locks. Impossible for me to change out door or lock now.
I can create a modified driver for you in the next days when I’m back home.
Did Another Z-Wave repair successfully, but no change in behavior of the locks reporting wrong status. I would greatly appreciate a modified driver. I don’t see any other solution as Schlage or the door manufacturer have both said it’s not their problem. Ugh