Schlage BE468GBAK Zigbee Question

I put this in general support, but think it belongs more on the device side... withdrew from the support site.

I am having a heck of a time getting a schlage BE468 Zigbee lock to pair with hubitat. I have reset the lock multiple times (press schlage button and connect battery at same time) and I have the HE right next to the lock when trying to pair. I keep getting a blinking green light when going through the pairing cycle.

Here is Logs of what happened while trying to pair.. Any help would be appreciated... interesting that the first lines are repeating over and over.
sys:12020-04-30 08:32:19.915 am infoZigbee Discovery Running
sys:12020-04-30 08:32:18.897 am infoZigbee Discovery Stopped
sys:12020-04-30 08:31:18.885 am infoZigbee Discovery Running
sys:12020-04-30 08:31:17.055 am infoZigbee Discovery Stopped
sys:12020-04-30 08:30:17.044 am infoZigbee Discovery Running
sys:12020-04-30 08:30:16.010 am infoZigbee Discovery Stopped
sys:12020-04-30 08:29:16.003 am infoZigbee Discovery Running
sys:12020-04-30 08:29:14.985 am infoZigbee Discovery Stopped
sys:12020-04-30 08:28:14.973 am infoZigbee Discovery Running
sys:12020-04-30 08:28:14.941 am infoZigbee Discovery Stopped
dev:5402020-04-30 08:27:57.526 am infoZigbee parsed:[raw:catchall: 0000 0006 00 00 0040 00 84B0 00 00 0000 00 00 03FDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:84B0, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, FD, FF, 04, 01, 01, 19, 00, 00]]
sys:12020-04-30 08:27:14.929 am infoZigbee Discovery Running
sys:12020-04-30 08:27:14.903 am infoZigbee Discovery Stopped
dev:812020-04-30 08:26:58.786 am infoEntry Way switch was turned off
app:2342020-04-30 08:26:58.665 am infoTurn On & Set Level Entry Way when Front Door Opened anti-Turn On & Set Level
dev:42020-04-30 08:26:38.720 am infoTable Lamp was turned off
sys:12020-04-30 08:26:14.892 am infoZigbee Discovery Running
sys:12020-04-30 08:26:14.866 am infoZigbee Discovery Stopped
sys:12020-04-30 08:25:14.855 am infoZigbee Discovery Running
sys:12020-04-30 08:25:12.075 am infoZigbee Discovery Stopped
sys:12020-04-30 08:24:56.153 am infoCreated Unknown Zigbee Device
sys:12020-04-30 08:24:12.064 am infoZigbee Discovery Running
sys:12020-04-30 08:24:11.875 am infoZigbee Discovery Stopped
dev:5402020-04-30 08:23:55.700 am traceZCL version:02
dev:5402020-04-30 08:23:55.691 am traceSoftware Build Id:unknown
dev:5402020-04-30 08:23:55.682 am traceModel:BE468
dev:5402020-04-30 08:23:55.628 am traceManufacturer:Schlage
dev:5402020-04-30 08:23:55.275 am debuggetting info for unknown Zigbee device...
sys:12020-04-30 08:23:53.280 am infoRe-added Unknown Zigbee Device
dev:5402020-04-30 08:23:53.234 am debugconfigure() called...
sys:12020-04-30 08:23:32.971 am infoInitializing Zigbee Device 90FD9FFFFE644F2F, BEFA
sys:12020-04-30 08:23:11.860 am infoZigbee Discovery Running

What Hubitat firmware version are you on? I'm guessing 2.2.0.x (if not, you might want to upgrade before trying again, unless you have a reason to be on 2.1.9.x or earlier). From the logs, it looks like Hubitat might be creating an "Unknown" Zigbee device, which (if you're on at least 2.2.0) will show up in your "Devices" list. This means you should also be able to go there, hit "Remove" for that device, and Hubitat will either send a command to the device to reset itself (as is done for healthy Zigbee devices getting removed) or at least remove the device from the Hubitat database (and then you can reset the lock yourself, which it sounds like you know how to do). That should give you a clean-ish slate to start from.

