FAQ: Zwave repair not working (how to fix error messages)

When you run a zwave repair, The hub goes through its device table and attempts to contact each device and ask them who their current neighbors are.

The hub then takes all of this information together and calculate some optimal routes in advance. It sends this routing information back to each individual device, just The part that applies to that specific device. So each device ends up with a partial routing table. All of this should make routing faster and more efficient.

So in a sense the hub asks a question, the node answers, and then the hub sends out a New map for the node to use.

The two common error messages that you will see are

“Failed to update mesh information.” This means the node didn’t answer the first question. It didn’t send back the list of its neighbors. That might mean in the node is missing altogether, it might mean it was just asleep, it might just mean it’s out of range, or it might mean the data was corrupted. If it was just asleep, it’s no big deal. If it’s out of range it may not be a problem as the rest of the map is filled in.

Note in particular that “failed to update mesh information” won’t cause a problem for the network if that particular device was a battery powered device because they don’t act as repeaters. But if that device is a repeater, it can’t be used in routing until the error message goes away, so you can lose access to a lot of other devices down the line.

“Failed to update route”

After the hub has collected all of the information from all of the devices it starts calculating the routes. when it has the partial map ready for a particular device, it sends the information to that device. It should get back an acknowledgement. If it doesn’t, you get the “failed to update route” message.

Again, this can happen for a couple of different reasons. If the device is battery-operated, it might just have gone to sleep again. It happens. if any devices get physically powered off during the repair, it can happen. if devices get moved around it can definitely happen.

When this does happen, it’s actually not that big a deal. It just means that there’s a device out there that doesn’t have the most optimal route.

I’ve mentioned before that a lot of field techs will do 3 zwave repairs in a row. Cleaning up These kinds of errors are the main reason.

Of course you could also get either of these errors because of either data corruption in the address tables or device failure in the hub itself, obviously both a problem. But most the time it’s just a sleepy device that’s thrown something off and it will run fine the next time.

Ghost devices

The ghost device error where you only see a device number not a name and you get “[ ] not responding” is a different kind of error, and one you really shouldn’t see very often. The problem has been well described in posts above, it means the hub has a listing for a device which is no longer on the network. You have to clean up the address table so that the network will stop trying to use it.

7 Likes

@JDRoberts

This is awesome information!

How did you find this out?

I have been thinking for awhile how I would ask these questions because these are the kinds of errors I sometimes get.

College major in Computer Information Systems, worked as a network engineer, asked a lot of questions. :wink:

Z wave repair utility is a standard function for the protocol. But the exact wording of the individual error messages is up to each controller company.

I am a bit late on this thread, but I just had a problem with my hub and am looking for ideas. My hub can read the status of all devices, but when i try to issue commands to any device, nothing happens for any one of my devices.

I tried running the network repair but nothing happens. I did try deleting the name filter on the event log as someone suggested, and the only thing the hub is doing is sending out a ping every 30 seconds. But nothing on the repair as far as i can tell after 25 minutes. I don’t see anything in the live logging at all about the repair being started even, so i don’t get any kind of error messages.

I am at a bit of a loss. I would assume if i had one of the errors mentioned it would at least kick off the repair and tell me what the error is?

Ok, update on my issue…i did a hard reboot of the device. I had tried doing a reboot through the API a few times but that didn’t seem to work. Then i went down to my basement and a hard reboot fixed my issue…should have thought of that before I suppose.

I have recently had havoc in my zwave network which was caused by malfunctioning Aeon Smart Switch 6 (one or two of them). After recovering from the nightmare I ended up with two zwave IDs that show up in my network repair log as follows:

Network repair for device [62]: Did not finish updating mesh info

I followed the instructions above to force delete ghost devices but it no longer works. The ST app just says it sent the force delete command but then nothing happens and the devices are still there. If I delete them from the IDE nothing happens either.

Other than having ST support delete them, is there anything else I can do to nuke them?

Question, if there is only one Z-Wave device installed, does the Hub to the Z-Wave dimmer make up a mesh? I understand the concept of mesh network but do not know in this case if it is really applicable as it mostly resembles a client/host. In other words can a mesh exist with one, two or does it have to be more than 2 Z-Wave addresses? The reason I ask is because my Z-Wave repair fails with "Failed to update mesh info"
Thanks!

I’d say that a mesh network technically exists once there are at least two devices on it (hub and device) but the mesh part only really comes into play when there are 2 or more non hub devices that can relay each other’s messages. Even though you only have one device, the table with mesh information exists anyway. Why it has trouble updating it is a mystery to me too! This is just my guess…

1 Like

