Schlage BE469ZP smart lock: Is this an improvement over BE468?

Hi community,

I have two Schlage BE468 z-wave locks and they have always had some problems. A big one is that a z-wave command issued to the lock will not result in the lock reporting its new state. However, manually changing the lock to open or closed will result in the lock reporting its state.

A second problem is that the lock seems to suffer from nonce errors now and then, and often enough such that I can’t have any assurance that a z-wave command to open/close the lock was actually successful.

I am presently using OH3 on a windows box.

Is the BE469ZP better in either of these regards? I’d greatly appreciate feedback, thank you.

I have a BE469 (I don’t know if it’s a ZP), and I’ve never had the nonce error you describe. It always locks and unlocks reliably for me.

This is still kind of the case. The Door Lock channel doesn’t update, but the Alarm (raw) channel does. So you can parse out the code to determine the unlock/lock state and then post an update to Door Lock. I have a rule I can share, but someone else here did all the hard work to make it happen.

Russ, thanks for the feedback. That’s encouraging.

With my BE468 I have a rule that is triggered by a change in Alarm (raw) channel, and like I said, this channel is not updated when the lock acts upon a z-wave command but only after a manual change to the lock.

If you’re saying that BE469ZP Alarm (raw) channel DOES update even when the lock is opened/closed by a z-wave command, that’s fantastic. Do I have that right?

Thanks again.

Yep, that’s correct. Here’s the original solution, from a thread that started with a Yale lock.

In OH3, you can apply the JSONPATH transformation directly to the channel, so that it will only send the information you want to the item.

I’ve isolated the event and use a simple case statement to update the lock status. If you want more detailed information, you’ll need to refer to the thread above.

switch (Door_Lock_Alarm_Raw.state.toString)
{
	case "1", case "3", case "5" :
	{
		Door_Lock.postUpdate(ON)
		// logInfo("Rules", "Lock updated to ON (locked)")
	}
	case "2", case "4", case "6" :
	{
		Door_Lock.postUpdate(OFF)
		// logInfo("Rules", "Lock updated to OFF (unlocked)")
	}
	case "11" :
	{
		Door_Lock.postUpdate(OFF)
		logInfo("Rules", "Lock is jammed, so setting lock to OFF (unlocked)")
	}
}
1 Like

Thanks again, you’ve been a big help. I’ll go ahead and replace my old BE468 locks.

No problem. I hope the nonce error is specific to the BE468. I can only speak to my experience, but I don’t recall anyone else mentioning it.

I love my BE469. I still carry a physical key (just in case), but I like not having to worry about having my phone or some other identifier in my possession to unlock my door.

1 Like

I just installed a new BE469ZP and I can confirm it is behaving as expected! It’s also responding within seconds to z-wave commands, as opposed to my old BE468 which might take 30-60 seconds to respond.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.