Beyond that, I'm not sure but have some typical guesses. If you haven't tried using new batteries in the lock, that would be worth a shot. If you don't have those or know your current ones are fine (I'd measure the voltage), maybe at least pulling power for a few seconds to "restart" the lock could help. Restarting Hubitat shouldn't be necessary but is unlikely to hurt if you only try it once (do it from Settings, not by pulling power; keeping a local database backup on hand is always a good idea).

For what it's worth, I have one of these and it paired easily, but that was several firmware versions ago (though I don't recall any Zigbee changes getting announced since then besides the fact that unknown Zigbee devices that are indeed paired to the hub's network will now have database entries created for them, so I can't imagine that making a difference). I'm not sure what a flashing green light would mean; Schlage's manual only says that it will flash yellow while in pairing mode, green (once) when complete, and red if there was a problem. :thinking:

1 Like

Not all Zigbee devices like all Zigbee channels. Most users have very good success using Zigbee channel 20. It may be worth a try to see if it helps the pairing process.

1 Like

Also, do you happen to have any Zigbee bulbs paired to your hub? Some bulbs can really screw up your Zigbee mesh.

1 Like

thank you for the reply!

I am on 2.2.0.125. This is a brand new lock, but I will change out the batteries just for the heck of it.
It is creating an entry in the device list, but it seems to not finish, since the device type is not filled in and I have to choose the Schlage lock. I have rebooted the hub, both by the gui, and by pulling the power. I called Schlage support, and he really could not answer why the lock was flashing green but he "thought" it was trying to initialize.

In HE Devices, the far right side shows what I thought was last communication, and for this device, it is blank.

I have a ton of bulbs... but I took the hub and it is placed right next to the lock...would that make a difference?

Zigbee is using channel 20 currently.

The bulbs are a likely culprit. What brand are they? How many do you have? The only truly safe Zigbee bulbs to have directly paired to Hubitat are Sengled bulbs, which are designed to not be Zigbee repeaters.

If possible, as a test, power off/unscrew all of the Zigbee bulbs and try pairing your lock again. Even with the hub near the lock, there is no guarantee that a Zigbee repeater is not involved in the pairing process.

2 Likes

that is easy, I will try that and report back... thank you for the info!

So it pairs as a "device". And you're choosing Schlage? That's incorrect - the Schlage driver is only for z-wave locks. Not zigbee locks.

You should pick the "Generic Zigbee Lock" driver and then hit configure on the device page.

Schlage's bizarre naming scheme is the source of this problem. The BE468 is a z-wave lock. As is the BE469. Hubitat's BE468/BE469 driver is for both of those z-wave locks.

