Schlage BE469NX zWave inclusion problem

  • Platform information:
    • Hardware: RPI 3B+
    • OS: Openhabian
    • openHAB version: 2.4.0
    • Zwave binding is 2.4 -
    • AeonLab Zwave Stick Gen5

I’m trying to include a Schlage BE469NX lock into an existing and stable OpenHabian installation. The process proceeds normally but I get an ‘unknown device’ thing that offers no channels to configure or link to.

I tried some of the other thread on this topic with no success. Can someone help with this?

The device Properties are as follows:

zwave_beaming true
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_frequent true
zwave_listening false
zwave_neighbours 1,4,5,6,7,8,9,10,12
zwave_nodeid 14
zwave_routing true
zwave_secure false
zwave_version 128.22

I believe that device was recently added. You’d need to check the DB to confirm (on my phone ATM or I’d look it up). If so, you’ll need to upgrade the binding or OH to a snapshot version.

BE469 is listed in the bindings compatibility list. Do you think the NX suffix changes it enough to make it unique?

Yes. The nx has zwave plus and was added as a new DB entry.

I hate to upgrade a perfectly operational system to a snapshot version. Any idea when it will be included in a ‘release’ version?

Then just upgrade the binding. But forget all that, since it was the BE469ZP that I was thinking of. The BE469WK and BE469NX are the same (WK for Wink and NX for Nexia), and these are just BE469 in the database. Look at the Thing for your lock in Habmin. Under Attributes, do you have a green mark next to Security? If so, then you just need to get it to initialize. If not, then you need to exclude it and reinclude (using Habmin, not through the zstick) from very close to the controller.

The release and milestone schedules are delayed due to the ESH reintegration and build system changes.

Scott – thanks for your help.

I don’t use Habmin due to lack of compatibility with Microsoft browsers (don’t judge me :slight_smile:). But I did fire it up on chrome on another machine and the BE469 device has a RedX next to ‘using security’.

I did do the initial inclusion using the ZStick button instead of Habmin.

I tried “Remove device from controller” then entered the programming code followed by ‘0’ on the device keypad. (The RPI w/ZStick is about 30 feet from the lock) The device times out and seem to tell me the exclusion failed.

No feedback on habmin.

I’m leaving for vacation on Saturday and would love to get this issue worked out prior.

You can exclude directly with the zstick, but you can’t securely include with it. Some devices, this lock included, require the controller to be very close for secure inclusion to work. I usually have the controller touching my locks and it sometimes takes multiple attempts. You will need to exclude between attempts. Failed attempts will leave dead Things that will need to be deleted. There are a lot of threads specifically about including the BE469.

Some magic happened overnight: I woke up to the device ‘properly’ configured with green check mark next to security. and 3 channels available: Lock, alarm and battery level.

It also reports a ‘self healing’ events 3 hours ago.

The listening attribute is still showing with a red mark and the user codes are all empty. But I’m able to lock and unlock the device.

Well that was easy! Did you actually include from 30 ft away? Best I’ve ever done is 10. If you can control it then it is definitely securely included.

These locks don’t listen, since they are battery powered devices. But they are frequently listening. These locks also do not report state changes, so you need a rule triggering on alarm_raw to update the state.

My next step was to dismantle my setup and move it closer to the lock (one of the reasons I was using the Stick inclusion instead of doing it in Habmin). But, you get lucky every once in a while.

Thanks for the pointer on alarm trigger and Thanks for all your help.