Schlage lock problems

🛎️ Get Help Devices
82

This is VERY important that people don't fully grasp. The market is flooded with cheap devices with a label but no proper certification. Locks REQUIRE end points that PROPERLY support BEAMING. Z-Wave Plus devices support this IF implemented correctly which unfortunately not all of them are implemented correctly.

If you're having problems with locks it's most likely a repeater problem and the repeater NOT supporting beaming properly. This becomes a REAL mess when you have dozens...hundreds of CHEAP devices deployed with questionable implementations. Why pay for the expensive outlet, switch, plug when there's a cheaper one??? This is why.

1 Like
83

I upgraded to ZP locks about a month ago. Also used two ZP plugs for repeaters - one near the hub one near my lock that was the 40 ft from the hub. All working great.

I got Schlage to take my old z-wave locks back. It was a major hassle to deal with them but persistence paid off.

4 Likes
84

Including WiFi I have 8 2.4g radios running and 120 zigbee devices at this point

Okay, I pulled 5 out of my tail--it's likely greater than 8, and if they are all yours you can prevent overlap. When I look for wifi channels in my urban neighborhood I see more than 36. There are more than 9 each on 1, 6, and 11 and at least 2-3 on the overlap channels in between. A friend of mine who lives in an apartment building sees more than 70. Neither one of us can get Zigbee to work for crap--that's not just Hubitat, that's been across Wink, Iris, Abode, Hubitat. I have no zigbee more than 15 feet from my hub, and even then I've several times lost access to them until I changed my Zigbee channels.

don't know what to tell you...

Well, that is exactly my problem with your promotion of Zigbee -- you @mike.maxwell claim it's awesome but you don't know what to tell me when it's not. When I lost access to my front gardenspots, I reached out to your staff to determine what debugging features you had, what you recommended for determining the failure--anything. Since I had heard you repeatedly praise Zigbee and tout it's value, I figured Hubitat would have some tools or experience debugging it. Nope, I got nothing but shrugs from Hubitat support. No debugging, no idea how to determine the failure, try moving it or rebooting it, that's it.

So same as last time, I borrowed a pro scanner from work and did a walk through to find the least worst pollution channel and adjusted it.

I haven't found any scanners you can run on your phone or tablet to be useful for this. I'm privileged to work with wifi professionals who can lend me those tools. That's not a reasonable expectation of most homeowners, and these tools aren't cheap.

I'm not saying you're wrong, perhaps Zigbee is the best thing since buttered bread. But based on my experience and that of other people I know who live in urban environments, it's finicky, tempermental, and there's no way to debug it without tools costing several thousand dollars.

If we're configuring it wrong somehow, if Hubitat does have tools for debugging Zigbee to help us out when it's not working--then please educate us.

(this probably needs its own thread)

85

No dispute on product flaws, and I don't doubt there are problems-- but where are you seeing "widely reported" ?

On every other hub channel Schlage are promoted as the best by the general populace. Ask in Wink, Hubitat, look in the old Iris channels-- everyone tells you to get Schlage. So I'm just not seeing this "widely reported" problems...?

Again, not saying there aren't problems. But I'm having trouble reconciling this claim with what I've seen over the last 3 years.

86

FWIW I had this problem back when I was using them with Wink. What cleared it up was finding the relay device in between the relays and the hub which didn't support beaming. Having a relay near the lock which does support it doesn't help, if it's choosing a path back that goes through a unit which doesn't.

YMMV but as soon as I found and removed the bad relay, it worked instantly and perfectly. With the same Z-wave devices in place I've gone through Iris and Abode to HE without any problems that weren't caused by hub malfunction/upgrades that broke Z-wave in general.

1 Like
87

Concur with those who believe that the HE z-wave radio is behind this. I've actually had good luck with the very prescriptive Aeotec Range Extender deployment required for HE C5, but my August Z-wave locks didn't need any of that when I had a ST hub where my C5 hub is now located. I'll be watching the C7 discussion threads closely...

Interestingly, I also found that making sure the batteries were fresh when adding my locks made a big difference with their discovered capabilities. It was only after I put fresh batteries in all 3 of my August locks that their ability to report lock and door ajar state was discovered.

88

This is NOT a radio issue. Zwave is a MESH network. It may be possible for a platform to compromise how it broadcasts messages to overcome bad devices. That may have been prudent when devices and the platforms were new and the manufacturers were willing to work to find solutions. This is today and the HE platform does not use the cloud to offload processing to enable time for any extra shouting to get deficient devices to respond.

2 Likes
89

Being a mesh network is irrelevant A mesh is not needed to control a single device it is only needed when you have many devices or need to reach far distances

Zwave is ALSO a device controller. And if the reported device is the ONLY device on the controller and the device does not work at very short distances but DOES work at even greater distances with other "local" controllers also being the only device on the other platform, then there is only ONE variable that changes and it's not the mesh or cloud.

90

If you only have one device then it is a mesh issue. The hub broadcasts its message and then goes on about its business. The hub is not there to babysit devices. You need additional devices on a Zwave network, especially with battery operated devices.

91

Other platforms prove this as false

92

It doesn't matter what other platforms have done. Read my previous post.

93

Read the documentation provided by every single zwave device. NOWHERE will you find that it states that it is "required" for you to have other devices for this device to function on zwave.

94

That's not how Z-Wave works.

The controller only uses broadcast messages for "scene" control which requires associations to be setup and then you are limited to the distance between the controller and the end point devices because these broadcasts DO NOT route. A Scene controller can be a gateway controller or a stand alone scene controller (ie wall pad).

Standard Z-Wave messages are all direct route messages from the gateway to the end point. The message contains the route information (path) defined from the controller to the end point and that message is sent on it's way. If the route is not direct then the node receiving the message has the next hop info inside the Z-Wave message and it sends the message to the next hop or to the end-point device.

Z-Wave also requires an Ack for each message (when implemented correctly) to ensure delivery and response for each message. The response will take the same return route as it was delivered on.

95

I should not have used the word broadcast. Locks are not the same as a powered device and may not be available for a message when sent.

96

Locks also don't have in their documentation that other devices are "required" for them to work on zwave.

97

I haven't read the the Zwave documentation in a long while but have a look at the HE documentation How to Build a Solid Z-Wave Mesh - Hubitat Documentation

I am currently using a BE469. It is on firmware 6.8 and it seems to be working well.

98

That is correct. Locks are FLIRS devices which wake up every other second to receive messages. It is required to have Beaming capable repeaters on the network to effectively communicate with FLIRS devices. If you have no Beaming repeaters that are talking to the Lock then you will have VERY bad experiences.

That will be half-working sometimes it does sometimes it doesn't work. This is because of the message route taken. Especially with everyone constantly doing network heals that can/does change the routes. Also a problem is people don't generally know about FLIRS and Beaming requirements so there's this "any repeater" works thought and it doesn't.

On paper all Z-Wave Plus devices are "supposed" to support Beaming. This however is not always the case because not ALL Z-Wave Plus devices are properly certified or even certified at all for that matter they just have a label/sticker/print on the device and are fake. To be sure everyone should always lookup the devices they want to use and verify them in the Z-Wave product database and LOOK AT the Z-Wave Protocol Implementation Conformance Statement to verify if they claim Beaming or not.

2 Likes
99

"That" documentation is relevant to having a successful "many device" system. That documentation doesn't have anything to do with one (and only) device operating. The hub/zwave itself is designed to be a endpoint controller.

And after many many months of tracing down this issue on this platform, I have determined that if your hub is close to the lock many will never experience issues.

The easy way to find this out is for those that experience this problem, don't add a single repeater. Just move the hub within a few feet from the hub and leave it there for a few days, therefore all other variables are the exact same. What I have found that 99% of the time the issue goes away. Move the HUB back, and the problem returns regardless of the "beaming" repeaters you have on your network, OR (like my testing) having it as the ONLY device on the hub.

100

It's perfectly fine to have only single devices or if you have a strong radio signal and have direct route to devices then repeaters are not needed. I do this in testing devices all the time where I only have one device in the controller (including locks) and I have no issues because it's a direct route and within range.

I have a couple of controllers that have amazing range and have direct routes to nearly all of my devices. In this case I can add repeaters which is the common solution or I can add another controller.

2 Likes
101

My "assumption" is the main issue here is that when the hub transmits directly everything is fine. However I believe something is lost (with this hubs radio) in the transmission from the hub to a beaming repeater to the lock, which continues the issues even with the repeaters. As I have 3 locks and 5 dedicated beaming repeaters within 30 feet in either direction of the hub.

After adding the repeaters the problems went away, but only for a few days, then back to the same. I move the hub within 5 feet of the lock and the problem has been gone for 3 months now and not once returned.