Rediscovery of ZigBeeNodes

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:

https://github.com/openhab/org.openhab.binding.zigbee/blob/696bcf9b7271b222998b639dc03075de766b1887/org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/handler/ZigBeeThingHandler.java#L224

It was introduced with https://github.com/openhab/org.openhab.binding.zigbee/pull/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 https://github.com/zsmartsystems/com.zsmartsystems.zigbee/issues/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?

Start with the rediscovery call at org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/handler/ZigBeeThingHandler.java#L224 and review the history from pull request 28. Read the linked ZSS issue about ZigbeeNetworkManager blocking, then determine whether startup rediscovery is required or should happen elsewhere. Done requires an agreed policy for rediscovery timing and validation against unreachable devices.