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
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
