Adding to this, a note about lightbulbs and doorlocks…
-
Most zigbee light link devices, including Phillips Hue bulbs, GE link bulbs, Cree Connectedly bulbs, and Yee Sunflower bulbs can only act as repeaters for other ZLL devices on their own mini network. Not for other zigbee devices. (edited to add: @Savij reports below that the Osram Lightify bulbs do act as ZHA repeaters also.)
-
Many zwave lightbulbs, although not all, will in contrast act as repeaters for any nonbeaming zwave devices as long as they are powered on. This can be useful if you need a ceiling mount zwave repeater.
-
zwave doorlocks use a special protocol called “beaming.” Only other zwave devices that support beaming can pass messages on to them. To determine if a device supports beaming, see its official “conformance statement” on the Z-wave Alliance website.
The following topic explains more about exactly which devices can repeat for which. This is a clickable link.
I know the osram bulbs will act as routers(repeaters) for whatever zigbee network they are joined to. I think the ge bulbs will too.
Check again: they will likely act as repeaters for whatever ZLL network they are joined to, but not for any nearby ZHA devices. So they will repeat for the other bulbs, but not, say, a nearby zigbee sensor. I know that’s true for GE and Hue. If Osram is different, let us know.
I checked my osram bulb and it will extend the network and act as a zigbee router for all zigbee devices as long as they are connected directly to the ST hub.
Excellent, thanks for checking!
@pstuart says GE has confirmed that their bulbs do not repeat for ZHA devices.
HEALING THE NETWORK TO GET ALL ROUTING TABLES UP TO DATE: ZWAVE REPAIR UTILITY
And here a little more detail on running a Zwave repair, since the blog article above just mentions it in passing. If after reading the information above you decide you want to add a repeater to your network, or if you just suspect that your routing tables may not match your real physical configuration, you can “heal” the network to improve overall efficiency after you’ve added any new devices.
Z-wave repair (also called “healing” the network) is a utility that will force every zwave node on your network to rebuild its routing table. This can rescue “orphan” nodes who are confused about who their nearest neighbors are and consequently have a difficult time getting or receiving messages.
ZIGBEE HEAL: UNPLUG AND PLAY 
For zigbee, healing the networks occurs automatically whenever the hub is powered off for about 15 minutes or more. It may take an hour or two before the routing tables rebuild completely, but you don’t have to do anything other than unplug the hub, wait at least 15 minutes, and then plug it back in.
ZWAVE HEAL: RUN THE ZWAVE REPAIR UTILITY
For zwave, though, you have to use the Repair utility. This is available through the IDE. You will see a message in the log that the repair is complete, but that’s just at the hub, like zigbee it may take an hour or two before all the nodes have rebuilt their tables as well.
REAL LIFE::: RUN A ZWAVE REPAIR 3 TIMES TO CATCH ALL SLEEPING NODES
Most field techs will actually run the zwave repair three times in a row. This allows each hop of the network to be rebuilt.
So for maximum benefit:
-
unplug the hub for at least 15 minutes. Then plug it back in.
-
run the zwave repair utility. When you see the message in the logs that the repair is complete, wait another 15 minutes (don’t unplug the hub this time, though), then do a second zwave repair.
-
again when you see the log message that the repair is complete, wait 15 minutes with the hub still plugged in, then do a third zwave repair.
The wait and repeat also improves the odds of catching all nodes, including ones that were asleep during the first pass.
So easy, but a little tedious. You should expect to see improved response rates within a few hours if node address tables were contributing to the problem.
- A FOOTNOTE ABOUT “BENCH INSTALLS”
if you pair new devices to your hub by always bringing them to the hub, they’ll join the network but they won’t know who their real neighbors are once they’re in their true locations.
If you only have a few devices and they’re all close to the hub anyway, it won’t matter. but as you start to add more devices or they get further away, your messages will take “hops” to travel across the network, going from neighbor to neighbor.
The problem is if they were all paired right next to the hub, they’ll try to send their messages through neighbors that were close to the hub when they were paired, which may now be out of range.
So doing a bench install is fine, but it’s generally a good idea to then heal the network after everything is in their final location just to make sure each node knows its true neighbors.
I am curious how you were able to check this. Software??
The community-created wiki, things that are smart, includes an article on repeaters that lists specific repeater models that may be of use for specific use cases:
Looks like Christmas lights can be added to the list of things that can interfere with Zigbee.
One more thought. While I understand the marketing reasons for the decision, the fact that SmartThings gives customers zero guidance on how to set up a network backbone does lead to a lot of frustration that shouldn’t have to exist. if people knew that
.1) The hub should be located centrally in the home, both vertically and horizontally. Don’t put it in a garage or basement as those have concrete and pipes and metal objects which will reduce signal. If your Internet router is off in some inaccessible corner, you can use a Wi-Fi access point that has a ethernet port on the side and plug into that. Also, the hub should not be put in a cabinet. You just want to make it as easy as possible for signal to spread around your house.
.2) they need one device that can repeat about every 40 feet (every 60 feet for Z wave plus).
.3) zigbee repeats only for zigbee and zwave repeats only for Z wave. The repeaters form the “backbone” of the network. So there will be one backbone for zigbee and one backbone for zwave. When installing several devices at once, install the repeaters first, beginning closest to the hub and working outward, so that the other devices will be able to use them to reach the hub. Then go back and install the battery powered devices. Using this method, zwave plus Devices should be able to be paired in place.
Some Z wave classic devices may need to be moved close to the hub to pair, and then moved to their desired location (or you can move the hub close to the device, or you can use a minimote to do the inclusion). Z wave locks will need to be paired very close to the hub so that they can exchange an encryption key.
.4) battery powered devices do not usually repeat, but most mains-powered devices do including plug-in modules, light switches, in wall relays, and plug in sensors
.5) Z wave plus has the longest range per device of the Z wave/Zigbee options
.6) The hue bridge forms its own mini network and none of the devices connected to it will repeat for any of your other devices
.7) wi-Fi is irrelevant to the performance of zigbee/Z wave devices except that very strong Wi-Fi can drown out nearby ZIgbee. For this reason, locate your SmartThings hub at least 3 m from your Wi-Fi router and any Wi-Fi access point.
.8) Different architectural features can make it harder or easier for signal to get through, effectively making the range shorter. For example, foil backed insulation inside a wall might make it hard to get signal through to the next room. Signal might pass easily from one side to the other when a garage is empty, but be blocked by cars when the garage is full. These kinds of obstacles may require an additional repeater or changing the placement of devices.
.9) Z wave is limited to four total hops per message between the end device and the hub, zigbee allows for 15.
A zwave network is limited to 232 Devices, including the hub. A zigbee network can support many more. so you will theoretically be able to add up to 231 Zwave devices to your SmartThings account at one location, although you may start to encounter some issues if you go over 40, it just varies.
However, as of this writing the smartthings hub can only handle 32 non-repeating zigbee devices connected directly to it. These are most commonly battery operated sensors or the Sengled brand lightbulbs. If you try to connect more than 32 non-repeating zigbee devices directly to the hub, some of them will just drop off the network.
The good news is that every time you add an additional zigbee repeater, it can “parent” some of the non-repeating devices, leaving more slots for the hub again. The number that each new repeater could take varies by brand/model, but is typically 3 to 7.
.10) each end Device keeps a list of its closest neighbors. Anytime you add a new device to the network or physically relocate a device, you should run the Z wave repair utility for Z wave devices or do a zigbee heal for zigbee devices to make sure that all the neighbor tables are up-to-date.
To do a zigbee heal, take the hub off power (including removing the batteries) and leave it off for at least 20 minutes. When you put the hub back on power, all the individuals zigbee devices will automatically update their neighbor tables.
To do a Z wave repair, follow these instructions:
This process can take a while for both Z wave and zigbee, so you may not see efficiency improvements until the next day.
People would then know 95% of what they need to know to set up an efficient mesh network. One line in the hub user manual “go online for information on how to set up the most efficient communication network for your home automation devices” and a one page web explantation of those ten points and you’d save a lot of support calls.
Professionally installed systems, even Xfinity home, obviously don’t have to do that. Their installers will deal with those issues.
But I do think it makes sense to provide the backbone planning information for a DIY system.
JMO 
Do we know if the Zigbee and Z-wave antenae orientations are still the same as the illustration in that blog post? It looks like an older hub.
On point as always, JD. Thanks!
Question on fail over if a repeating node fails.
For zwave, if a repeater fails, battery powered endpoints seem to find the next repeater on their own.
For zigbee, if a repeater fails, the battery powered endpoint cant seem to find another.
What is the expected functionality?
If a battery powered device (zigbee in this case) is mobile, and goes in and out of range between 2 repeaters, will it be able to jump back and forth? Will zwave?
What you just described in the moment, although over time it’s different… Zigbee battery powered devices select a “parent“ when they join and that’s the device that they expect to be the first repeater. They should also be able to reach the hub if it’s one hop. But if the parent dies and they are on the edge of the network, they can get “orphaned.” The hub is supposed to notice that the orphan has not checked in for a while and then there are a couple of different things that can happen which will either rebuild the network by giving the child to a new parent, or if a new parent is not available, Mark the child as unavailable. How quickly all of this happens depends on the zigbee profile being used and some individual manufacturer settings. On the other hand, if you just take the hub itself off of power and leave it off for 15 or 20 minutes, then all the devices will basically remap themselves when the hub comes back online and that cleans up anything involving defective devices as long as another parent is available. So most commercial installations will force a network heal once a week or so. All of which means that eventually, the child device will probably find a new parent unless there just isn’t one available in which case the hub should know that.
Z wave, however, has two different mechanisms for providing alternate routes more quickly. First of all, most devices are aware of a couple of alternate routes to begin with. Second, through “explorer frames” zwave plus devices and some of the older generation can eventually rebuild paths around failing devices, although it can take a couple of days. You can also issue a “repair“ utility command to force the network to rebuild. A lot of zwave only platforms do a repair every night to keep things clean, but smart things has always recommended against that because they have additional synchronization issues due to the cloud.
So in practice if you are using smartthings a zwave end device probably has a better Chance of finding an immediate alternate path. Zigbee may require power cycling the hub to get things cleaned up. But both protocols do have housekeeping methods that should automatically improve messaging over time after a device goes defective. So both protocols are considered “self healing networks.“
For more information, see the resources on the various alliance sites.