FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?

This question comes up a lot. Suppose you have a Z wave lock, but the status doesn’t seem to update or commands don’t always seem to work. Typically someone in the community will recommend that you add another beaming repeater within 10 feet or so of the lock. So the question is why would you need that if the lock is already pretty close to the hub?

The short answer is that the hub is busy, and it takes some load off of it if you have a separate beaming repeater near your lock.

The long answer is in the following thread (this is a clickable link)

Also, since I get asked all the time what’s an inexpensive Zwave plus beaming repeater, for the US hub the Minoston miniplug is often on sale for right around $20. It should not require any custom code, it’s just a very simple one socket on/off plug, but it is a zwave plus beaming repeater. Note that it can only handle up to 10 A, though. There are other, better smart plugs that can handle up to 15 A, but they do cost more, so if all you want is something to make your Zwave lock work better, this is a possibility.


2021 Update

I was recently asked if I would make any changes to this recommendation now that it’s 2021, and the only thing I would add is that at this point you might want to get a device which also supports S2 security. Fortunately, the minoston I linked to above has been updated (MP21Z) and does also support S2 security. :sunglasses:

2023 Update

All series 700 and series 800 Z wave repeaters now support beaming, so pretty much any smart plug and most light switches and relays from these generations should work. Older series 300 and series 500 devices should still be checked to confirm that they do, as some models don’t.



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:

  1. 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
  2. I moved my lock closer/next to my hub but I’m still having issues
  3. One of my locks is working perfectly, the other one (closer to the hub) is having trouble locking/unlocking/programming codes
  4. I’m not (or stopped) getting notifications/events when I lock/unlock my door with a user code
  5. 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.


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:

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:


  • 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: [RELEASE] Universal Enhanced Z-Wave Lock Device Handler 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.

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.


@RBoy can you verify which of any of these MonoPrice plugs will serve as beaming repeaters for locks? I can’t get a clear answer on this from what I read. Model #s 11995, 15654, 27481

You can check the beaming status for most zwave products at the z wave alliance site. Just look on the conformance statement for the specific model.



1 Like

Here’s where the confusion happens. This is from a user question about the 15654. With this question on the 15654 it puts both of those others in question and at the same time I could not find the 11195 or the 27481 in the Z-Wave Plus database.

1 Like

I, personally, am having a bear of a time with my detached garage and I have a Z-Wave lock on it, which says it has my codes but when I try it, they do not work.

I have two Iris 3210 plugs in my backyard. One on the house, then another outside on the detached garage that I was hoping would serve as a great repeating network and that is about 4 feet from the lock. The Z-Wave light switch and locks give me grief. They work for a little bit and then…nothing. The garage door opener and Z-Wave open/close sensor work fine and I would think the Go Control Z-Wave garage door opener would be a great repeater for those devices since it is on mains and works like a champ…nope.

Getting ready to take the lock off my door and let it sit in the house for a little bit to see if it can finally get all the programming. I get no errors in the log as far as codes, but the alarm portion screams bloody murder every time the hub sends a change. I even tried a factory reset…that may have screwed things up for me. I have been trying to find out where @RBoy had a recommendation on that.

Hoping someone, eventually, will develop a repeater over Cat-5 or even Ethernet. Hell, at this point, I would take coax, two wire, carrier pigeon, anything for these detached buildings, which I am sure is a good market. I cannot stick another hub in there or I would. The environmentals are too extreme between heat and cold.

When I pair z-wave locks and physical switches I use a 50’ long piece of Cat 6 cable with the ST hub to get the hub as close as possible for pairing. That solved the issue where item either would not pair at all or only partially.

@JDRoberts is it enough for a zwave repeater to Support Z-wave Beaming or does a device also need to support AES Security if it’s going to repeat for a lock?2018-09-26%2011_34_59-Z-Wave%20Protocol%20Implementation%20Conformance%20Statement


Good call! Interested in finding that out…I may have two Iris outlets for sale, soon!

There are subtitle differences between each device and consequently how they will behave on the mesh.

The 11995 is a zwave device and conforms to the Routing Slave specifications and is based on the 4.54 development kit which supports Beaming. (Random Note: Beaming (FliRS) was supported starting 5.02 kit with the Series 200/300 chipset however the 4.5x kit was released after 5.x so it does support Beaming, however older kits such as 4.3 dont support Beaming).

The 15654 is a Zwave plus device conforming to an Enhanced 232 Slave (which is like a routing slave but can support a routing table of upto 231 devices vs 4 devices for a routing slave). It is based on the 6.51.07 kit and it supports Beaming.

The 27481 is a Zwave plus device conforming to an Enhnaced 232 Slave. It is based on the 6.51.08 kit and supports Beaming.

