Rediscovery of ZigBeeNodes

[triller-telekom]

I was analyzing some issues in the past, regarding delays of various zigbee transactions in the framework.

What I noticed is that on startup, this is worse than during normal operation.

I found a line that would explain this:

org.openhab.binding.zigbee/org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/handler/ZigBeeThingHandler.java

Line 224 in 696bcf9

coordinatorHandler.rediscoverNode(nodeIeeeAddress);

It was introduced with #28, so it exists since a very long time already. As long as all devices are reachable with power and full batteries, this is not a problem on startup.

However, if there are non reachable devices, we will retry the network address requests multiple times until we finally give up. Since failures are retried before other commands (and if multiple devices are not causing such failures), they are blocking tasks within the thread pool of the ZigbeeNetworkManager, see zsmartsystems/com.zsmartsystems.zigbee#1153 where such a blocking occurs already within ZSS.

I tried to find in the ZigBee specifications WHEN a node changes its network address, but haven't found answers other than "may do so at any time".

Now I am wondering whether it makes sense to start such a rediscovery for all paired devices on EVERY startup, or if we should do this at a different place.

For testing purposes, my current setup does not contain the rediscovery and I have between 5-10 devices paired and I am restarting the zigbee bundles multiple times per day. So far, I didn't find any issues.

So, do we need this rediscovery? If we need it, do we really need it on every startup?

[cdjackson]

Sorry @triller-telekom for not getting back to you sooner on this and the related issue - I've been away on holiday in the far north of Scotland and internet access etc has been scetchy.

This was originally added as people were having a lot of problems with devices on startup. Devices could not be found - possibly because the data store had been removed, or was somehow corrupt.

I do agree though that this could be managed better, and probably this is not required. Possibly we should only do this if the ZigBeeNode is not found for the IeeeAddress.

There are a couple of improvements I'd like to do in the discovery area - reduction of broadcasts was part of it, and for example zsmartsystems/com.zsmartsystems.zigbee#1108 is another. If you want to take a look at some of these @triller-telekom that would be appreciated.

[triller-telekom]

No worries, I hope you enjoyed your vacation. Mine is going to start tomorrow :)

I do agree though that this could be managed better, and probably this is not required. Possibly we should only do this if the ZigBeeNode is not found for the IeeeAddress.

Yes, this makes sense, as we will get rid of a lot of unnecessary network address requests this way.

There are a couple of improvements I'd like to do in the discovery area - reduction of broadcasts was part of it, and for example zsmartsystems/com.zsmartsystems.zigbee#1108 is another

The plan is to proceed with zsmartsystems/com.zsmartsystems.zigbee#1153 after my vacation.