Automated Cleaning of ZWave "Tortured Routes"

Get Help Apps
14

My understanding (and I'm not an expert) is the Zwave controller just changes routes when it's forced to, aka, when it "can't get to a destination" or no existing route is defined. (then Explorer Frames are broadcast to find any working route) - This stuff is not nearly as sophisticated as OSPF or EIGRP, with costs associated on the hops. Once it finds a working route (LWR), in ZW+ the controller basically sticks with that, as it tries the LWR first (and any burst of interference/noise might force it from an obvious/optimal route), it just doesn't dynamically change to lower cost routes, once it finds a working path - It's also a proprietary routing approach by SiLabs, so it's not like the internal routing scheme is well documented - But the best description, I could find, was section #4 of this article

There are some other limited docs:

Finally, there is a concept of ZW application priority routes (APR), that can "force" a route, but those are obviously not self-healing, nor supported by HE (to my knowledge).

Bottom line ZW LR is likely your best bet to "force a route" and keep it to a single hop (and it also supports higher power levels that the standard mesh, as I understand it)

Totally agree - And given that it's done in ZB (See the GroupOn/GroupOff commands) it does seem to be a missing feature in HE ZW and Matter APIs

As I understand it - the older ZW ZIP gateway does NOT seem to support ZW Multicast. But, that all said, the newer ZwaveJS interface DOES support multicast (there are apparently limits around S0 and S2 security) - But I think RL and Groups/Scenes were both written before ZwaveJS was available (so this all may be a historical/chronological artifact of what was available at the time)

So it would be great if @bcopeland could expand the HE Zwave APIs (and Matter APIs as well) to support Multicast - Then I think it could be integrated into G&S and/or RL (more likely).