FAQ: Please explain Repair Z Wave Network

Hi there.

I’m hoping to get a better understanding of what all happens when I hit the Repair button. I get a vague sense from the articles on the site, that the Hub? is sending out commands to the mysterious mesh network. But that only tells me so much. Does anyone know the ins and outs of it?
For example…

  1. What is the command or signal that is going out? Just checking in to see the device? Telling it to look for different routes? Asking it to see if it still has a valid route?
  2. So if it has a route that is still technically working but not great…is there anything that can force it to change that route?
  3. I read on the site just run the Repair. And also read from users that you should run it 4-5 times. Is that true in every case? Only if you see an error? Can running it more times make things worse?
  4. When I run it and it shows me a huge list of devices that failed to update the mesh, does that mean that by asking them and having them failed I have impaired the system now?
  5. What is the difference between running it on my phone app, vs running it in the API?

I don’t want to keep pushing a button I don’t understand since it seems like tossing a pennny in a wishing well. Nothing tells me it works, but nothing tells me it doesn’t.



nebulous, ain’t it.

my unstudied guesses from the last 2-3 years of practice and observation:

  1. “Repair request” from hub, is asking all Zwave devices, which may or may not be awake to see the request, to update their communication path back to hub.

  2. “Repair” is the “force”/request that does not actually force anything different to happen.

  3. Multiple repairs improve the “chances” that you will catch the sleepy/battery devices when they happen to be awake. If you have communication failures then first, try repair. It is unlikely to make things worse. Then add repeaters.

  4. IMO no, repairs cannot make things worse, unless you have temporarily installed plug-in/repeater devices that you will soon remove.

  5. no difference between repair requested via the phone app or the API (I assume you mean IDE/website).

just press the button.
Yeah it’s opaque and obtuse.

1 Like

Just as a heads up… usually Z-Wave repairs will make things better. However, if you have a lot of Z-Wave devices (there is not a hard number), running a repair can be resource intensive and cause the Hub to temporarily stop working. This is something we are working on improving.


Official article:


Short answer:

Every zwave device keeps a “neighbor table” of its own closest neighbors that can be used for routing. That’s all. It doesn’t know the entire network. Just the neighbors that it can send an outgoing message to as the first step in a relay. The repair utility tells each device to update its own neighbor table.

Long answer:

Remember that the whole goal of Zwave and Zigbee is to keep cost down both in dollars and in energy draw. It’s cheaper and faster to check a table of two entries than it is to check a table of 200.

The controller, in this case the SmartThings hub, keeps the complete network tables. But each individual device just keeps the minimum information it needs to know.

If devices are physically moved around, or new devices are added to the network, or old devices are removed from the network, the neighbor tables can get out of date.

The only thing the “repair” utility does is tell every device to update its neighbor table with its current closest neighbors. Honestly, that’s it. It’s just a little bit of housekeeping. Say hello to new devices, say goodbye to ones that have left the network or are now out of range, make the neighbor tables efficient again.

The reason why field technicians often run several Z wave repairs in a row is because battery operated devices might be asleep the first time the request went out. Again, to save power, battery-operated mesh devices typically sleep a lot. It’s all in millisecond slices, so it might sleep for 8 ms, wake up for two, etc. But it saves battery significantly. So you might run it a couple of times just to make sure you hit everybody. But you don’t have to.

Repair as maintenance:

In most Z wave installations, a zwave repair (which is part of the Z wave standard) is a “can’t hurt, might help” utility. So if you’re seeing too much lag in the network or you can’t remember if you updated the tables when you removed a device a couple of weeks ago or you observed weird behavior on a particular device, normally you would run the Z wave repair.

However, SmartThings staff have said several times that if things are really flaky running a zwave repair could make things worse. From an engineering standpoint (I was a network engineer before I ever bought SmartThings) I don’t understand that. I can only assume it has something to do with SmartThings cloud architecture. But I certainly believe the staff when they say it, so at this point I no longer recommend a Z wave repair with SmartThings if things are flaky until the person has talk to support.