Thanks for these instructions! I’ve got 2 ghosts I’m trying to get rid of. I’ve followed your instructions but having an issue with step 5. After attempting to force-remove the ‘Trash’ devices, they don’t actually get removed. I can delete them from the IDE, but they still appear to leave their ghosts behind that are fouling up my zwave network repair.

Any thoughts?

At this point, I usually wrote to support. Then they are gone in a couple of days.

1 Like

From my experience deleting from the app rather than IDE seems to work better. Sometimes the app doesn’t refresh without getting a serious kick in the …

1 Like

FWIW, info from a newb (me) here:

I was having a hard time with a Lowes IRIS garage door controller GD00Z-1, and it was reporting an UNKNOWN status. After spending some time on the forum here, opening an closing the door via the wall switch, checking sensor batteries, etc, I went to the repair Z-Wave Network section of the mobile app. For the garage controller, I got both:

“Network repair for [device name or ID]: Failed to update mesh info”
“Network repair for [device name or ID]: Could not assign new route”

I got the same result from the IDE.

I had added/paired the device from just a few feet away from the hub as suggested here. I ended up removing and excluding the opener, and re-added it. This was with the hub maybe 20 feet from the controller. Everything worked perfectly. I even tried a repair, and it reported no errors. FYI, I had to download the instructions for the GoControl branded GD00Z for exclude instructions, as the IRIS controller instructions were specific to the IRIS hub.

It’s unfortunate that this install took about 2 hours instead of the 20 minutes it should have. Hopefully the second garage controller goes a bit more smoothly.

1 Like

I’m trying to do a Force Remove. I went to edit the device, clicked Remove. Waited for that to timeout, then clicked the Force Remove button and OK. SmartThings says it was successfully removed, but it is still showing up in both the App and IDE.

So I too had two phantom devices. So after reading what was described above I tried it and as you said it no longer works. So I tried a new variation and it worked on both of my phantoms. I had an extra receptacle that I made sure was not in my network by trying to removing it using the app removal process as described above. I than created a new device (called trash) with the type I know that is would used by normal pairing process (for my receptacle) plus of course the phantom network ID. (Now the change. Using the app on my phone I did a “replace” on the trash device. When it asked me for the new device I triggered pairing on my unused receptacle and it replace the phantom to the newly pared working receptacle device. Than using my phone app, I removed the trash device (which was a working receptacle). I re-ran Network repair and the phantom is gone. Doing it for the second phantom was the same process. Both phantoms are now gone and I have a clean Repair.

4 Likes

I keep getting the Failed to update mesh info for two of my devices they were working and nothing was moved there’s one zwave switch that i installed that should be making connection better since it’s a repeater. I’ve read all the information but I’m confused because that in on post, I read hub should be powered down for 15 minutes then brought back up then repair initiated . in another I read that only works for zigbee. The hub is about 9 feet from a Leviton DZS15 switch and then my problem switch is an Enerwave ZWN-RSM2 PLUS hooked to a ceiling fan is in the next room about 15 from that switch. What’s the best way to get these working right? (it’s my bedroom and my GF is getting pissed that lights aren’t working.

Most mains powered Z wave devices are repeaters, including the two that you just mentioned. It’s battery powered devices that don’t repeat.

Did you see the following above?

Note in particular that “failed to update mesh information” won’t cause a problem for the network if that particular device was a battery powered device because they don’t act as repeaters. But if that device is a repeater, it can’t be used in routing until the error message goes away, so you can lose access to a lot of other devices down the line.

If you were getting the “failed to update” from a wired device, something is seriously wrong. Check the wiring to make sure the connections are good. For a switch, test the switch manually to see if it’s still controls the light and if it’s LED comes on appropriately.

I would also contact support in case they can see something from their side.

This worked, thanks. But what a pain!

1 Like

This is a great asset for a frustrating problem :slight_smile: any thoughts on how these ghost devices appear to begin with?

Typically, it’s a cloud artifact. Somehow you succeed in deleting the device from your cloud account without ever actually deleting it from the device table that the Z wave controller inside your hub keeps for itself.

There are multiple ways this can happen in a SmartThings environment. Manually editing the device list through the IDE can do it. Doing a remove which for whatever reason fails to complete fully can do it. Database corruption in the cloud account itself can do it. There are couple of other possibilities as well.

Thanks - I’d guess it was one of the few times I moved a device and renamed it or something along those lines. I’d guess this might be a common pitfall for those unfamiliar with the way things work.

I was hoping this might solve my phantom device problem in Google home, but no dice. A similar strategy (renaming a device and then trying to delete it) just gave me two devices with the same name :slight_smile:

1 Like