Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rediscovery of ZigBeeNodes #613

Open
triller-telekom opened this issue Oct 13, 2020 · 2 comments
Open

Rediscovery of ZigBeeNodes #613

triller-telekom opened this issue Oct 13, 2020 · 2 comments

Comments

@triller-telekom
Copy link
Contributor

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:

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants