Dump out Device Routing table!

From time to time my hub would drop devices and drop even more when I ask it to do repair. Within the month sept-nov, on 3 different occasions, my devices started to fail and drop out the network of the devices as I ran repair: with hub logs about “Failed to update mesh info”, “Failed to update route” “Failed to assign new route”. And the funny thing is that when I moved the hub closer to the devices and ran repair, it actually made some of them that didn’t fail, fail.

At this point, I must ask, why can’t I get the most basic routing table representation as seen by the hub for each device? I don’t care for a visual diagram. It can be just a matrix representation of tree of device ids and its neighbors device ids. With that I can at least track down bottle necks or find dead devices.

Lack of this information and I have to GUESS which device failed that can cause my mesh to be all dropped is very frustrating. How do you guys behind the scenes there do your job debugging people’s network?


I am having this exact problem. About once a month my zwave devices would be very laggy and some won’t respond at all. Running repair showed “failed to update route” for a few devices. I’ve been trying to figure out which device is killing the mesh for a couple of months now but still no luck. Each time this happen, i would power down the entire house then everything is responsive again after power restoration.

Instead of dumping out a routing table, perhaps it’s not smart, at least the hub should suggest replacing a device that’s down and not routing.

I am in the same exact boat. In the events log, sometimes it will display the routing information after a successful repair.

I am having an issue where an orphan device is stuck in the routing table and somehow causing the Z-wave module to fail. It is really brutal. On Vera, I could just edit the device out. Here I cannot.

1 Like

@Kristopher, what’s the device ID of that orphan? A couple of times I tried to exclude a switch and it says “Another devices was excluded”, I had to exclude again to get the switch to exclude. Reviewing the log it indicated that the “Another device” had an ID of “00”.

Is it the hub or is it actually a broken device that tried to confuse the network?


The device ID is “04”. It used to be a normal z-wave switch that was acting funny. I excluded it, the exclude was successful, but the device keeps popping up in the z-wave repair and then killing my repair somehow. I air gapped the switch so its not that the switch is sending some weird signal to the Hub. Check this out:

2015-11-12 10:35:01.385 AM CST
48 minutes ago	HUB		zwStatus	module failed		Z-Wave module failed
2015-11-12 10:35:01.334 AM CST
48 minutes ago	HUB			Err 101: ZW module not respon...		Err 101: ZW module not responding
2015-11-12 10:34:51.558 AM CST
48 minutes ago	HUB			Z-Wave device [04]: Not respo...		Z-Wave device [04]: Not responding
2015-11-12 10:34:48.470 AM CST
48 minutes ago	HUB		ping	ping		ping
2015-11-12 10:34:04.557 AM CST
49 minutes ago	HUB		zwNwk			zw network:E651BF49, node:01, suc:01
2015-11-12 10:34:04.538 AM CST
49 minutes ago	HUB		zwStatus	ready		Z-Wave is ready
2015-11-12 10:34:03.067 AM CST
49 minutes ago	HUB		zwStatus	starting up		Z-Wave starting up
2015-11-12 10:33:58.816 AM CST
49 minutes ago	HUB		zwStatus	power cycle		Z-Wave power cycle started
1 Like

WTF… lol this is nightmare level compared to my issue. V2? BTW how did you get this log format?

Yeah V2. Its under My Hubs -> (Pick Hub) -> List Events

Here is one thing to try, assuming that you don’t have a z-wave device with address 04:

Create a new device in the IDE, select some z-wave device type, and assign it the address of 04. Then see if you can run the repair. If so, then delete that device. Sometimes, this works to get rid of a bad z-wave device.

Of course, if you do have a z-wave device with address 04, remove it from your system, then run the repair, then re-include it.


Oh interesting. Trying now

1 Like

Hi Bruce,

That was brilliant - and it did work in a sense. Outside of repair, my network seems to be more functional now. However, the repair is still killing the radio. Any other ideas? I can’t actually execute a successful repair :frowning:



OK - So I spent more time on this. Interestingly enough whatever was wrong with device “04” is OK now. I eventually was able to readd the device and that seems great.

However, the issue with the radio dying “Err 101” still seems to exist. Whatever is going on there is killing the radio before I can do a full repair

@Kristopher you can see if this helps track down what is going on with your Z-Wave network.

https://graph.api.smartthings.com/hub/zwaveDebugOn/{your hub id}

Replace {your hub id} with the id at the end of the link for your hub in the IDE under My Hubs.
This should then enable extra logging in the Live Log and you can see if there is more info when the repair fails.

Make sure to turn it back off when done.

https://graph.api.smartthings.com/hub/zwaveDebugOff/{your hub id}


An ID of “00” usually just means it’s a device that was not on your network, and it picked up a general exclude. Or a device that had a partial paring And was never assigned a network ID. So you can have multiple devices with an ID 00. That’s just the default for any device that was not previously paired to this Zwave controller.

Thanks. I have repaired my network by re-excluding and including all of the devices that had the “can’t update route” message. Also bought a second hub for the house. I am definitely seeing a difference in range as well, the new hub has a longer reach than the old one. This is with same position, same orientation etc.

For now I think I will have to live with 2 hubs for my house. Getting use to switch locations via the app.


So after weeks of the 101 error, I decided to just wipe the whole system and start over with another new V2 Hub. It was so brutal and I am still setting things up. The Minimotes helped. I had more than 100 apps and 300 devices.

To wipe the Hub the first time, I removed each item individually from the IDE. It didn’t take long, but I should have just removed the location and did a factory reset. I put that V2 Hub aside and opened a brand new V2 Hub. I then used a V1 minimote to go aruond to each device, exclude it, and then included it with the ST app. I did about 30 devices at a time and repaired. I did all of the wired z-wave devices, and then the battery powered sensors. However, after I got through my second batch of battery operated sensors, I got the 101 error again during a repair. I removed all of the 30 devices from that batch, then did another repair. I still got the 101 error. This was really discouraging – whatever was giving me this error was in my stack rather something wrong with my Hub.

So with the second new V2 Hub, I did factory reset and redid the whole process. However, this time I used the Minimote V2 to do all the inclusion. It works really well, except for the fact that batch adding devices 30 at a time with no labels is actually slower than including from the ST app directly. I am almost done, but I am further than I was last time and I have not gotten the 101 error. Fingers crossed.

Pairing with the Minimote seems cleaner – the Hub definitely has some issues with Z-wave inclusion on its own. I noticed on the first rebuild that sometimes I would see the device add twice, which got me immediately worried. That did not happen with the V2 Minimote, so maybe that was the difference.

1 Like

Does this still work? I get: Sorry, you’re not authorized to view this page.

Yup, getting the same error. Looks like it has been disabled.