So here is the modified driver with the suggested changes from @nayelyz :
Click this invitation link → Accept → Enroll → Available Drivers → Install Z-Wave Lock (AR).
Delete the device in the SmartThings app and add it again. Please keep the working device(s) as they are.
This is completely untested, of course. Next week I could add device preferences, so you could configure the behaviour per device.
Andreas;
Thanks so much for new driver. I installed as instructed with no problems and removed and reinstalled locks reporting wrong status. I verified in IDE that your new driver Z-Wave Lock (AR) driver assigned to each.
I was so expecting this to work, however the same result where wrong status reported in ST App after locking and unlocking. I’ve captured the log file of your new driver for the Kitchen entry lock. I took the following actions below:
So no change in behavior which is surprising. The only thing I can think of is doing another factory reset and then adding to smartthings. I wouldn’t think that would change anything. The lock is always added with the wrong status in ST, to that of the physical door. I am a bit perplexed.
I sent log file to build@smartthings.com. If you need me to send elsewhere, please advise. Or if you need anything else let me know.
Kind Regards;
Mark
I could flip the states in other places of the driver, but I don’t think that it solves your problem.
I’ll have a look at it tomorrow.
I think the issue is that these events don’t have a “state_change=true”
But also, something I didn’t consider is that the device also acts backwards when receiving a lock/unlock event, so I think you should define “capability_handlers” to do the opposite on each event because I see that the alarm 24 is now emitting the “unlocked” event as I mentioned before.
For example, the “lock” command was received and translated to “DOOR_LOCK” in the Z-Wave message sent, but it didn’t perform any physical action.
Too much work for two out of three locks that aren’t correctly installed or not compatible with 3-point locks… 
And without device preferences (“inverted lock state”, or something), the now working lock would do the opposite sooner or later anyway.
So, these devices can’t be installed separately? So, only 1 uses the driver from ST and the others the custom one?
Even using preferences, the “capability_handlers” should check “is inverted lock state active?” to see which path to take: the default one or the inverted one.
This is really unfortunate spending $750 for 3 smart locks only to have only 1 reporting correct status. I guess I will just have to live with the confusion in ST app.
I do believe nayelyz is correct in her assessment, because I ran a test on the only lock that works assigning your new Z-Wave Lock (AR) driver to it, where locking and unlocking it via ST app still reports the correct status as what’s physically happening at the door. If your custom driver was working as what we expected, you would have thought that a working lock would end up showing wrong status while the other doors the correct status. Ugh, I just don’t understand how Schlage’s locks don’t figure out their orientation when initially setting them up. Schlage have washed their hands of the issue, not supporting 3-way locking systems w/their smart locks, however none of their documentation notifies potential buyers of this shortcoming. The door manufacturer has nothing to do with it, because they bought linkage hardware to make it work for a 3-point locking system. But this is for all Schlage locks, smart or unsmart and I assume it’s Schlage whom supplies this linkage. But I could be wrong. Thanks to y’all again. Kind Regards; Mark
So, I realize this is a somewhat stale thread and possibly even unrelated to what I experienced.. however, as it was found when I was searching for solutions to my issue, I figured I’d post here in case it helps others.
I have a BE469 that is just regular ZWave (not Plus).. maybe that’s the BE469Z, I’m not sure. It recently started reporting to SmartThings that the state was “unknown”. It would often get “stuck” in a locked state or simply not lock at all. It would try it’s requested actions (lock/unlock) twice and then beep at the end and show a red X. I opened a ticket with Schlage and they had me do a factory reset, exclusion, inclusion, yada yada.. nothing helped. They gave up and told me to order a new lock. So, I decided to start pulling it apart to debug it.
It was mega easy to pull apart, so I’m not going in depth on that; but take a gander at the photos below.
Once this interior part is off the door after removing two screws and pulling off the keypad’s cable from the control board, then it’s really just three more little screws, disengage 4 (I think) pressure clips that hold the circuit board down. Keep an eye on the “interior” Schlage button and it’s frame (on the front side, not pictured) and pull it open like a book.
I found this rather import chunk of metal had fallen loose.
This is a close up of the gears the way I found them.
This is how it’s SUPPOSED to look (for a door latch on the left configuration). I stole this next picture from a review on the internet, where the user was swapping supported latch positions to the right side. [google search result linked, hoping it would help someone find it easily]
I straightened and super glued that little metal conductor piece where you see it in the borrowed picture above. I aligned the top plastic chunk in the same relative position as you see in the photo. That plastic piece spins somewhat freely along w/ the thumb knob on the other side.
I didn’t take a “finished photo” because I was SURE I’d be reopening this thing to tweak it again; but alas, I put it all back together (carefully) and it worked perfectly on my first try! I have no idea how LONG it will last. I noticed the latch is a little stiff with friction, so I’ll pull the latch mechanism apart later and give it a good lube job. That probably contributed to this problem.
While putting it back together, I struggled for a minute to get the circuit board to go back to where it came from in the frame. But the trick, for me, was to align the top side (where the battery module is into the metal frame first. Part of that section needs to be on both sides of the metal frame. In the first picture you can see a little slot where one side of the top of the “guts” rests, and the battery module goes on the other side. Yes, I left the batteries attached while doing this. It is not necessary to do that; but I was planning to keep an eye on the Zigbee status signal in the debug dashboard mentioned earlier in this thread or even in the SmartThings app. But, I forgot to look at that as I was putting it back together and just tossed it back on the door and tested it. It cycled a time or two to adjust it’s positioning and then wham.. it showed a real status of locked or unlocked!
Good luck. I hope this helps someone else! I have two more similar locks (but ZwavePlus).. I assume they’ll do the same thing one day, so when I search for the solution, I hope to find this post.
Yes!!! That’s awesome!
If I remember correctly, I suspected a hardware issue that prevented the lock to do its initial calibration run.
At the end it was just a peace of metal…
If you still have “my” driver installed, you should switch back to the official one.
Thanks Andreas.. I wasn’t the OP.. I never installed your driver. But you’re right to remind OP of that if they find a similar fix.
