Separate timeout option for BT Classic commands #179
Comments
# [2.9.0-beta.1](v2.8.2...v2.9.0-beta.1) (2020-08-16) ### Features * **bluetooth-classic:** add option for preserving sensor state ([7cd2afe](7cd2afe)), closes [#156](#156) * **bluetooth-classic:** add scan time limit option ([ae40009](ae40009)), closes [#179](#179) * **home-assistant:** refresh states after broker re-connect ([85064e6](85064e6)), closes [#218](#218)
|
🎉 This issue has been resolved in version 2.9.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Is there any additional configuration needed to set this lower timeout, or is there a default that will just work after installing the beta? Edit: I found it in the commit notes, the config is scanTimeLimit and looks like it has a default of 2 seconds |
|
Just wanted to say this seems to be working well for me. Typically before this unless there was at least one device in range the pi zero w might as well have not been on the network. no response to pings, no ssh access until you gave it a device. No it seem fine (only tested for about 8 hours so far, so not sure of any long term ill effects, but looking good!). |
# [2.9.0](v2.8.2...v2.9.0) (2020-08-23) ### Bug Fixes * **bluetooth-classic:** exclude old measurements from preservation ([10b0e21](10b0e21)) ### Features * **bluetooth-classic:** add option for preserving sensor state ([7cd2afe](7cd2afe)), closes [#156](#156) * **bluetooth-classic:** add scan time limit option ([ae40009](ae40009)), closes [#179](#179) * **home-assistant:** refresh states after broker re-connect ([85064e6](85064e6)), closes [#218](#218)
|
🎉 This issue has been resolved in version 2.9.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Is your feature request related to a problem? Please describe.
Pis share Bluetooth and WiFi on a single chip, which means Bluetooth communication blocks WiFi communication. The default interval of 6s leaves only very little time for network calls and leads to sluggish SSH sessions and Pis going unavailable. See also #178 for an example.
Describe the solution you'd like
At the moment the timeout for
hcitoolis set based on the interval and some leeway. If we could set the timeout as a separate option we could reduce the actual communication time down to what is realistically needed in most cases (about 2-3s) to leave some more room for the WiFi packets to come through.Describe alternatives you've considered
Additional context
Shortening the timeout to below the default timeout of
hcitoolrequires forceful kills of the process, which might mess up the Pi or the integration when left running for some time. This needs to be tested before a release to the public.The text was updated successfully, but these errors were encountered: