Change z-wave routing table ourselves

Repair failed node unreachable

06 07 08 09 0D 0E 14 16 1E 23 0C 11 13 15 24 19 1C

You've posted in a lot of different threads now, so this is hard to follow.

But in general, once you have multiple ghost nodes it is not uncommon for both repairs and pairing to fail. You need to get the ghost nodes fixed either by working through removal on the hub, using an external usb stick + PC zwave software, or by starting over on the mesh and factory resetting all devices.

I know that will likely not be great news, but once there are ghost nodes - especially multiple of them - the options are limited.

EDIT: I see Bryan is helping you out in another thread. He has forgotten more than I'll ever know on this topic, so I'll bow out in deference to his help!

Good luck! Seriously!

1 Like

Thanks. Was able to get things back and running finding out what I was doing wrong. However, there's still the matter of having ghost devices appearing every other device I try to pair. The inclusion times out and initialization doesn't finish, thus generating ghosts: and this, even if i touch nothing, at all... it looks like it's more frequent with battery powered devices so I wonder if it's not the hub that is too slow at pairing before the device is done, but I can't really say; what I can tell is that there are a lot of people in my situation and also that I never had that problem with my C5's and my C4 hubs...

I had that problem continuously on the C-5 when I first joined. The difference is that the C-7 puts it in the zwave details page that there is a ghost and the C-5 did not. The very easy way to tell on the C-5 if you have ghosts is when you run a zwave repair and you get 4 consecutive "Repairing SUC route" or something to that effect and it just goes to the next device. Although you could only see this on repeating devices that are included in a zwave repair.

This is what got me to include every device right next to the hub, then just let the mesh settle itself out for about week. When transitioning to the C-7 I had zero ghosts out of 43 devices.

2 Likes

I guess I had a lot of ghosts on my C5 then!!! LOL! I wonder then if it is not worth the pain it's like the C7 forces you to maintain your mesh.

I have the exact opposite experience, I fought for months resetting my radio and rebuilding my mesh from scratch AT LEAST 6 times, trying to get the problems ironed out on the C-5. I've literally had no issues whatsoever on the C-7 all 3 of my (problems on the C-5) Schlage locks work perfectly, even one a great distance on a metal building. Everything is far more responsive and reliable on the C-7 from my experience.

I put off getting the C-7 because I really didn't want the hassle I once had with the C-5 again, now I'm kicking myself for not getting it sooner.

1 Like

Any idea where to find the doc about remove statuses ?

Could you explain a bit what you are trying to do so that we can understand the document you need?

Oh I'm just trying to understand the logs when I try to remove a dead node such as:

Failed node XX remove status: 0

https://community.hubitat.com/t/unable-to-remove-z-wave-device-on-c-7/49281/18

Yes that’s what I was looking for. Any idea where to find the complete doc? Is this it?

That is it.. This is the list from the 700 series SDK as this message comes from the SDK

2 Likes

2 ghosts now... 12 hours without any z-wave device working, after fresh install. I most certainly have made mistakes, but there's no way this can be a viable smart home solution for me.... I'm going to have to rethink this entirely. Fact is: it doesn't work for me... any longer and after 4 years without such a huge obstacle... no choice left here. Can't have a system that controls my water valve suddenly disconnecting from all my devices at once.

Ok, so hub migrated, all zwave devices working, clean table. HOWEVER, can someone try to let me know why after reboot my devices have a good reactivity but, like 30 minutes later, the routing table is totally changed and nothing works any longer.

Example: after reboot, Aeon Smart Strip, node 4A, route: 01->4A, everything's ok (hub not too far, maybe 6 feet away, one light door in between). Super reactive.

Then, later, like 30 minutes or so:
01->31->08->4A...

that is:
A signal that goes from the hub, then one floor down, further away to the right in the most remote of my rooms, then back upstairs closer to the hub and finally to the device...

And, of course, 2 minutes reaction between button pressed and toggled switch. This makes no sense to me...

It would be indeed quite useful to be able to set our own routing table.

1 Like

The 2 minute reaction time scenario is consistent with a device that has tried (and unsuccessfully re-tried, according to the protocol, a specific number of attempts) the standard Z-Wave routing methods which are always performed in this order :

-Last working route (if it exists-- only post SDK 4.5x devices store it)
-Direct RF to previously learned in-range neighbors
-Calculated routes (the hub's routing table distributed routes) retried to a set limit
-Direct RF, again
-Explorer frame (last resort mesh flooding)

This video outlines the process; it includes a table of retry timeouts that could explain the long delays you're seeing: Z-Wave Mesh Performance Training - Silicon Labs

It sure seems like the explorer frame method is the only one that is functioning in your mesh. The tutorial refers to it as 'last resort' for a reason-- it has terrible performance and renders the rest of the mesh unusable as it is bandwidth intensive. Hence it incurs the worst delays (potentialy 30 sec. per hop, not including retry timeouts for the previous routing methods). It should only be invoked when all other methods have failed.

Normally if it (explorer) succeeds, the resulting path should be saved as a LWR in the device (but NOT in the hub's routing table-- that only gets updated and recalculated when a neighbor rediscovery is done via a user-initiated repair or some other hub process as C-7 now does) to prevent having to go through that again. So the key issue in your mesh seems to be why LWR's aren't being remembered, requiring the whole chain of failures, timeouts and explorer discoveries to be performed repeatedly.

Are all your devices capable of using LWR? Kind of a rehtorical question as the answer isn't obvious. Supposedly the determinant is the device's Z-Wave SDK level (which the video states is post SDK 4.5; you'd have to look up the details on each device's certification page at Z-Wave Alliance website). That seems to be a fairly old level and should encompass everything released in the last few years (including some non Z-Wave plus). And if explorer frames are working, as they seem to be in your case, the devices should indeed be at a level which is post 4.5x (yet bizarrely, level 4.5x actually was released after level 5.02. Perhaps that is an issue). Puzzling to say the least.

4 Likes

Oooh. Video. Cool!

1 Like

There are a series of Z-Wave tutorial videos linked there as well; they're worth watching (each runs for about 5 min or so). Here's the full list: Z-Wave Technology Training Series - Silicon Labs (silabs.com)

2 Likes

Hi @waynespringer79; I have a similar experience with zwave devices; I wonder whether upgrading to C-7 would resolve the issue or not now; Do you currently have a metal beam structured house? (as I have one, as per my comments here)

I do not. Metal does have a tendency to have some interference with radio signals.

My issue mainly with the C-5 was with zwave locks, other than that it was mostly ok, however I only use zwave for power monitoring, a few contact sensors, smoke detectors, and locks.

As per the locks, they have been drastically improved with the C-7 chipset.

1 Like