Hi,
I saw it written earlier that 1.13 was expected to resolve the Schlage issues. But I also found a thread in March where a user reported that 1.12 resolved their issues. “Well, folks, I can verify that firmware 1.12 resolves the Schlage BE469NX issues”
Are the Schlage issues confirmed to have been resolved?
I realize that the Yale locks are recommended for better/easier integration with 2gig/Alarm.com (and I have one on my back door that I like very well), but I really prefer the looks of the Schlage set for a front door, and I am hoping that they are now well supported!
I can’t confirm that 2GIG, Alarm.com and Schlage have worked out all their compatibility issues. We don’t use Schlage locks here so we can only go by what others post about Schlage. I’m not aware of any known issues with the Schlage BE469NX and the 2GIG 1.13 firmware but that doesn’t mean they don’t exist. I’ve seen too many compatibility problems come and go with Schlage locks to be confident that it all works now. Hopefully someone else on here who has a BE469NX and runs 1.13 firmware can chime in and tell you how it’s working for them.
Thanks.
I ordered one; wish me luck! I’ll check in with an update after I’ve updated the firmware and installed the lock.
UPDATE: Well, I got the firmware updated to 1.13 yesterday and the Schlage BE469 installed today. So far, so good!
The lock was manufactured in Jan 2015.
I ran into a snag when I first enrolled the Schlage as a zwave device; the panel didn’t properly identify the lock and couldn’t query its device status. I came across some postings that said the new device could sometimes already be joined to a manufacturer’s zwave network; deleting the device and re-adding it worked.
So far it is behaving exactly like the Yale T1L. Both locks are showing up on alarm.com and obeying the automation rules, locking when the system arms and disarming the system when the code is entered on the lock’s keypad.
So, maybe they have the bugs worked out? I’ll post back if I find any Easter eggs.
Issues related to Lock communication are commonly caused by an incomplete pair process with the controller. It is important to make sure the lock and the panel remain in close proximity during this process.
Good to hear it is working well so far.
That could have been the problem. The first time I paired the lock I had the panel in its normal location 15-20 ft from the front door. Then pulled it off the wall and took it to the lock for subsequent attempts.
On a side note; what is it about the pairing process that requires the two devices to be in close proximity? It seems to me like if the radio device can function properly during normal usage, then it should be able to pair under the same conditions.
A proportionally large amount of encrypted data is being transferred. Every device you add should be within a short distance from the panel, but lights are often able to get away with a little extra distance given their relative simplicity. Add into that the fact that the lock is low voltage and battery operated.
Quick update: The BE469NX and firmware 1.13 have been in place for a week.
No apparent issues; I’ve got a rule set to lock it when the system arms, and one to disarm the system when unlocked by user code.