Your lock is not a BE468. It is a BE468GBAK (which is Schlage's part number of the zigbee version of the BE468).

5 Likes

To add to the above, I wouldn't consider removing the smart bulbs during pairing a permanent solution. You just happen to have experienced early-on the problems they can cause with your Zigbee mesh as they interact with non-bulb devices. Not sure whether to consider you unlucky (that it happened so early) or lucky (that it did and you've already figured out the culprit instead of pulling you hair out later trying to figure out why some devices aren't working). This document is good reading, particularly the summary you can find near the end in the "Tips" section about bulbs: How to Build a Solid Zigbee Mesh - Hubitat Documentation

You can read there is why Sengleds were specifically mentioned above as OK (they don't repeat). Some people report that newer bulbs are likely OK here, but I don't know of anyone who's tested them with a packet-sniffer to see if they eat something they should be passing on (known problematic ones here include Cree, GE Link, Sylvania/Osram, and Hue, but likely many others). As stated there, if you want to keep the bulbs (alternatives include replacing them with something non-problematic or using a smart dimmer/switch instead), then keeping them on a separate Zigbee network from your other devices like your lock is a good idea. Some people use a second Hubitat for this; a Hue Bridge would also work (and works with all of the bulbs I mentioned above except Sengled--which don't have this issue anyway--and most Sylvania/Osram ones). Personally, almost all of my bulbs are on Hue, and the ones that aren't aren't Zigbee, except the one Sengled I have laying around that I don't use much. :slight_smile:

3 Likes

question regarding the configuration if I choose generic lock. delete code, set code etc?
What do I put in each of the fields on the configure page. It is not very clear there. Also, I ordered a smart things hub that I can use as a hub to control either the locks, or the old bulbs, but that sounds like a crappy solution and just adding complexity to the smart home.

Nothing for now. After you change drivers, just hit the configure button that is on that page. That's it.

Then test if you can control the lock from the device page (i.e. unlock/lock commands). If all that works, then install the lock code manager app to manage codes for that lock (if you so desire). You can also add/delete codes from the device page.

Finally, what brand bulbs do you have? Many of us put problematic zigbee devices on a separate Hubitat by themselves. No SmartThings involved .....

1 Like

OSRAM, Cree mostly

You could consider putting all your bulbs on a Hubitat by themselves. And then link your two Hubitats together using HubLink or HubConnect.

P.S. Does the lock now work?

1 Like

negative, I cancelled the smart things and ordered a second hubitat...all bulbs have either no power, or are unscrewed.

Lock is just not initializing.

There are multiple people here who can tell you horror stories for both. A second hub is a good idea (though honestly I still had bad luck with the Crees on one myself; they work great on Hue, and I sold my Osram so I didn't have to worry about it not working on a Hue Bridge). You'll have to use something like HubConnect or Hub Link/Link to Hub to "share" devices (and probably groups) from the bulb hub to your "main" hub or vice versa.

3 Likes

I replaced all of my Cree and GE Link bulbs with Sengled bulbs. Afterwards, all of my Zigbee issues disappeared.

2 Likes

its a learning experience. This begs the question though, do the same things happen on the Smart things hub? The bulbs have been working as expected for over a year. The hubitat runs the bulbs, and i have an Ambient weather station tied in, and a few zigbee contact sensors. I am just wondering if I may avoid a huge expense by just paying to get a new smart things hub and calling it done. If so, it is too bad, because I like the flexibility of hubitat, and am learning a ton with it....

I also have 4 sylvania bulbs too... so I am just screwed completely
https://www.amazon.com/gp/product/B07H918FN5/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

with the 2nd hubitat coming tomorrow, is the recommendation to move my contact sensors to the same hub as my lock, assuming it works, and then use the hubconnect to connect the two? I would assume that if one hub is using channel 20, the other one should not use channel 20.

A knowledgeable user here (srwrite) reported that SmartThings seems to have mostly overcome Zigbee bulb issues by doing some sort of rate-limiting on their Zigbee radio, which would presumably affect all devices and not just bulbs. (Bulbs, in my experience, do indeed seem to have issues with commands coming in too fast and missing some; I could see this fixing that when coming from the hub, but I'm not sure it could fix issues they may have with repeating messages from other devices.) In any case, Hubitat staff have indicated that they are not interested in doing anything like this on Hubitat.

If you're happy with the bulbs on ST, you could keep using them on ST instead of a second Hubitat if you wanted; HubConenct could still integrate them. But I enjoy lighting automations working correctly and not relying on the Internet, so that's why I keep mine local (Hubitat or Hue). :slight_smile: You could, of course, also just keep ST for everything and forget Hubitat, but I moved here because I value local execution and the speed and reliably that provides; your experience and requirements may vary.

If you "only" have two hubs, then yes, the point here would be to keep Zigbee bulbs on just one hub, then other Zigbee devices on the other hub. So if your lock and contact sensors are Zigbee, they'd need to be on the non-bulb hub. (Where you actually build the automations doesn't matter; HubConnect could bring those onto the "bulb hub" or the bulbs onto the "other hub.") Technically, Z-Wave and LAN devices wouldn't matter here, so you could put them wherever makes the most sense, though when I tried this I made the bulb hub Zigbee bulbs only and disabled Z-Wave (only wanted one Z-Wave network; they weren't the "problem devices").

Ideally, yes, you'd want the hubs on different channels. Zigbee is supposed to be good about not stepping on another network's toes (including other "noise" to it on that spectrum like Wi-Fi), but no need to make it harder than it needs to be.

Hope that helps!

Correct. I would try channel 15 for the other hub.

On the hub with your sensors and door lock, Youโ€™re probably going to need some decent Zigbee repeater devices to help build a string zigbee mesh network. Many use the IKEA Tradfri outlets, or Samsung/SmartThings outlets for this purpose. I use older Loweโ€™s Iris 3210-L outlets.