Duplicate nodes in route path?

I have one ZWave lock that gives me problems fairly often. I discovered there were phantom nodes in its route a few weeks ago (probably switches I replaced). So I cleaned all that up, excluded the lock, reset it, and added it back. All locked fine with a clean route. But it started not reporting status correctly when it is locked or unlocked (sometimes). Going into Groovy, I see this path:

This Device (18) <> Backyard (0D) <> Garage Door Lights (06) <> Garage Door Lights (06) <> SmartThings Hub

Backyard is a wired Jasco switch about 12 feet from the lock, Garage Door Lights is a switch on the other side of the house and closer to the hub. But why does it show up twice? And there is a Aeotec repeater between 0D and 06 that is being ignored and probably unnecessary anyway. Obviously, ZWave Repair does nothing.

Any ideas on why there is a duplicate? And whether it could be messing up the status? I am using the RBoy Universal ZWave lock DTH and Lock Manager app.

i tried a couple aeotec repeaters and they were more trouble then worth. took them all out and things started working correctly. the nest repeaters that ive found are the aeotec sirens gen5. they run about $25-30 used on ebay.

I have a device (zooz zen16 multirelay, paired with S2 located in the garage, running firmware 1.03) that does something similar. I have no dedicated zwave repeaters.

On top of this, the route it chose is super weird, other zwave devices also in the garage nearby go straight to the hub or one hop at most. This device was added months ago and has never self healed, nor does a repair affect it. But it says it took this crazy route around the house…

I have a feeling that this device hasn’t sent route updates back to the hub (or the hub doesn’t understand them), and this was the route it took during pairing. Not sure why the double entry though. Are there any known issues with the zen16 like this @TheSmartestHouse? I have no ghost zwave devices or anything.

I was going to put the zniffer on and try and catch to see if a heal would broadcast any route changes from it, just haven’t had time. And the device responds reliably otherwise.

Z-Wave devices only send information about their neighbors when prompted by the hub (during inclusion and network repair) but they don’t establish the routes, the hub does. So all of the device does is tells the hub what other Z-Wave devices are around, the rest is handled by the hub. Have you seen anything in the logs suggesting the ZEN16 reported the neighbors twice or confirmed with ST that this type of double report would cause the type of display you’re seeing?

1 Like

Thanks for the clarification! I wasn’t clear on how the routing tables were built up and when.

When I run a zwave repair, the logs all say it was completed and no issues are logged. The ZEN16’s route stays the same. Oddly the other devices have various routes of their own, that also don’t match up with what the routing the hub chose for the ZEN16 (ie, if it knows GE Switch 1 can talk direct to the hub, why isn’t the route ZEN16->GE Switch 1->Hub, etc)

For instance, GE Switch 1’s route:
image

Living Room Corner Light’s route:

Those two device’s routes make more sense as to their location in the home and why it might pick that device to route thru. But the hub’s decision for the ZEN16 is wackadoo, and the double entry in the route sequence to boot. :slight_smile:

(single floor ranch with a basement, basement devices in green)

I wish ST would expose the routing grid and signal data/neighbor count for Zwave like Hubitat does. That might help figure out why it sees what it thinks it sees.

In smartthings, the only thing you are seeing is the last reported route that was chosen. Not the route that is chosen most of the time, or the route that is usually the best. Just the last one that was reported to the cloud. So it’s helpful, but pretty limited information.

As far as why any specific route is chosen, the network has access to information that we as humans don’t, including signal strength, message traffic, etc. As long as you aren’t seeing any problems, there really isn’t any reason to worry about what route it’s chosen.

You can sometimes see a device in a route twice if a message transmission failed and had to be resent, but it is weird to see the same device in two consecutive hops. I’m not sure what’s going on there.

Are you having problems with this particular device or were you just curious about the reported route information?

1 Like

I was curious. And the double entry in the route made it even more interesting. I get that routing can be black magic especially when we don’t have access to all of the data on a minute by minute basis. Its just curious that this one device has done this since it was included, and its had stranger routes before. At one point the route displayed was something like ZEN16->Honeywell Outlet->Honeywell Outlet->GE Switch 1->Hub

And if other devices had unexplained or :man_shrugging: routes too, I wouldn’t have been so curious… Just this one!

the zen16 is a multi endpoint device. It’s possible that smartthings is getting confused and the multiple entries have to do with the multiple possible origins. But I don’t know for sure. Smartthings route reporting is not The same format as most Zwave hubs. :thinking:

Yes, I do have problems with this end device. Status from the lock is often lost and then automations don’t work as they should. Maybe 25% of the time.

1 Like