You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Corebluetooth peripheral cant be used after reconnect #413
Describe the bug
When I have a peripheral that disconnects and I later call connect on it successfully the stream returned by notifications() never produces an event.
Expected behavior
I can re-use a peripheral after it has reconnected
Actual behavior
The peripheral stops producing notifications after the first diconnect
Additional context
The log message Event receiver died, breaking out of corebluetooth device loop appears which seems to show the event handler for my peripheral dying. I am currently working around this be rescanning and getting a fresh version of the peripheral from Central.
Yes, the TX/RX channel is initialized in Peripheral::new() and cleaned up in Drop.
When disconnected, the peripheral is removed from the manager's HashMap, triggering its Drop implementation.
Doesn't this lead to a discrepancy between the peripherals in src/common/adapter_manager.rs:28 and src/corebluetooth/internal.rs:372. It doesn't look like AdapterManager ever removes peripherals. I understand the need to cleanup old connections but it feels like there should be some way to reconnect after a disconnect without scanning. Especially as I believe this is the recommended strategy for osx.
Probably the easiest option would be adding a method to disconnect_and_forget that actually cleans up the peripherals but I'm sure there is a better way to handle this scenario.
Activity
laxian commentedon Dec 11, 2024
Yes, the TX/RX channel is initialized in
Peripheral::new()and cleaned up inDrop.When disconnected, the peripheral is removed from the manager's
HashMap, triggering itsDropimplementation.saty9 commentedon Dec 11, 2024
It would be helpful if all methods return an error after that point instead of appearing to work if this is intentional
dylanowen commentedon Feb 14, 2025
Doesn't this lead to a discrepancy between the peripherals in
src/common/adapter_manager.rs:28andsrc/corebluetooth/internal.rs:372. It doesn't look likeAdapterManagerever removesperipherals. I understand the need to cleanup old connections but it feels like there should be some way to reconnect after a disconnect without scanning. Especially as I believe this is the recommended strategy for osx.Probably the easiest option would be adding a method to disconnect_and_forget that actually cleans up the peripherals but I'm sure there is a better way to handle this scenario.