Ver .121 zigbee taking screwy routes

look below.. never saw this before version .121 prior my sonoff repeaters were used as repeaters.. now one is using a bulb with a low lqi and an outcost of 3 (higher than the sonoff itself which has a great lqi in the 200s and outcost of 0) as a repeater ..

This makes absolutely no sense..


I normally don't jump on the latest updates but they've been coming fast a furious with the C8.

Last night I updated to .118 and my Z-wave mesh is a train wreck now. Before 28 devices direct, 2 had to relay, one an outdoor plug, one a really old GE/Jasco switch in the garage.

Now I only have 16 devices direct. There's a switch in the hall not 8' from the hub that only has to get through my fat head and one layer of drywall. Running a z-wave repair now.

Doh! now I see .121 must have rolled out right after I updated. not sure if i should roll back/restore or roll forward at this point.

Doesn't it usually take some time to stabilize?

Also, what is Repearter? LOL.


It's never acted that way before or the past few updates since moving to the C8.

zwave routes are rebuilt following a cold start. recommend shutdown hub then remove power then wait 30 secs

it did remove the screwy route... but not sure what stupid alrogithm assigned it in the first place.. is it a bug in the device or the hub....

In that example the routing did what it was supposed to do.

Outcost=0 is a special case, meaning the far end of the bidi link either never told the near end what its cost (LQI) was, or it has gone 6 age intervals without updating its status (1 age interval is 15 sec.)

LQI measures reception; it can be 'great' at the near end, and lousy at the far end. Neighbor table's LQI's are for near end (hub's) reception only. For the far end of that same link, you don't see LQI in the table, you see outCost (derived from LQI measured at the far end).

The great LQI of 7253 means the hub hears 7253 loud and clear (inCost=1). The outCost=0 means 7253 hasn't recently told the hub whether it hears the hub, at all...

So when hub wanted to talk to 7253 (which was obviously a neighbor, but at that time wasn't confirming that it was receiving) it picked another router which had advertised having a route to 7253, which evidently was 576B.