Schlage FE599 doesn't report locked/unlocked state after change

I have managed to get my locks into the system and am working my way through LCM and all the other little quirks involved. My main issue at the moment is the fact that the lock does not report a change in state for a LONG time. I understand that the battery will wear down if it reports in (surveys? polls? Still learning the terms) constantly but when changing lock states it is important to immediately know that the change has been made. On my dashboard I have a button for each lock. When the lock icon is pressed it does change the state of the lock but the button remains grayed out for a while then returns to its normal reflecting the current state of the lock (green and locked or gray and open like all of the Hubitat switches/buttons/icons). Is it possible to tell the lock to relay it's current state one time immediately after each change in lock state? If I go to the device page and hit refresh it accomplishes this goal. Can it be told to refresh after every change. This seems critical to me. Thanks for reading!

Randy, you managed to get a lot further than I did. I added the lock but it doesn't respond to any commands sent from the Devices page. I can't even get the current state to update.

Was there anything that you did differently (other than pairing it) to get this far?

Schlage locks are not on Hubitat's list of compatible devices:

https://docs.hubitat.com/index.php?title=List_of_Compatible_Devices

They aren't on that list because there multiple mesh and lock firmware dependent issues that sometimes prevent them from functioning properly with Hubitat as a z-wave controller.

That being said, here is a common workaround to get Hubitat to work stably with z-wave locks:

  1. Build a solid z-wave mesh as described in the Hubitat documentation.
  2. Make Aeotec Range Extenders the backbone of this mesh. If you get the Range Extender 7, place one of these very close to the Hubitat (within 2 feet), and two others strategically distributed in your house. I have the older Range Extender 6, and have 4 of them distributed around my relatively small house (and one right next to my z-wave Hubitat) - with no z-wave issues at all.
  3. Locks and garage door openers pair securely. This means they pair directly to the z-wave controller (and cannot pair via a z-wave repeater). Therefore, during pairing, your lock has to be very close to the Hubitat (within a few inches). There is a lot of data exchanged during secure pairing - the closer you are, the lower the likelihood of loss during transmission.

The hub was very close when I paired it (on the floor just below the lock being paired). After it was paired it showed up as a Schlage FE599/BE369 lock (see image attached). As I did not add any additional drivers I assumed that Hubitat was able to detect the lock type and had the drivers built in. With the hub still inches away from the lock I was still unable to obtain the current states from within the Hubitat app.

It appears that Randy was able to get the lock to function from his post. I'm attempting to determine if Randy had any additional steps (either before or after he paired the lock to the hub) that wasn't mentioned in the post.

That may not be not close enough. It literally has to be right next to the lock (think in terms of under 6 inches). I would recommend excluding the lock and pairing it again.

I had a Schlage FE599 working with Hubitat until a few months ago. So I know they do work - if paired closely, and then used on a mesh with Aeotec Range extenders.

I will attempt re-pairing the lock with it right next to the lock.

I'm not quite certain why the hub needs to be this close, and why range extenders are required. I didn't have this issue either pairing or operating the lock when connected to Wink. (I use this comparison as it's the only other hub that I used prior to the Hubutat).
I know that Hubitat offers way more control over my home automation, but I didn't expect it to be this problematic with the hardware.

It isn't. Many other hubs have workarounds for problematic hardware - Wink in particular worked with Schlage (and other specific manufacturers) to get around device-specific firmware issues. OTOH, WInk worked with very limited hardware. For example, Wink doesn't support lock code management on any lock outside of Schlage z-wave locks. And even with Schlage, not the newer zwave+ locks.

Hubitat doesn't cripple its hardware by creating fixes for manufacturer specific firmware issues. So it works with a broader set of devices, but it is essential to consult the device compatibility list.

In this case I had the hardware prior to migrating from Wink to Hubitat. I knew that the door lock wasn't on the hardware list, but there are several posts by community members that have got it to work. I'm just trying to ascertain the step/s that I'm missing, or what I'm doing differently.

I agree that the functionality wasn't there with Wink, not just for the lock but with a lot of other devices. The usability, and the ease of setup of devices is far superior on Wink. The ability to create complex rules is what made me choose the Hubitat over Smartthings when migrating over the sinking ship that is Wink. I was hoping for a more seamless process of getting up and running, so that I can handle the headaches of automation at a later stage.

Me either, but I completely agree with @aaiyar. I had to bring my hub with in 2 feet to pair my lock. I will also say I had zero issues with these locks in ST, other ST outages, or with Vera before that. But the past does not matter we can only change the future.

Have you tried Reliable Locks by @jwetzel1492?

I use it as well as Device Watchdog by @bptworld. with a few rules to check/refresh my Yale and Schlage lock (not the same model but I have issues as well). I have a solid mesh and 0 problems with any other devices. I have added repeaters and lots of things to fix these locks. In the end my cocktail of RL, DW, and a few customized rules have made my locks functional and reliable.

While I submit adding 3rd party apps and additional rules to the hub to make these lock work is sub-optimal. Until functional correct without them, or I feel like investing more time and money into replacing them (why not just buy other HA stuff?), my workaround has them 'fixed' them.

1 Like

I had the same problem. The device would lock/unlock from command either by dashboard or device page, but if manually locked/unlocked, the status would not update. I simply changed the driver to "generic z-wave device' and it started working instantly!

1 Like

Back Door Lock
(Schlage FE599/BE369 Lock)
Generic Z-Wave Lock

Back Door Lock was manually locked [physical] DEVICE physical
Back Door Lock was unlocked via command [digital] DEVICE digital
Back Door Lock was locked via command [digital] DEVICE digital
Back Door Lock was manually unlocked [physical] DEVICE physical

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