-
Notifications
You must be signed in to change notification settings - Fork 45
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
Resuming server notification sessions #18
Labels
external
caused by bluetoothd or kernel
Comments
BlueR exposes the full BlueZ API with respect to GATT services. Thus this seems to be a limitation of the current BlueZ API and extensions to |
Understood, thanks for the quick response! |
Probably the best way to get a quick response is to ask in BlueZ slack. I am not too familiar with the daemon myself. |
otaviojr
added a commit
to otaviojr/bluer
that referenced
this issue
May 10, 2023
# This is the 1st commit message: BLE Passive Scanning # This is the commit message #2: monitor # This is the commit message bluez#3: monitor # This is the commit message bluez#4: monitor # This is the commit message bluez#5: monitor # This is the commit message bluez#6: monitor # This is the commit message bluez#7: monitor # This is the commit message bluez#8: monitor # This is the commit message bluez#9: monitor # This is the commit message bluez#10: monitor # This is the commit message bluez#11: monitor # This is the commit message bluez#12: monitor # This is the commit message bluez#13: monitor # This is the commit message bluez#14: monitor # This is the commit message bluez#15: monitor # This is the commit message bluez#16: monitor # This is the commit message bluez#17: monitor # This is the commit message bluez#18: monitor # This is the commit message bluez#19: monitor # This is the commit message bluez#20: monitor # This is the commit message bluez#21: monitor # This is the commit message bluez#22: monitor # This is the commit message bluez#23: monitor # This is the commit message bluez#24: monitor # This is the commit message bluez#25: monitor # This is the commit message bluez#26: monitor # This is the commit message bluez#27: monitor # This is the commit message bluez#28: monitor # This is the commit message bluez#29: monitor # This is the commit message bluez#30: monitor # This is the commit message bluez#31: monitor # This is the commit message bluez#32: monitor # This is the commit message bluez#33: monitor # This is the commit message bluez#34: monitor # This is the commit message bluez#35: monitor # This is the commit message bluez#36: monitor # This is the commit message bluez#37: monitor # This is the commit message bluez#38: monitor # This is the commit message bluez#39: monitor # This is the commit message bluez#40: monitor # This is the commit message bluez#41: monitor # This is the commit message bluez#42: monitor # This is the commit message bluez#43: monitor # This is the commit message bluez#44: monitor # This is the commit message bluez#45: monitor # This is the commit message bluez#46: monitor # This is the commit message bluez#47: monitor # This is the commit message bluez#48: monitor # This is the commit message bluez#49: monitor # This is the commit message bluez#50: monitor # This is the commit message bluez#51: monitor # This is the commit message bluez#52: monitor # This is the commit message bluez#53: monitor # This is the commit message bluez#54: monitor # This is the commit message bluez#55: monitor # This is the commit message bluez#56: monitor # This is the commit message bluez#57: monitor # This is the commit message bluez#58: monitor # This is the commit message bluez#59: monitor # This is the commit message bluez#60: monitor # This is the commit message bluez#61: monitor # This is the commit message bluez#62: monitor
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm implementing battery and HID peripheral services, which require caching of CCCD state across client connections. As far as I can tell, the current behavior for both
StartNotify
andAcquireNotify
is that the notification session persists across client re-connections, but as soon as either the rust process or bluetoothd itself are restarted, there is no way to resume notifications. These services specify that the client is not required to re-enable notifications on each subsequent connection after bonding, so the client assumes that notifications will just work from there on.I thought this would be controlled by the
Cache
option inmain.conf
, but that doesn't seem to be the case, at least not across bluetoothd restarts.Is this a fundamental issue with the bluez API or is there some functionality that would enable this use case that isn't exposed in bluer?
The text was updated successfully, but these errors were encountered: