Absolutely right JD. This question is the number 1 question we get from users in many different forms.
I’ll outline the most common symptoms folks experience when using locks:
- My lock is 5ft from my hub
- I can see the lock/unlock events in the history but I don’t see the user code/name
- I can lock/unlock using my mobile app but my codes aren’t being programmed
- Some of my codes are being programmed while others aren’t
- My codes are being programmed but I’m not getting notifications/actions aren’t being executed when the codes are used
- It works in the mornings but not in the evenings
- It was working till recently and now it’s having trouble
- I moved my lock closer/next to my hub but I’m still having issues
- One of my locks is working perfectly, the other one (closer to the hub) is having trouble locking/unlocking/programming codes
- I’m not (or stopped) getting notifications/events when I lock/unlock my door with a user code
- I’m getting lock/unlock notifications but I’m not getting the user information
Folks often assume that because the hub is getting some notifications/events the mesh/hub are fine. Often the hub/mesh loses the subsequent event(s) if they come in quick succession which causes issues like I get the unlock/lock notification but it doesn’t tell me which user unlocked/locked the door. This is because a user lock/unlock action contains 2 events and a weak mesh will deliver the first message (lock/unlock) but lose the second message (user name/code).
Adding a beaming repeater (atleast 1; Z-Wave limits each message to a maximum of 5 hops, when there are more than 4 repeaters, the message will traverse only 4 repeaters, so make sure that you lock is no further than 4 repeaters away from the hub; the ideal recommendation is 2 hops), followed up a Z-Wave repair, resolves these issues.
NOTE: Some locks like Schlage Connect/BE469/IDLock have a firmware defect which causes loss of user details while notifying the hub. It is recommended to use this Universal Enhanced Z-Wave lock device handler which addresses this issue.
EXAMPLES OF REPEATER DEVICES
Plugin type repeaters which can be moved around and placed in any receptacle:
The Aeotec Smart Switch 6, Ministon Miniplug, GE Outdoor Switch, GE Enbrighten 55249 seem to do well with Locks as repeaters.
Hardwired in-wall repeaters, the Ultra Pro Z-Wave Plus 39348 Paddle Switch, GE Z-Wave Plus (avoid the older Z-Wave models) like GE 46201 Paddle Switch, GE 46203 Paddle Dimmer Switch, GE 14291 Paddle Switch or the GE 14292 Toggle Switches are excellent choices for creating buffered repeaters and work well with the newer Z-Wave Plus and older Z-Wave locks/devices.
Another very common misconception is that all devices are repeaters, often we hear, I have lots of Z-Wave devices near my lock, shouldn’t that work as a repeater:
- Battery operated devices do NOT act as repeaters
- Most AC/Mains powered Z-Wave Plus devices are beaming repeaters, in general you’re safe with a Z-Wave Plus mains powered device to act as beaming repeaters (except bulbs which don’t act as repeaters)
A hub alone doesn’t make for a good quality/reliable mesh and locks are beaming devices and often very slow to respond to messages (varies by brand). This puts an bigger load on hub/mesh and having repeaters makes a huge difference.
A general rule of thumb to troubleshoot when using locks:
- Add a repeater within about 10-20ft of the lock, if possible move the hub 70+ft from the lock so that the device connects to the (buffering) repeater instead of directly to the lock
- Change your lock battery, new batteries tend to perform better with programming locks. Some locks become unreliable with battery levels starting at 75%, see this topic for details
- Reboot/power cycle the hub
- Do a Z-Wave repair (if you have a Z-Wave lock)
- Reboot your router
Sometimes when things are running “slow” even with a repeater, it may have to do with the latency of the internet/mesh. Rebooting the hub and the router go a long way in improving the latency and subsequently you’ll also see a more “responsive” lock.
When there are a lot of Z-Wave devices in the mesh, that too can cause issues sometimes. The hub / mesh aren’t perfect and the mesh tends to degrade over time (from orphaned devices to routing issues). SmartThing, at one point, was looking to detect a degraded mesh and automatically do a Z-Wave repair. Until that feature is deployed it’s advisable to reboot the hub and do a Z-Wave repair when things begin to slow down or have trouble.
WHERE TO INSTALL REPEATER: Folks often put the hub and the repeater in the same room as the lock. This defeats the purpose of the repeater (holding messages until the lock is ready to receive them) because the lock will connect directly with to hub rather than through the repeater. So, it’s better to have the hub further away from the lock (40+ft), possibly in a different room, and the repeater close to the lock so that it forces the lock to connect through the repeater and take advantage of the buffering. Doing a Z-Wave repair after changing the positions of the hub and repeater should help fix the mesh configuration. Ideally exclude the lock and repeater, then pair the repeater first followed by the lock and finally do a Z-Wave repair to get optimal mesh routing.
CHECKING DEVICE ACTIVITY/EVENTS: In the new ST app when you open the device page you’ll see the device activity at the bottom of the page. If you don’t see the device events (e.g. an unlock event when the lock is unlocked) that’s a clear symptom that your mesh is having issues with message delivery.
VERIFING REPEATERS: After doing a Z-Wave repair, verify that your lock is routing through your buffering device/repeater. To do this, open the IDE → click on My Devices → Click on your lock. Scroll down and look for Route. It should look something like this This Device ↔ Repeater device ↔ Hub. If it is connected directly to your hub, you may need to move the hub further away and do a Z-Wave repair again. If it’s routing through a device you don’t want it to go through, you may need to exclude that device, do a Z-Wave repair and then re-pair the unwanted routing device. Note that changes to routes after a Z-Wave repair can take a few minutes to show up in the IDE. It should end up looking something like this:
IMPORTANT NOTES
- You have to pair the buffering repeater with the hub for it to work as a repeater for the mesh, unpaired devices do NOT buffer/repeat
- While it’s not always possible to force the device route through a repeater, it still helps to have the repeater in the mesh due to how z-wave meshes work with secondary/redundant pathways. The repeater will provide buffering, help improve the quality of the mesh and it’s reliability significantly.
- Some locks like Schlage connect, IDLock and certain Yale models have a bug in their firmware sending packets out of order which can cause loss of details in notifications (like missing names of who locked/unlocked the door). If you’re experiencing this issue, try this device handler which has a workaround for this specific issue: [EDGE] Universal Enhanced Z-Wave Lock Driver for Schlage, Yale, Kwikset, IDLock, Popp, Danalock, August Pro, Keywe, Philia, Samsung
- If you see a device called Unknown Device in your device Route, these are ghost devices and should be removed as they can cause communication problems with the z-wave mesh and interfere with lock operations.
- When a MAINS POWERED z-wave device (i.e. a zwave routing device) shows Failed to update during a Z-Wave repair it could be a sign of a bad device which may causing routing problems, loss of packets and other issues with the mesh. It would be advisable to factory reset and re-pair these devices to see if the problems go away. If not you may want to consider replacing these devices to avoid expected issues with other devices such as communication problems, devices going offline/online continuously
And on the topic of locks, here is a table which compares features across different lock models and also check out this write up on limitations of some locks.