Does the controller have the ability to override a nodes LWR and change it?
Discussion Forums
Answered
Z-Wave
Answered
Only the Controller caches the last working route(LWR), while the slave nodes relies on the response routes, i.e. respond through the route a request was received through.
0
Are you sure that's the case with the LWR? Maybe the terminology is wrong but I thought LWR was something that each node/controller in a 700 series Plus Device contained.
Isn't the whole point of routing in a mesh network that each device has its own LWR to get a command to a node if teh node is out of range of the controller?
0
I think there's some misunderstanding about the terminology, but anyway, if a slave node is out of direct range of the controller which requires multiple hops to deliver the message. It either relies on the response route (received frames carry information on the route the response has to take back), or the controller can assign return routes to the slave so that it can send unsolicited messages.
So are you asking about how to assign return routes from the controller to a slave node?
0
We have devices in the field since 3/20 which have 7.12.2 SDK. IT looks like 7.13.3 fixed "sticky" LWR routes.
Was wondering if there was anything the controller could do until we put out a FW update with the new SDK.
What is happening is that the LWR for the nodes (or whatever you call it) is not being used and the devices are sending out explorer frames all the time.
We know we need to update the SDK but what can be done NOW by the controller software to "hide" this issue until we release newer FW.
ZWave and Explorer Frames
Does the controller have the ability to override a nodes LWR and change it?
Are you sure that's the case with the LWR? Maybe the terminology is wrong but I thought LWR was something that each node/controller in a 700 series Plus Device contained.
Isn't the whole point of routing in a mesh network that each device has its own LWR to get a command to a node if teh node is out of range of the controller?
I think there's some misunderstanding about the terminology, but anyway, if a slave node is out of direct range of the controller which requires multiple hops to deliver the message. It either relies on the response route (received frames carry information on the route the response has to take back), or the controller can assign return routes to the slave so that it can send unsolicited messages.
So are you asking about how to assign return routes from the controller to a slave node?
We have devices in the field since 3/20 which have 7.12.2 SDK. IT looks like 7.13.3 fixed "sticky" LWR routes.
Was wondering if there was anything the controller could do until we put out a FW update with the new SDK.
What is happening is that the LWR for the nodes (or whatever you call it) is not being used and the devices are sending out explorer frames all the time.
We know we need to update the SDK but what can be done NOW by the controller software to "hide" this issue until we release newer FW.