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.