I'll grab one and give it a shot.
Given that I have beaming GE Z-Wave Plus dimmers within 12 inches of each lock, would the suggestion be to put the repeater near the hub? Assuming then that the hub will relay to the repeater which can then repeat until commanded to the locks via each beaming device?
Yes, certainly that's where I would start. The advantage of the plug in (wall wart) repeaters is they can be moved to find an optimal location. ME.. I'd use it to find the place I could install an In-Wall device to eliminate the ugly wall wart. 
Just last weekend I got a Zigbee In-Wall dimmer to replace a ZWave JUST so I could remove a zigbee wall wart. It worked and my Zwave is unaffected -- so success for me.
I had a similar issue with my August lock. Commands were super delayed and the lock would just fall off the network after a while. Added a beaming repeater (I used a Monoprice Z-wave plug) right near my August Z-Wave lock (repeater facing the lock) and now everything has been super stable for weeks!
The problem for those of us without 'RF Goggles' is, we can't see the mesh the way the Hub sees it.
The Mesh, that is the Hub and all repeating devices, want to make the mesh as physically large as possible. This has the practical effect of sometimes the hub picks a distant repeater, skipping right past the one we put 'in the middle' to fix the mesh. Then the mesh turns right around and connects our Lock to that distant repeater.. that doesn't support beaming, completely bypassing this top of the line repeater there in the middle.
Bottom line, you can't predict which device location is going to be ideal. When I first bought my Yale ZWave lock, it was a year after the rest of the mesh had been built. On that day, the Yale paired with SmartThings right away and worked fine.
Then I migrated to Hubitat and I wanted to get it done quick.. The mesh hadn't built well because of rushing and the room-by-room nature of pairing. The Yale did not securely connect and neither did my Garage Door Opener. But after getting everything else around them migrated and coming back to the Lock and GDO last, it worked as if by magic.
I mostly did my locks last. The funny thing is, they all securely paired the first time around, without having to move the hub around.
I thought some of the people on here were crazy having to hold the hub 3" away from the locks to get a securejoin. I had zero of those issues.
Little did I know 
I've heard people around work talk about "the blue bag" of troubles vs "the green bag" of troubles. Neither 'bag' has the exact same troubles, but the quantity and quality of the trouble is the same. Each of us seems to have our own story about which device or devices were the worst... and my list matches almost no one else.
I ordered a repeater as well as swapped out the switch next to my front door which I thought was zw plus but was just zw.
I also excluded and readded the lock in case that helps the mesh, since I know battery devices won't wake up for a repair
I will add the repeater next week when it comes (placing it close to the hub itself) and run a repair again and wait a few hours for those devices to wake up and find new neighbors.
Just a note for the developers/engineers/whoever
I literally cannot even run a z-wave repair when any kind of polling is enabled. Whether it is the built in poller app, or using RM to create a scheduled poll. Right now I am polling just five devices at a 15 second interval.
I started the repair 11 minutes ago and it's barely through 4 nodes. If I stop polling, it flies through.
There has to be some kind of bug/glitch/something when polling and overall z-wave stability.
Curious, how many zwave devices total do you have?
18 zw/zw plus devices. Mostly dimmers/switches (all non-secure) + 4 secure devices (3 locks, one garage opener)
About the same number of ZigBee. Small house as well, 1500sqft, mostly configured like a big open box.
As mentioned, right now 5 of the installed switches are the older zwave jasco type that do not self poll, hence the need for polling.
In the scheme of things, this is a small deployment.
From your explanation of how long your zwave repairs are taking, I would tend to think your zwave mesh has some problems with it ( it may be because of the older ge/jasco devices I don't have any so can't verify) It will probably eventually clear itself up but may take some time.
(Because of the "Locks issue") I have personally rebuilt and reset my zwave network back to build from scratch at least 3 times trying to fix solve this issue. I have noticed on one of those at least 3 times my zwave repairs followed the same motto as you are having when I tried to do the all secure zwave route and pair the aeotecs securely, I also noticed this just suddenly began doing that after I removed then readded a device that seem to be a repeater that alot of devices "were" routing through, then had to completely rebuild the mesh again, the zwave repairs never seemed to run as smoothly as they did prior.
Long story short, after rebuilding from scratch this last time, I followed a specific process when building the zwave network/mesh and has seemed to work great every since. I have 34 zwave devices. 21 of those are repeating devices all zwave plus (4 aeotecs) and of the 13 battery devices 3 are locks.
My current zwave repairs for those 21 repeating devices I ran one last night took a total of 9 minutes. I ran one when I began typing this and completed in 14 minutes. Chatting devices can slow it down, but usually not as much as you're experiencing.
If you ever decide to reset your zwave radio and start from scratch (After you get the Aeotecs)
Pair in this order for best results
And yes you "might" just need one Aeotec, I started with one and noticed "improvements" but wasn't "fixed" and continued buying one at a time until the problem was completely fixed.....I probably could have lived with 3 but still had a random drop off, which I do not with 4. One of my locks is also outside over 50 ft away on a metal building.
It repairs in under a minute or two when polling is not taking place. (last repair just under 3 minutes total, all devices, no errors)
It's only when polling that all z-wave activities are slowed to a crawl.
Sorry if that wasn't clearer from the last post.
My zwave mesh repairs in about 5-10 minutes without polling enabled. It took overnight with polling enabled
So I agree with your observations about the zwave poller app.
Thanks. Other confirmations that polling has this effect.
Can any @staff take a look at this thread and let me know if we can resume my troubleshooting ticket to understand more about this issue. My ticket number is 13929
To be honest and practical right now you have two imediate choices.
1 replace your older non plus devices
2 disable polling prior to running a repair.
I would go for the latter, you know when you're going to run a repair, and it's simple to disable the polling app...
@mike.maxwell - to be more clear, the immediate issue isn’t polling while repairing the mesh. I can understand why those two may be impossible to run together.
The issue is the total lack of zwave performance when polling is running. Lights seem to work well enough, but locks are nearly unpredictable when polling is on.
If i stop polling, lock responsiveness improves 10x, though maybe not perfect.
I’ll be working with @bobbyD tomorrow AM, perhaps we can review further. He’s investigating some details of my network.
Just an update here, I begrudgingly added a couple Aeotec zwave plus repeaters (one near the hub, one near my lock) and things are much improved.
I'm still not loving the fact that it's required, but I am happy that things are working well. I added some noisier devices back to the network (mimolite garage controller, Aeon HEM Laundry Driver) and stability is still there.
I also noticed my routines run much faster when doing multiple secure commands, like locking all doors and closing the garage.
You will find out your overall zwave network will be much more responsive and reliable after a few weeks of having the Aeotecs included in your mesh...
I swore I would never by these as they are single purpose devices but I'm actually glad I did as even other platforms that may not "need" them I can definitely see the mesh improvements.
You and me both. I was 100% sure that buying them would be a total waste. And I was 100% wrong.
I know this is an old thread, but I can't help taking a jab at ST here!
I'm sure you meant to say "100% local processing or 50% device reliability" considering the (un)reliability of the ST cloud, and it gets worse by the day. What's the point of making sure your hub can talk to your devices if you can't control them each time the wind blows and the cloud shifts. LOL!
My hubitat hub is mounted up high away from obstructions, and centrally to my 3-floor, 3,500+ Sq, Ft, home, I have lots of in-wall z-wave switches which act as repeaters so I don't really have any connectivity/signal issues and no need to add dedicated signal repeaters. The few non-plus z-wave devices I have work mostly fine, I have noticed a few issues with a couple of them not reporting status reliably and enabled polling (total of 4 devices out of 50+) and they are pretty reliably showing the correct status now, just sometimes slightly delayed, and doesn't seem to cause any problems with delays.
Overall, the speed, reliability, and performance of my Hubitat hub blows ST out of the water. The whole design/ecosystem of ST is horrid - but at least it's a "big name" and popular enough for people to build apps and drivers for which can easily be ported to work with Hubitat, so I can't complain too much. I just hope they get their shiz together soon before too many people abandon their platform for it to be cost effective to continue running it. Or, if that happens, I hope people finally see the light and switch to Hubitat so the community development for this platform will increase!!
Just my $0.02 worth...
Download the Hubitat app
