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
Expose battery levels from configured split peripherals through standard Battery Service instances on the central's BLE GATT server, including host-readable and notifiable levels for each peripheral.
Add configurable battery_user_description values for the central and split peripheral Battery Level characteristics through [ble], [split.central], and [[split.peripheral]], with descriptive defaults for each battery service.
Do you have any idea why Flash/RAM increases that much for split central?
The largest avoidable cause was enabling trouble-host's 128-byte client ATT table for every split build, as you mentioned. I removed the default ATT table expansion and now generate Peripheral Battery Services only for peripherals with battery_adc_pin configured. This reduced the split central overhead as follows:
The remaining increase comes from the new GATT descriptors and, when configured, the additional Battery Service and notification handling. The common +272 B .bss in BLE builds is mainly the cost of the two new descriptors on the central Battery Level characteristic. Split peripheral builds now have no .bss increase.
The reason will be displayed to describe this comment to others. Learn more.
It looks good! I have only 1 more comment: when the split peripheral disconnects, will the battery level for peripheral be set to 0 or marked disconnected somehow?
when the split peripheral disconnects, will the battery level for peripheral be set to 0 or marked disconnected somehow?
The Battery Service does not have a standard value for "disconnected" or "unknown", and 0 means an actual 0% battery level.
Currently, the last reported battery level is kept until the central is restarted, and when the central starts up with the peripheral disconnected, the GATT Battery Level remains at its initial value of 0%, since the last reported value is only stored in RAM. This might seem inconsistent, but treating 0% as disconnected also feels unnatural to me.
How did you make it show up in the zmk-battery-center? Does it require any special configuration?
No special configuration is required; only battery_adc_pin for your split peripheral is needed (battery_user_description is optional).
Updating the GATT structure might require re-pairing the BLE host.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
resolves #710
battery_user_descriptionvalues for the central and split peripheral Battery Level characteristics through[ble],[split.central], and[[split.peripheral]], with descriptive defaults for each battery service.Testing
Tested with a split keyboard (one split peripheral), using Microsoft Bluetooth LE Explorer and zmk-battery-center and verified:
Only tested with a single peripheral. Configurations with two or more peripherals should also work but not tested.
Specification reference
This implementation follows the Bluetooth SIG Battery Service Specification v1.1, especially the requirements for multiple Battery Service instances and unique Characteristic Presentation Format Description values for each Battery Level characteristic:
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/BAS_v1.1/out/en/index-en.html