Hey,
I'm back looking into Bluetooth LE battery reporting, and I'm a bit
stumped as to what would need to be done to add support for it.
First, I've already found a few old implementations:
- I cleaned this up a couple of years ago, to try it out, and it spit
debug information as expected. Doesn't compile anymore:
https://gfiber.googlesource.com/vendor/opensource/bluez/+/42bc327d464b1f7c2c73b3fecb2e9a8d3dc01035/profiles/battery/battery.c
- [email protected] 's "Add Battery Service GATT Client" patchset that
was posted to the list in 2012 (!)
- and finally, there's bluez' very own "bas", the last commit touching it says:
commit b6cb2d3ec320bdfdf1cdcdf750e767d214170efd
Author: Luiz Augusto von Dentz <[email protected]>
Date: Wed Nov 11 13:08:52 2015 +0200
bas: Move code from android to profiles
This is a place holder until the code is ported to use shared API so it
can be shared by android and D-Bus daemon.
That last one is compiled, but doesn't seem to be hooked up (?). I
tested this with a Microsoft Arc Touch Mouse SE (the same mouse I
tested that first patch with).
Is this all hooked up and I'd just need to export the battery
information through D-Bus?
Or does it need fixing, in which case, which plugin could I use as an
example of what porting to that elusive "shared API" should look like?
Cheers
On Thu, 2017-09-07 at 17:15 +0300, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Thu, Sep 7, 2017 at 5:03 PM, Bastien Nocera <[email protected]>
> wrote:
> > On Thu, 2017-09-07 at 01:16 +0200, Bastien Nocera wrote:
> > > On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote:
> > > > On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
> > > > >
> > > >
> > > > <snip>
> > > > > I assumed that it is forbidden to include HID battery
> > > > > reporting
> > > > > events via the GATT HID descriptors. I think the standard
> > > > > clearly
> > > > > says these have to come via battery service and not via HID.
> > > >
> > > > So we're back to implementing battery reporting as a separate
> > > > profile.
> > > > What would be a good example/skeleton to use to implement this?
> > >
> > > This is what I managed to do so far:
> > > https://github.com/hadess/bluez/commits/ble-battery
> > >
> > > A first (gentle) pass at a review would be nice, especially if
> > > there's
> > > a better way to get notifications on both the attributes in one
> > > go.
> >
> > Obviously, the reworked code I wrote at 1 AM didn't work correctly.
> > I've fixed the copy/paste bugs and pushed it.
> >
> > > The second question is how I would export this.
> > >
> > > I'm currently thinking that exporting a new interface on the
> > > device
> > > itself might be the best idea, and I'll monitor devices directly
> > > in
> > > UPower to export them to desktops. Would that be a good way?
> >
> > Still unsure about this, comments welcome.
> >
> > > And as UPower will be the likely consumer of this data, I think
> > > I'll
> > > try mapping this set of flags:
> > > https://www.bluetooth.com/specifications/gatt/viewer?attributeXml
> > > File
> > > =org.bluetooth.characteristic.battery_power_state.xml
> > > to UPower properties rather than trying to export it as-is.
> >
> > I've written parsing code for this. Does anyone know of a device
> > which
> > would use the Battery Power State characteristic so I could try it
> > out?
> >
> > Finally, I've realised that my code replicates a lot of the code in
> > bas.[ch], which is only used by the hog profile plugin. Seeing as
> > this
> > does nothing (the Battery Level is at the same level as the HoG
> > characteristics, not a child of it), I've removed it.
>
> We should probably make similar changes to what was done in dis.c so
> it can operate with gatt_db directly instead of doing its own
> discovery.
This is what I came up with:
$ gdbus introspect --system --dest org.bluez --object-path /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX --only-properties
node /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX {
<snip>
interface org.bluez.Battery1 {
properties:
readonly b Present = true;
readonly b Rechargeable = false;
readonly n Percentage = 86;
readonly s State = '';
readonly s WarningLevel = '';
};
$ gdbus monitor --system --dest org.bluez --object-path /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
Monitoring signals on object /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX owned by org.bluez
The name org.bluez is owned by :1.645
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Device1', {'Connected': <true>}, @as [])
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Present': <true>, 'Percentage': <int16 100>}, @as [])
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Device1', {'ServicesResolved': <true>, 'Paired': <true>}, @as [])
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 99>}, @as [])
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 98>}, @as [])
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX: org.freedesktop.DBus.Properties.PropertiesChanged ('org.bluez.Battery1', {'Percentage': <int16 97>}, @as [])
Code is at:
https://github.com/hadess/bluez/commits/ble-battery
I've only compile-tested the Battery State reporting, as I don't have a
device that implements it. If somebody knows of one, let me know and
I'll look into buying it for testing.
If the general code and interface are agreeable, I'll go ahead and
implement the UPower side of things, and then the API documentation for
bluez itself.
Cheers
On Thu, 2017-09-07 at 17:15 +0300, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Thu, Sep 7, 2017 at 5:03 PM, Bastien Nocera <[email protected]>
> wrote:
> > On Thu, 2017-09-07 at 01:16 +0200, Bastien Nocera wrote:
> > > On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote:
> > > > On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
> > > > >
> > > >
> > > > <snip>
> > > > > I assumed that it is forbidden to include HID battery
> > > > > reporting
> > > > > events via the GATT HID descriptors. I think the standard
> > > > > clearly
> > > > > says these have to come via battery service and not via HID.
> > > >
> > > > So we're back to implementing battery reporting as a separate
> > > > profile.
> > > > What would be a good example/skeleton to use to implement this?
> > >
> > > This is what I managed to do so far:
> > > https://github.com/hadess/bluez/commits/ble-battery
> > >
> > > A first (gentle) pass at a review would be nice, especially if
> > > there's
> > > a better way to get notifications on both the attributes in one
> > > go.
> >
> > Obviously, the reworked code I wrote at 1 AM didn't work correctly.
> > I've fixed the copy/paste bugs and pushed it.
> >
> > > The second question is how I would export this.
> > >
> > > I'm currently thinking that exporting a new interface on the
> > > device
> > > itself might be the best idea, and I'll monitor devices directly
> > > in
> > > UPower to export them to desktops. Would that be a good way?
> >
> > Still unsure about this, comments welcome.
> >
> > > And as UPower will be the likely consumer of this data, I think
> > > I'll
> > > try mapping this set of flags:
> > > https://www.bluetooth.com/specifications/gatt/viewer?attributeXml
> > > File
> > > =org.bluetooth.characteristic.battery_power_state.xml
> > > to UPower properties rather than trying to export it as-is.
> >
> > I've written parsing code for this. Does anyone know of a device
> > which
> > would use the Battery Power State characteristic so I could try it
> > out?
> >
> > Finally, I've realised that my code replicates a lot of the code in
> > bas.[ch], which is only used by the hog profile plugin. Seeing as
> > this
> > does nothing (the Battery Level is at the same level as the HoG
> > characteristics, not a child of it), I've removed it.
>
> We should probably make similar changes to what was done in dis.c so
> it can operate with gatt_db directly instead of doing its own
> discovery.
battery.c does use gatt_db already to do the initial discovery:
https://github.com/hadess/bluez/blob/ble-battery/profiles/battery/battery.c#L362
Or did you mean something else? dis.c might not be a great example, as
it doesn't use notifications.
On Thu, 2017-09-07 at 17:15 +0300, Luiz Augusto von Dentz wrote:
>
<snip>
> We should probably make similar changes to what was done in dis.c so
> it can operate with gatt_db directly instead of doing its own
> discovery.
That's doable. I'll try it out.
Hi Bastien,
On Thu, Sep 7, 2017 at 5:03 PM, Bastien Nocera <[email protected]> wrote:
> On Thu, 2017-09-07 at 01:16 +0200, Bastien Nocera wrote:
>> On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote:
>> > On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
>> > >
>> >
>> > <snip>
>> > > I assumed that it is forbidden to include HID battery reporting
>> > > events via the GATT HID descriptors. I think the standard clearly
>> > > says these have to come via battery service and not via HID.
>> >
>> > So we're back to implementing battery reporting as a separate
>> > profile.
>> > What would be a good example/skeleton to use to implement this?
>>
>> This is what I managed to do so far:
>> https://github.com/hadess/bluez/commits/ble-battery
>>
>> A first (gentle) pass at a review would be nice, especially if
>> there's
>> a better way to get notifications on both the attributes in one go.
>
> Obviously, the reworked code I wrote at 1 AM didn't work correctly.
> I've fixed the copy/paste bugs and pushed it.
>
>> The second question is how I would export this.
>>
>> I'm currently thinking that exporting a new interface on the device
>> itself might be the best idea, and I'll monitor devices directly in
>> UPower to export them to desktops. Would that be a good way?
>
> Still unsure about this, comments welcome.
>
>> And as UPower will be the likely consumer of this data, I think I'll
>> try mapping this set of flags:
>> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile
>> =org.bluetooth.characteristic.battery_power_state.xml
>> to UPower properties rather than trying to export it as-is.
>
> I've written parsing code for this. Does anyone know of a device which
> would use the Battery Power State characteristic so I could try it out?
>
> Finally, I've realised that my code replicates a lot of the code in
> bas.[ch], which is only used by the hog profile plugin. Seeing as this
> does nothing (the Battery Level is at the same level as the HoG
> characteristics, not a child of it), I've removed it.
We should probably make similar changes to what was done in dis.c so
it can operate with gatt_db directly instead of doing its own
discovery.
--
Luiz Augusto von Dentz
On Thu, 2017-09-07 at 01:16 +0200, Bastien Nocera wrote:
> On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote:
> > On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
> > >
> >
> > <snip>
> > > I assumed that it is forbidden to include HID battery reporting
> > > events via the GATT HID descriptors. I think the standard clearly
> > > says these have to come via battery service and not via HID.
> >
> > So we're back to implementing battery reporting as a separate
> > profile.
> > What would be a good example/skeleton to use to implement this?
>
> This is what I managed to do so far:
> https://github.com/hadess/bluez/commits/ble-battery
>
> A first (gentle) pass at a review would be nice, especially if
> there's
> a better way to get notifications on both the attributes in one go.
Obviously, the reworked code I wrote at 1 AM didn't work correctly.
I've fixed the copy/paste bugs and pushed it.
> The second question is how I would export this.
>
> I'm currently thinking that exporting a new interface on the device
> itself might be the best idea, and I'll monitor devices directly in
> UPower to export them to desktops. Would that be a good way?
Still unsure about this, comments welcome.
> And as UPower will be the likely consumer of this data, I think I'll
> try mapping this set of flags:
> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile
> =org.bluetooth.characteristic.battery_power_state.xml
> to UPower properties rather than trying to export it as-is.
I've written parsing code for this. Does anyone know of a device which
would use the Battery Power State characteristic so I could try it out?
Finally, I've realised that my code replicates a lot of the code in
bas.[ch], which is only used by the hog profile plugin. Seeing as this
does nothing (the Battery Level is at the same level as the HoG
characteristics, not a child of it), I've removed it.
Cheers
On Wed, 2017-09-06 at 16:37 +0200, Bastien Nocera wrote:
> On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
> >
>
> <snip>
> > I assumed that it is forbidden to include HID battery reporting
> > events via the GATT HID descriptors. I think the standard clearly
> > says these have to come via battery service and not via HID.
>
> So we're back to implementing battery reporting as a separate
> profile.
> What would be a good example/skeleton to use to implement this?
This is what I managed to do so far:
https://github.com/hadess/bluez/commits/ble-battery
A first (gentle) pass at a review would be nice, especially if there's
a better way to get notifications on both the attributes in one go.
The second question is how I would export this.
I'm currently thinking that exporting a new interface on the device
itself might be the best idea, and I'll monitor devices directly in
UPower to export them to desktops. Would that be a good way?
And as UPower will be the likely consumer of this data, I think I'll
try mapping this set of flags:
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.battery_power_state.xml
to UPower properties rather than trying to export it as-is.
Cheers
On Wed, 2017-09-06 at 10:40 +0200, Marcel Holtmann wrote:
>
<snip>
> I assumed that it is forbidden to include HID battery reporting
> events via the GATT HID descriptors. I think the standard clearly
> says these have to come via battery service and not via HID.
So we're back to implementing battery reporting as a separate profile.
What would be a good example/skeleton to use to implement this?
Hi Luiz,
>>>> I'm back looking into Bluetooth LE battery reporting, and I'm a bit
>>>> stumped as to what would need to be done to add support for it.
>>>>
>>>> First, I've already found a few old implementations:
>>>>
>>>> - I cleaned this up a couple of years ago, to try it out, and it spit
>>>> debug information as expected. Doesn't compile anymore:
>>>> https://gfiber.googlesource.com/vendor/opensource/bluez/+/42bc327d464b1f7c2c73b3fecb2e9a8d3dc01035/profiles/battery/battery.c
>>>>
>>>> - [email protected] 's "Add Battery Service GATT Client" patchset that
>>>> was posted to the list in 2012 (!)
>>>>
>>>> - and finally, there's bluez' very own "bas", the last commit touching it says:
>>>> commit b6cb2d3ec320bdfdf1cdcdf750e767d214170efd
>>>> Author: Luiz Augusto von Dentz <[email protected]>
>>>> Date: Wed Nov 11 13:08:52 2015 +0200
>>>>
>>>> bas: Move code from android to profiles
>>>>
>>>> This is a place holder until the code is ported to use shared API so it
>>>> can be shared by android and D-Bus daemon.
>>>>
>>>> That last one is compiled, but doesn't seem to be hooked up (?). I
>>>> tested this with a Microsoft Arc Touch Mouse SE (the same mouse I
>>>> tested that first patch with).
>>>>
>>>> Is this all hooked up and I'd just need to export the battery
>>>> information through D-Bus?
>>>>
>>>> Or does it need fixing, in which case, which plugin could I use as an
>>>> example of what porting to that elusive "shared API" should look like?
>>>>
>>>> Cheers
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> I think this should be done as "virtual" battery and reported to
>>> system via standard means (upower?).
>>>
>>> I was wondering it would be done in similar way uhid is designed (other option
>>> would be bluez registering battery via D-Bus API in upower if such API
>>> exists...)
>>
>> for LE HID devices we could just convert their battery service into HID battery events. For non-HID devices, we could create a HID device via uhid anyway and just expose only battery information.
>
> You mean we create USB reports for the battery status? While this is
> possible what if the remote is also doing this already, it would be
> quite hard to detect this but perhaps it is fine since the values
> should be consistent. For non-HID devices that sound pretty easy to do
> though perhaps having the a Battery property in the Device interface
> wouldn't be a bad idea either as that may be more convenient for D-Bus
> clients to read.
I assumed that it is forbidden to include HID battery reporting events via the GATT HID descriptors. I think the standard clearly says these have to come via battery service and not via HID.
Regards
Marcel
Hi Marcel,
On Tue, Sep 5, 2017 at 8:44 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Szymon,
>
>>> I'm back looking into Bluetooth LE battery reporting, and I'm a bit
>>> stumped as to what would need to be done to add support for it.
>>>
>>> First, I've already found a few old implementations:
>>>
>>> - I cleaned this up a couple of years ago, to try it out, and it spit
>>> debug information as expected. Doesn't compile anymore:
>>> https://gfiber.googlesource.com/vendor/opensource/bluez/+/42bc327d464b1f7c2c73b3fecb2e9a8d3dc01035/profiles/battery/battery.c
>>>
>>> - [email protected] 's "Add Battery Service GATT Client" patchset that
>>> was posted to the list in 2012 (!)
>>>
>>> - and finally, there's bluez' very own "bas", the last commit touching it says:
>>> commit b6cb2d3ec320bdfdf1cdcdf750e767d214170efd
>>> Author: Luiz Augusto von Dentz <[email protected]>
>>> Date: Wed Nov 11 13:08:52 2015 +0200
>>>
>>> bas: Move code from android to profiles
>>>
>>> This is a place holder until the code is ported to use shared API so it
>>> can be shared by android and D-Bus daemon.
>>>
>>> That last one is compiled, but doesn't seem to be hooked up (?). I
>>> tested this with a Microsoft Arc Touch Mouse SE (the same mouse I
>>> tested that first patch with).
>>>
>>> Is this all hooked up and I'd just need to export the battery
>>> information through D-Bus?
>>>
>>> Or does it need fixing, in which case, which plugin could I use as an
>>> example of what porting to that elusive "shared API" should look like?
>>>
>>> Cheers
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> I think this should be done as "virtual" battery and reported to
>> system via standard means (upower?).
>>
>> I was wondering it would be done in similar way uhid is designed (other option
>> would be bluez registering battery via D-Bus API in upower if such API
>> exists...)
>
> for LE HID devices we could just convert their battery service into HID battery events. For non-HID devices, we could create a HID device via uhid anyway and just expose only battery information.
You mean we create USB reports for the battery status? While this is
possible what if the remote is also doing this already, it would be
quite hard to detect this but perhaps it is fine since the values
should be consistent. For non-HID devices that sound pretty easy to do
though perhaps having the a Battery property in the Device interface
wouldn't be a bad idea either as that may be more convenient for D-Bus
clients to read.
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
Hi Szymon,
>> I'm back looking into Bluetooth LE battery reporting, and I'm a bit
>> stumped as to what would need to be done to add support for it.
>>
>> First, I've already found a few old implementations:
>>
>> - I cleaned this up a couple of years ago, to try it out, and it spit
>> debug information as expected. Doesn't compile anymore:
>> https://gfiber.googlesource.com/vendor/opensource/bluez/+/42bc327d464b1f7c2c73b3fecb2e9a8d3dc01035/profiles/battery/battery.c
>>
>> - [email protected] 's "Add Battery Service GATT Client" patchset that
>> was posted to the list in 2012 (!)
>>
>> - and finally, there's bluez' very own "bas", the last commit touching it says:
>> commit b6cb2d3ec320bdfdf1cdcdf750e767d214170efd
>> Author: Luiz Augusto von Dentz <[email protected]>
>> Date: Wed Nov 11 13:08:52 2015 +0200
>>
>> bas: Move code from android to profiles
>>
>> This is a place holder until the code is ported to use shared API so it
>> can be shared by android and D-Bus daemon.
>>
>> That last one is compiled, but doesn't seem to be hooked up (?). I
>> tested this with a Microsoft Arc Touch Mouse SE (the same mouse I
>> tested that first patch with).
>>
>> Is this all hooked up and I'd just need to export the battery
>> information through D-Bus?
>>
>> Or does it need fixing, in which case, which plugin could I use as an
>> example of what porting to that elusive "shared API" should look like?
>>
>> Cheers
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I think this should be done as "virtual" battery and reported to
> system via standard means (upower?).
>
> I was wondering it would be done in similar way uhid is designed (other option
> would be bluez registering battery via D-Bus API in upower if such API
> exists...)
for LE HID devices we could just convert their battery service into HID battery events. For non-HID devices, we could create a HID device via uhid anyway and just expose only battery information.
Regards
Marcel
Hi Bastien,
On 5 September 2017 at 18:03, Bastien Nocera <[email protected]> wrote:
> Hey,
>
> I'm back looking into Bluetooth LE battery reporting, and I'm a bit
> stumped as to what would need to be done to add support for it.
>
> First, I've already found a few old implementations:
>
> - I cleaned this up a couple of years ago, to try it out, and it spit
> debug information as expected. Doesn't compile anymore:
> https://gfiber.googlesource.com/vendor/opensource/bluez/+/42bc327d464b1f7c2c73b3fecb2e9a8d3dc01035/profiles/battery/battery.c
>
> - [email protected] 's "Add Battery Service GATT Client" patchset that
> was posted to the list in 2012 (!)
>
> - and finally, there's bluez' very own "bas", the last commit touching it says:
> commit b6cb2d3ec320bdfdf1cdcdf750e767d214170efd
> Author: Luiz Augusto von Dentz <[email protected]>
> Date: Wed Nov 11 13:08:52 2015 +0200
>
> bas: Move code from android to profiles
>
> This is a place holder until the code is ported to use shared API so it
> can be shared by android and D-Bus daemon.
>
> That last one is compiled, but doesn't seem to be hooked up (?). I
> tested this with a Microsoft Arc Touch Mouse SE (the same mouse I
> tested that first patch with).
>
> Is this all hooked up and I'd just need to export the battery
> information through D-Bus?
>
> Or does it need fixing, in which case, which plugin could I use as an
> example of what porting to that elusive "shared API" should look like?
>
> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I think this should be done as "virtual" battery and reported to
system via standard means (upower?).
I was wondering it would be done in similar way uhid is designed (other option
would be bluez registering battery via D-Bus API in upower if such API
exists...)
--
pozdrawiam
Szymon K. Janc