-
Notifications
You must be signed in to change notification settings - Fork 18
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
Limit request concurrency #173
base: dev
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #173 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 7 7
Lines 759 760 +1
=========================================
+ Hits 759 760 +1 ☔ View full report in Codecov by Sentry. |
I've tested this change. Unfortunately it does not solve the problem, because only tx_explicit API frames are limited, but others, such as commands and remote commands, are not. |
2b1b21f
to
6059c1e
Compare
I've reimplemented this PR on top of the unreleased zigpy priority lock/queue: pip install git+https://github.com/puddly/zigpy@zigpy/priority-lock This should deprioritize transmit commands so that any watchdog polling task would have to wait only for a single command slot to open up, as opposed to the queue being completely vacated. |
I think we need to increase the AT_COMMAND_TIMEOUT anyway. Consider the follow scenario:
|
Zigpy provides a way for radio libraries to limit request concurrency (by default 8). It seems like zigpy-xbee did not use it. You can increase/decrease the default via YAML:
@Shulyaka this may actually be the only change required for zigpy-xbee to work properly with the watchdog. If you can find a value that works well for your XBee, this may supersede #172.