Having said that each implementation differs slightly based on how the developer implements it. So if Monoprice is saying that the 15654 doesn’t support Locks there may be something to it even through the device is certified as a Beaming repeater. We have also seen that the 15654 doesn’t work great with locks here in our labs. (Random Note: FliRS or beaming devices like Locks partially wake up between 4 times to once every second. The frequency depends on the lock developer. The beaming device needs to be able to match that frequency and hold / buffer messages until the lock is ready to receive them. ZigBee on the other hand doesnt have a FLIRS mode but a rather more complex timing mechanism it which makes it more expensive for Locks. Locks based on the latest 500 series zwave plus chipset if designed properly can last upto one year on a set of batteries)

The IRIS 3210-L plugs is an Enhanced 232 Routine Slave based on the 6.51.06 kit and supports beaming. However it is NOT suited to working with locks. The implementation of the zwave repeater functionality on this lock is very poor and does not work well even as a normal repeater. You can search the forum for the many issues reported by people. We weren’t able to get this device to work reliably in our labs. It is a good ZigBee repeater by the Zwave repeater functionality is impaired for some reason.

RECOMMENDATION: The Monoprice 11995 and 27481 seem to do well with Locks. We recommend the 11995/27481 if you have older ZWave Locks and the 27481 if you have newer zwave plus locks.

Hope this helps.


Not to hijack this thread but one quick question:

Since in my particular instances, I am dealing with outdoor repeaters between the two buildings, would something like the GE/Jasco Z-Wave Plus Outdoor Outlet or the Inovelli work with locks?

And people wonder why some folks pay big $$$ for Control 4 :slight_smile: Let someone else sort out this mess.


@RBoy Can we tell by looking at anything in Smartthings if a repeater is doing the repeating for a lock?

1 Like

might just need to turn hub 45 degrease especial if hub and device on on the same wall

Was going to respond to your PM but through about sharing this for the community’s benefit. Having to change the direction / height / location of the hub to get it to work is a classic sign of mesh trouble. These devices are supposed to have omni directional antennas but most aren’t effective, because of which you have dead spots and all kinds of signal reflection/isolation issues.
Another likely issue is if there are any wires running close by through could be causing interference issues with the hub.

It’s best to keep the hub away from corners and other wires/devices. Especially WiFi Routers and laptops with USB 3.0 ports.

The optimal solution is to blanket cover the area with repeaters to form a strong and even mesh.

Dose a repair get the optimum path from a strength or signal quality?

Strength is one aspect of signal quality. It’s a fairly complex algorithm that takes many factors into account.

I can certainly verify that there are indeed several factors that cause mesh issues. I’ve been having a problem with my Kwikset 912 periodically dropping off the network for a while now. It’s only 17 feet from the hub (I just measured it) and there are (5) Z Wave switches (all repeaters) between the hub and lock. There are many more Z-Wave switch/repeaters throughout the house. Nevertheless, the lock was dropping. Nothing else in the house. Just the lock.

About 2-3 months or so ago, I decided to replace the Z-Wave module in the lock. This reduced the lock dropping off the mesh, but it didn’t end it.

About a three weeks ago, I decided to move my hub 16" further away from my upstairs wireless access point. Previously, it was about 5" from the access point. Again, this helped but didn’t completely solve the issue, reducing the drops to once every 2-3 days or less.

About 10-14 days ago, I added a Z-Wave Plus fan controller on the opposite side of the house and ran a Z-Wave repair like always. The lock hasn’t dropped since then. So, Z-Wave mesh is certainly touchy - at least where locks are concerned.

It certainly would be beneficial to have some Z-Wave mapping tools!


I am having a horrific time trying to keep my August pro connected to my ST hub. It is paired but only works if I very recently opened the August app and controlled it through there. But 10-15 min later and the ST hub won’t control it at all. This problem started about 2 weeks ago. Prior to that, never had an issue.

I’ve followed the suggestions on this thread - bought and installed a beaming repeater next to the lock, repaired the zwave network, rebooted the hub, rebooted my Google wifi mesh network, even removed and reinstalled the August lock. Nothing seems to work. Any suggestions?

Since March they have made multiple unannounced changes to the Z wave platform in the cloud, and there have been many reports of strange Z wave problems. If you look in the announcements section of this forum for recent announcements you can see multiple reports there of zwave devices that had been working just fine and now are flaky, Particularly in the hub firmware update threads.

At this point, I think you may just have to contact SmartThings support and let them look at it from their side. It’s typically best to call in rather than use email. And you may have to get the problem escalated twice before you get to someone who really understands it.

Sorry I don’t have a better answer for you. :disappointed_relieved:

1 Like

hi is there any uk type repeaters ?