-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Feature: Split battery reporting over BLE GATT #764
Comments
I implemented this locally and unfortunately neither macOS nor Windows 11 handle multiple battery services properly. They only report the battery levels from first battery service they discover. I had services with 0x10D (left) and 0x10E (right) descriptions in their respective CPFs but only the values reported by the left service get reported. I had to write a quick swift app to retrieve the values via CoreBluetooth but I'm going to write something using either Qt or Avalonia UI to live in my system tray instead. |
That's surprising; I would expect at least macOS to support it for AirPods. I can sniff the BT traffic from my earbuds on Linux to check how Sony implemented it at least. |
Ah, Sony uses the Apple Accessories protocol for battery reporting instead of standard GATT, so no luck there. @rbitanga I'd be happy to test your changes on Linux with bluez/upower to see if it works here. |
Hey @tadfisher, I have been looking at implementing this until I saw your most recent replies. Purely for educational purposes - I realise there are OS limitations - do you have a branch where I can see your code? :) |
@PedroDiogo I also started to implement this, you can check it here, this is a POC at the moment, but I would like to create a PR soon. |
@rbitanga I opened a PR implementing this but couldn't nail down the CPFs (included only CUDs) can you please share them? |
This is implemented by #2045. |
It appears the battery service is only reporting the central device's battery level via Zephyr's built-in battery service. I'm not too knowledgeable about GATT service implementation, but it appears the battery service spec allows for multiple battery levels to be reported by implementing two services with different Characteristic Presentation Format descriptors.
I'm guessing we would need the peripheral device to report a battery level via its own service, and the central device would expose a second battery level service which passes that information through. I don't believe Zephyr supports this via the built-in battery level service, so we would have to implement the aggregate service ourselves.
The text was updated successfully, but these errors were encountered: