From what I understand you have multiple locks setup with multiple hubs/mesh’s.
There is one lock that’s responding with an intermittent programming failure, it is close to the hub but it doesn’t have a repeater, while the locks with repeaters in their mesh are working fine.
Z-Wave networks are mesh network and the reliability/strength of the mesh is created with repeaters in the mesh. Without a repeater (e.g. just a hub) it doesn’t create a mesh which can lead to intermittent failures due to lost commands (the ST hub is not a reliable message buffering device, which is highly recommended when using a z-wave beaming device such as a lock). The Schlage BE 468/469 models are particularly susceptible to a weak mesh/buffering issues.
This is a common setup issue and we always recommend having atleast one repeater on the mesh preferably within about 20ft from the lock. This is because locks need a buffered network to hold messages until they wake up to accept them. I’ll add this to the FAQ’s as well.
A Z-Wave repeater are most mains powered Z-Wave Plus devices. See this post for a list of recommended buffering/beaming repeaters which support locks. We recommend using a plug rather than a in-wall switch simply because it allows you the flexibility to place it at an appropriate location between the lock and hub.
After adding a z-wave repeater please do a z-wave repair on your hub so that the mesh is optimized. If you have any issue with your lock after adding a repeater please feel free to each back out to me.
Here are some popular choices for locks
- Yale (YRD256, YRD240, YRD226, YRD216, YRD220, YRD210, YRL256, YRL226, YRL220, YRL216, B1L, T1L)
- Schlage (FE469, BE469, FE599, JFE109)
- Kwikset (Obsidian, 916, 914, 620)
- Samsung SHP/SHS locks
Special considerations
These locks have a known issue with the firmware where they don’t accept reprogramming codes which are already programmed. This can be an issue when there is packet loss in the mesh, if RLA asks the lock to program a code but the programming confirmation message is lost in the mesh, RLA will continue to try to reprogram the code until it receives a confirmation. However since these locks do not accept reprogramming existing codes, they will not respond to the request. A typical symptom of this issue would be that the code works however it’s shows up as a failed programming request.
These z-wave locks have a known firmware defect which makes them susceptible to mesh packet loss (especially at low battery levels) causing a loss of lock/unlock notifications or names of users. The loss of notifications for these locks can be reduced by using the Enhanced Z-Wave Lock device handler and a good beaming repeater.
- Schlage FE599
- Yale Keyless
- IDLock 150
These locks do not report which user unlocked the lock. Consequently RLA cannot execute per user actions nor will it be able to record the usage history for guests.
- Ultraloq (U-Bolt, U-Bolt Pro)
Locks to avoid when using automatic code generation
It is advisable to use locks that have a full keypad. Avoid locks with a limited keypads that share buttons for digits, such as the Kwikset 888/910/912.
This is due to an inherent design flaw in these locks, if two codes share the same key button in the same order, e.g. 1234 and 2134, it cannot tell the difference. Consequently the lock will reject codes which share the same order of the key buttons. To put it in context, a 10 button keypad can generate 10,000 unique 4 digit codes, a 5 button keypad can only generate 625 unique 4 digit codes.
Since RLA generates codes automatically based on user/reservation information it is advisable to use locks that have a full keypad to avoid running into this issue.
Avoid Kwikset 888/910/912 and similar limited keypad locks
Alfred (DB1-C-BL, DB1-B-BL) locks do not allow sequential and repeated user codes (eg: 1111, 1234)
Comparison of Lock Features
Here is a write up comparing the features of different lock brands (they vary by model but it’s a good place to start).