[Feature] Assigning custom Return Routes and Priority Return Routes

[darkbasic]

Is your feature request related to a problem? Please describe. Routes computed by the zwave proprietary firmware are garbage with insane latencies and an useless number of hops. The application (us) knows better and we might either manually assign our own routes (computed by the best AI available: the zwave network owner) or devise an algorithm to brute force its way to best possible route. We can already set Priority Routes but unfortunately that's not enough because this route is not set at the end node, only the controller will use this route. If the end node needs to send a message to the controller it will use this route if it is the LWR otherwise it will use one of its own assigned routes. So we need to support setting Priority Return Routes along with the existing Priority Routes. Even with the Priority Return Routes the node will fallback to the shitty firmware-made routes in case of failure, so it would be better to be able to also set (and possibly cache) Return Routes as well to avoid high latencies whenever a Priority Return Route fails. There should also be a way to restore the cached return routes because we cannot fetch them and there is no guarantee that they haven't been tampered with. That would be the minimum to be able to start playing with better routes and it will be a good starting point to develop algorithms to brute force the best possible routes.

Describe the solution you'd like Being able to set all possible route types: https://drzwave.blog/2021/07/13/z-wave-mesh-priority-routes-explained/

[robertsLando]

As we said I think before implementing this makes sense to add a cache on driver to store return routes once them are set using the related method, so at least I can retrieve them on startup. In the meantime I can prepare the ui to draw them.

cc @AlCalzone

[AlCalzone]

Not sure what is meant by "custom Return Routes" - we may actually be able to freely set return routes by bypassing the controller API for this:

https://github.com/zwave-js/specs/blob/master/Z-Wave%20Long%20Range%20Specifications/Z-Wave%20and%20Z-Wave%20Long%20Range%20Network%20Layer%20Specification.pdf, chapter 4.3.2.12 Assign Return Route Command

But I'm not sure if we should go down this rabbit hole.

[darkbasic]

But I'm not sure if we should go down this rabbit hole.

Priority Return Routes along with Priority Routes would definitely be enough to get (most of) the work done, but the problem is that if they fail (and they will fail from time to time due to interference) you're stuck with the stupid Return Routes assigned by the proprietary firmware which (at least in my case) are utterly useless and will certainly cause a latency spike in the best case (or even packet loss in the worse scenario). AFAIK they can be set in PC Controller so I see no reason why we shouldn't permit that in zwave-js. Most users should stay away from that, but those who wish to experiment should be allowed to. I am at the point where I'm almost done with zwave and I either find a way to easily set custom routes or I move entirely to esp32 + tasmota/esphome. I think that Priority Return Routes + Priority Routes will probably get me 90% there and I could fill the remaining gap with custom Return Routes. Since my nodes are clustered in a few places it shouldn't be too hard to manually devise decent routes and if they prove to get the work done I'm sure that an algorithmic way won't be too far off either.

[AlCalzone]

AFAIK they can be set in PC Controller

No, that only uses the API where the controller itself decides. It doesn't allow you to specify anything:

That doesn't mean I'm not open to it - after all we've been fiddling with the NVM too.

[robertsLando]

@AlCalzone What about also store the return routes on cache? Do you have an open issue for that?

[darkbasic]

No, that only uses the API where the controller itself decides. It doesn't allow you to specify anything

Oh, if that's the case we should figure out if it's actually possible to do so in the first place.

[AlCalzone]

It is, if we use the CC used internally by the protocol for this:

This is very close to being a hack though.

[AlCalzone]

Support is now merged into node-zwave-js master: https://github.com/zwave-js/node-zwave-js/pull/5941

The whole thing seems to be a bit fragile though, since

• priority return routes are only cleared when deleting routes (this deletes ALL return routes of a node), not when assigning new ones, which can lead to weird behavior
• some commands apparently assign new routes behind the scenes. I caught requesting a neighbor update from a node doing a new route assignment without me telling the controller to do so.

So, while routes are cached to be read back, this cache isn't really reliable.

[robertsLando]

Adding also this as reference: discoverNodeNeighbors https://github.com/zwave-js/node-zwave-js/pull/5938