Most SmartThings competitors recommend running a Z wave repair once a month or once a week or even every night just to keep everything tuned up for maximum efficiency. Vera automatically runs one every night. Homeseer recommends running one every night but understands that people using the system for security might want to postpone it for a more convenient time so they leave it as a user option. (While the repair is running, other zwave messages will be postponed.)

So that’s probably more than you wanted to know but basically it’s just telling each device on the network to update its own neighbor tables. :sunglasses:


It shouldn’t, but with SmartThings who knows?

Normally the messages are just telling you about a problem that exists whether you run the repair or not.

“Failed to update the mesh” could just mean a sleepy device that was asleep when the message went out.

But there’s a huge difference between getting this particular error message with the device name and getting it just with an ID. If you get it just with an ID number, you have some ghost devices and you do need to clean that up. See the following thread for details on the error messages.

Every time that i run a Zwave repair from the Android app, I haven’t been able to see the status of the repair! It just spins forever. Is this normal for all users? Does it show the status of the repair in the graph utility online?

Try running it from the IDE instead under hub utilities and see if you get a different result.

  1. click on community at the top right of this page. That will take you to the first page of the forums.

Two) click on “developer tools” to log into the IDE.

Three) choose “my hubs” to go to the hubs page. If you have more than one hub, choose the one for which you want to run the repair.

Four) look for the section on “hub utilities” about two thirds of the way down. Choose that. That will open the utilities page.

Five) choose repair.

Not even a little bit. I wanted to know every scrap of that. Its the little things that weren’t quite spelled out in the original article.

Its good to know that running the repair actually asks the devices to make changes. I wasn’t sure if it was just saying…yeah I can still barely reach that old device you moved, so I’ll just stick with that. That was the dread.

So a follow up question. When it says it Failed on a device. Does that likely mean the device was sleeping? And just try again?


The error message FAQ has all the details on the messages. It depends on the exact format that you get.

Yes, thanks. I didn’t know there were others. I only ever get “Network repair for [device name or ID]: Failed to update mesh info” . But its pretty inconclusive about what that one means. I’m guessing its not a big deal though. Just doesn’t help me troubleshoot devices that just stop communicating when they have clear lines of sight to other repeaters. I ran some repairs this morning and almost every device gave me this error message.

But thanks for that link. Its good to have an idea what the errors mean if I ever see other ones.

1 Like

It just means the device didn’t respond.

If it lists the device by name and it is a sleepy device, it was probably just asleep.

If it only lists a device number, then it may be a ghost device – – a device that has been physically removed but that, for whatever reason, still has an entry in the address table. Those should be addressed. (See the messages FAQ.)

1 Like

Yup, lously sleepy devices. Just looks bad when a dozen or so report FAIL at once. Heh. :unamused:

Thanks for the info.

1 Like

Now you know why field techs run the repair a couple of times. :wink: You might get a different set of devices not reporting each time, you just try to hit each one once.

A really old thread, but I’m going to assume that much of this is still valid for the current Z-Wave spec.

It’s been suggested that a Z-Wave repair should be run after allowing newly added devices to establish their routing topology, but as you say Z-Wave repair only tells the devices to update their neighbor tables, is Z-Wave repair really needed for devices that were just installed for the first time?

Since Z-Wave Plus supports Explorer Frames, is Z-Wave Repair a useless step for an all Z-Wave Plus network? Is it harmful if it’s run in an all Z-Wave network?

Definitely not harmful if the specification was implemented correctly. Literally the only thing that the zwave repair utility does is tell each individual device to update its neighbor tables.

As far as if it’s needed, if all of your zwave devices are zwave plus devices it’s not strictly needed, but it can take a long time before the explorer frames get everything on the network updated. It’s just much more efficient to run a Z wave repair as part of your new device installation process.

Some of the confusion may come from the reason for running the zwave repair at that time. It’s not necessarily to update the neighbor table on the brand new device. But if you did a “bench pairing,” that is, pairing the device close to the hub and then moving it to its desired location, the zwave repair utility will make sure that it knows who its true neighbors are.

Second, the zwave repair will cause the rest of the devices on the network to become aware of the new device, which doesn’t typically happen when you just add a new device to the network. It can take days for explorer frames to find it and get everybody updated if you didn’t run the utility. And if you were adding the new device in order to strengthen the mesh and have it act as a repeater for older network members, then you probably want to see that improvement as soon as possible.

So running the zwave repair after you add a new device and have put it in its desired location is just a way to speed up The process of updating the network tables. You don’t have to do it, but it can definitely help.

Every once in a while smartthings support will tell someone who is having problems not to run a zwave repair “or it might make things worse.”

As far as I can tell, that’s because of the cloud component of your smartthings account. If they are out of sync or, heaven forbid, if your cloud account is corrupted, then running the zwave repair might cause them to become even more out of sync. That’s a flaw in the platform implementation – – it should not be a problem, regardless of the size of your network.

Most smartthings competitors recommend running a zwave repair frequently. It should always be a “can’t hurt, might help” utility. Vera automatically runs one every night. Homeseer recommends running one once a week just as part of regular maintenance.

However, once you toss the cloud piece in, who knows. If you are working with support on a specific problem, I would follow their recommendations during the troubleshooting process for that problem.

But other than that, even with Explorer frames it’s a good idea to run one after bench pairings or after adding a new repeating device.


Thank you so much for the quick response and concise information as always. Much appreciated, and clears up the confusion for me.

This is a conversation from 2016 but, if anyone is responding, I’m having a problem pairing a Eaton Master Dimmer Switch (I chatted with them and their switch IS compatible with SmartThings). I use to have a Clare Controls hub that died. I’ve replaced it with a SmartThings Hub 2018. So I tried discovering it so I can do an “exclusion.” SmartThings did NOT discover it. So, right now, I’m performing the “Repair Z-Wave network,” which is taking a while. Should this clear it so the Eaton will be discovered and I can pair it to the Hub? This Eaton switch thing is turning out to be VERY frustrating. Would appreciate a workable response, if there is one…thanks.

When a Z wave devices first joins a new network, the hub for that network assigns it a network ID and that’s how it will receive all future commands. Essentially its address for messages on that network.

If a Z wave device already has the field for address filled in, it will refuse any join requests from any other hubs. So you cannot discover it until you get that field cleared

The Z wave alliance was very aware that a device might have previously belonged to a different hub, but now the hub itself was damaged, or you bought the device used, or the previous network was a test network at the factory.

So they created an option called “general exclusion“ which allows any Z wave hub to issue a “Clear fields” command to all Zwave devices within a hearing, whether they ever belonged to that hub or not.

A person then has to physically put the desired Z wave device into “exclusion mode“ or it will just ignore the clear fields instruction.

But if a person does put the device into exclusion mode, then the Z wave device will accept the “Clear fields instruction” even if it never belonged to that hub before and it will erase the old information.

Once that is done, then the new hub can issue the “join my network“ command (called “inclusion“ in zwave) and then and only then the Z wave device can be added to the new network and receive its new network ID.

We would need the exact model number of your Eaton Cooper device to know exactly what the required device manipulation would be. But the general process will be the same.

You will issue a “general exclusion“ command from the smartthings hub. As long as the Eaton Cooper switch is powered and online you will then be able to physically manipulate it to accept the “Clear fields“ command and it will erase the information from your previous network that is stored in the switch.

Once that is done, you can then add the switch to your SmartThings account as usual.

So to be clear, you don’t discover it so you can do the exclusion. You have to first complete the exclusion before you can discover it. :sunglasses:

Thank you for responding. I’ve had Repair Z on for quite a while and nothing has happened. Now I know why. I had to pull the switches out of the wall (without removing the wires of course) to get the model numbers. We have a new town house that came with these switches installed along with the Clare Controls hub, which has died. We switched to SmartThings because Clare, which only works through “integrators,” to come out at $100 a pop to fix it. I want control over my hub without paying that. For the Eaton Cooper Master Dimmer, the model number is RF 9540 N. For the Cooper Smart Dimmer Accessory {add-on), it is RF 9542 Z. Not sure if the add-on # is needed as it isn’t the master. If you can, is it possible you can tell me how to do this step-by-step. Don’t understand how the “general exclusion” works if the device isn’t even picked up on a scan? Thank you.