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

[jstro (John Strong)]

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.

[rpwong (Russ)]

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.

@jstro

A big one is that a z-wave command issued to the lock will not result in the lock reporting its new state.

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.

[jstro (John Strong)]

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.

[rpwong (Russ)]

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

Zwave - Yale YRD220 Lock

Here is my current rule for parsing alarm_raw. My locks (Schlage BE469) do not update the lock_door channel, so I use alarm_raw to update the items linked to lock_door, and base rules off of that item’s state. Maybe all locks behave this way? You’ll find several examples of using the JSONPATH transform to parse the data in the lambda. This can be tricky though, because JSONPATH will throw an exception if the element name you are searching for does not exist in the JSON. I haven’t had any issues…

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 in a rule to update the lock status.

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)")
	}
}

The rule is triggered by Door_Lock_Alarm_Raw receiving an update.

If you want more detailed information, you’ll need to refer to the thread above.

[jstro (John Strong)]

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

[rpwong (Russ)]

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.

[jstro (John Strong)]

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.