Which is the expected behavior. A mesh has multiple paths form one device to another (by design to create redundancies). As I had mentioned in my post above:
It can pick any path from it’s routing table to and each repeater along the way can change that path so it can change from one packet to the next. The topic helps identify a ghost devices in the mesh and get rid of it since it can cause delays, loss of packets and performance issues. Using the last used path is one way to identify potentially impacted devices and ghost devices. The ideal way is to do a full z-wave repair and look at the device events to identify every ghost device in the controllers table (explained in detail in the first post).
Theres no way to force the device to use the optimal path everytime (although the mesh is supposed to do that). But what you’re seeing is a possible fallout of the mesh repair operation which is saying that there may be interference (radio or physical or reflections etc) between some devices which is causing the mesh to use a longer path instead of the shortest path.
So in your scenario, the device may have sent the packet 3 > 1 > Hub and then also 3 > Hub but the 3 > Hub packet never reached the hub and but the 3 > 1 > Hub packet did reach the hub. That would indicate to me that there’s a problem with the 3 > Hub path. There could a number of reasons, for example
- If 3 is a battery operated device (sleepy or FliRS), then that may explain it since the hub doesn’t do a good job of buffering packets, which leads to a loss of the packet and eventually the
3 > 1 > Hubpacket reaches the hub - There could be radio interference or a physical object causing the signals to bounce/reflect which then causes interference between 3 and the Hub thereby making it choose the alternate route or the packet sent via the alternate route reaches the hub eventually.
So what is really is telling you is to investigate why the mesh would take a longer path when there are shorter alternate paths available.