-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
adapter.events() stops sending updated after while #332
Comments
With BlueZ, scanning being enabled is a system-wide property. Is it possible some other process on the system is turning off Bluetooth scanning after some time? Does it make a difference if you have your program periodically enable scanning, rather than just once when it starts? |
@qwandor The process runs as service on a server, where nothing else should be touching bluetooth. But I can't discount something is. We have used I have two tests planned for next few days:
I will report how it goes |
TLDR; I've run more tests and the result is not that promising:
Long version: I've monitored 4 versions/implementations, each for about single day. I have setup a check for number of BLE devices seen by service - if it reported 0 for 3 consecutive checks (span of 30s), the service was restarted automatically. I have run 2 instances at all times. The graph below tracks CPU usage in ticks and each colored block in graph is a new process. You can see that version in first block using Possibility that some outside process is turning the scan off does not seem likely to me anymore. First, the
The workaround seems to be to periodically call Note on performance: A side result of running all these versions and monitoring them points to some performance regressions between |
Describe the bug
I run BLE scan in long running service which provides list of seen devices over REST API by watching service discovery (no connections to device).
CentralEvent
events and can handle themExpected behavior
Events continue coming until process is terminated.
Actual behavior
Events are coming for some time, then stop. Time before that happens ranges from half-hour to several hours. Once events stop coming, they will not resume (seen several days with no event) and process restart is needed.
Additional context
There are many BLE devices around (dozens to hunderds), they come online and disappear all the time. It is unlikely that lack of events would be caused by all BLE devices disappearing at the same time.
I have checked for errors noted in #150. It did not seem DBUS limits were exceed in time. As far as I can see, there is no suspicious activity logged in any system log.
I have observed same behavior when using
bluer
crate. Sincebluer
uses DBUS too, I suspect something on that level. Unfortunately I don't have know-how to track it deeper.Versions
btleplug: v0.11.0
bluez: version: 5.66-1
os: GNU/Linux Debian (bookworm)
The text was updated successfully, but these errors were encountered: