---
lib/bluetooth.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/lib/bluetooth.c b/lib/bluetooth.c
index d48d844..dad37fa 100644
--- a/lib/bluetooth.c
+++ b/lib/bluetooth.c
@@ -1635,6 +1635,118 @@ const char *bt_compidtostr(int compid)
return "Rx Networks, Inc.";
case 686:
return "WeatherFlow, Inc.";
+ case 687:
+ return "Technicolor USA Inc.";
+ case 688:
+ return "Bestechnic(Shanghai),Ltd";
+ case 689:
+ return "Raden Inc";
+ case 690:
+ return "JouZen Oy";
+ case 691:
+ return "CLABER S.P.A.";
+ case 692:
+ return "Hyginex, Inc.";
+ case 693:
+ return "HANSHIN ELECTRIC RAILWAY CO.,LTD.";
+ case 694:
+ return "Schneider Electric";
+ case 695:
+ return "Oort Technologies LLC";
+ case 696:
+ return "Chrono Therapeutics";
+ case 697:
+ return "Rinnai Corporation";
+ case 698:
+ return "Swissprime Technologies AG";
+ case 699:
+ return "Koha.,Co.Ltd";
+ case 700:
+ return "Genevac Ltd";
+ case 701:
+ return "Chemtronics";
+ case 702:
+ return "Seguro Technology Sp. z o.o.";
+ case 703:
+ return "Redbird Flight Simulations";
+ case 704:
+ return "Dash Robotics";
+ case 705:
+ return "LINE Corporation";
+ case 706:
+ return "Guillemot Corporation";
+ case 707:
+ return "Techtronic Power Tools Technology Limited";
+ case 708:
+ return "Wilson Sporting Goods";
+ case 709:
+ return "Lenovo (Singapore) Pte Ltd. ( 联想（新加坡） )";
+ case 710:
+ return "Ayatan Sensors";
+ case 711:
+ return "Electronics Tomorrow Limited";
+ case 712:
+ return "VASCO Data Security International, Inc.";
+ case 713:
+ return "PayRange Inc.";
+ case 714:
+ return "ABOV Semiconductor";
+ case 715:
+ return "AINA-Wireless Inc.";
+ case 716:
+ return "Eijkelkamp Soil & Water";
+ case 717:
+ return "BMA ergonomics b.v.";
+ case 718:
+ return "Teva Branded Pharmaceutical Products R&D, Inc.";
+ case 719:
+ return "Anima";
+ case 720:
+ return "3M":
+ case 721:
+ return "Empatica Srl";
+ case 722:
+ return "Afero, Inc.";
+ case 723:
+ return "Powercast Corporation";
+ case 724:
+ return "Secuyou ApS";
+ case 725:
+ return "OMRON Corporation";
+ case 726:
+ return "Send Solutions";
+ case 727:
+ return "NIPPON SYSTEMWARE CO.,LTD.";
+ case 728:
+ return "Neosfar";
+ case 729:
+ return "Fliegl Agrartechnik GmbH":
+ case 730:
+ return "Gilvader";
+ case 731:
+ return "Digi International Inc (R)";
+ case 732:
+ return "DeWalch Technologies, Inc.";
+ case 733:
+ return "Flint Rehabilitation Devices, LLC";
+ case 734:
+ return "Samsung SDS Co., Ltd.";
+ case 735:
+ return "Blur Product Development";
+ case 736:
+ return "University of Michigan";
+ case 737:
+ return "Victron Energy BV";
+ case 738:
+ return "NTT docomo";
+ case 739:
+ return "Carmanah Technologies Corp.";
+ case 740:
+ return "Bytestorm Ltd.";
+ case 741:
+ return "Espressif Incorporated ( 乐鑫信息科技(上海)有限公司 )";
+ case 742:
+ return "Unwire";
case 65535:
return "internal use";
default:
--
1.9.1
Hi Travis,
> I hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
>
> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
>
> I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
>
> I *think* I’ve discerned that there may be 3 different ways I could do this?
>
> 1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
this will work and you could use HCI User Channel direct access to HCI, but that means you have to do a lot of work for writing a BLE peripheral.
> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
If you refer to libbluetooth, then do not even bother with that. That library is deprecated. It also is as low-level as directly using HCI User Channel.
> 3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
This would be the easiest way since all the GATT details are handled for you.
> I get that I’ve got some learning to do, I’m looking for some guidance on which of the 3 above to bite off. I’d hate to spend a bunch of time figuring out #2 and then get told “oh, that’s the old way of doing it, you should have gone the other route.”
>
> I would be indebted for any code samples or for any general approach examples. Even if its just a link that my google skills did not find. If there are guns-for-hire lurking here, I’d probably be even to scrape together some cash to pay someone to help us bootstrap our efforts here.
>
> My BLE experience to date involves getting to know the iOS APIs, and having worked with the STMicro BlueNRGs ACI interface in a very embedded form.
If you look into the peripheral/ directory you find an example on how to use the kernel sockets and generic code in src/shared/ to link it into a single and simple BLE peripheral.
Regards
Marcel
Hello Travis,
On 18 December 2015 at 17:22, Gowtham Anandha Babu <[email protected]> wrote:
> Hi Travis,
>
> On 18 December 2015 at 21:51, Travis Griggs <[email protected]> wrote:
>> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral.
>> I’m running Debian Jessie, and build 5.36 of the bluez stack.
I'm trying to do a similar thing with a Raspberry Pi. Although right
now I'm making more progress with the RPi in the central role rather
than a peripheral.
>> I *think* I’ve discerned that there may be 3 different ways I could do this?
>> 1) Just use the hcitool/hciconfig command line tools.
>> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff.
>> 3) There’s a dbus interface. I appear to have dbus running on my device.
I'm currently exploring your option number 3 using Python as I want to
take advantage to the numerous Python libraries for RPi peripherals.
> I am not that much familiar with embedded. But I tried below things in Ubuntu.
> There are few python scripts in bluez git tree which is using DBus interface.
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-advertisement
>
> 1) Run bluetoothd with experimental flag enabled (# sudo ./src/bluetoothd -ndE).
> 2) Run the above mentioned script.
> 3) # ./test/example-gatt-server -- it exposes 3 services.
> 4) # ./test/example-advertisement -- it will advertise a sample data.
> 5) Finally you can capture these via your phone app.
>
> You can edit those python scripts to meet your needs.
>
> This is very basic information. Let others comment on this.
I would agree with Gowtham that this is a good approach or at least
the one I'm following.
DBus and GObject are new to me and I found the following stackoverflow
article helpful:
http://stackoverflow.com/questions/33428804/role-of-mainloops-event-loops-in-dbus-service
The goal of my experiments is to get an open source library so school
children can easily code things like:
https://youtu.be/1ZvFdX5bA8k so if you do get something that you can
share I'd be interested.
Another idea you might want to explore is using the CLI client,
bluetoothctl. There are a few bits about it around and I've done a
short video of my experiments:
https://youtu.be/fEx2V5y-Egk
I hope some of that helps.
Regards,
Barry
Hi Travis,
On 18 December 2015 at 21:51, Travis Griggs <[email protected]> wrote:
>
> I hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
>
> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
>
> I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
>
> I *think* I’ve discerned that there may be 3 different ways I could do this?
>
> 1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
>
> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
>
> 3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
>
I am not that much familiar with embedded. But I tried below things in Ubuntu.
There are few python scripts in bluez git tree which is using DBus interface.
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-advertisement
1) Run bluetoothd with experimental flag enabled (# sudo ./src/bluetoothd -ndE).
2) Run the above mentioned script.
3) # ./test/example-gatt-server -- it exposes 3 services.
4) # ./test/example-advertisement -- it will advertise a sample data.
5) Finally you can capture these via your phone app.
You can edit those python scripts to meet your needs.
This is very basic information. Let others comment on this.
>
> I get that I’ve got some learning to do, I’m looking for some guidance on which of the 3 above to bite off. I’d hate to spend a bunch of time figuring out #2 and then get told “oh, that’s the old way of doing it, you should have gone the other route.”
>
> I would be indebted for any code samples or for any general approach examples. Even if its just a link that my google skills did not find. If there are guns-for-hire lurking here, I’d probably be even to scrape together some cash to pay someone to help us bootstrap our efforts here.
>
> My BLE experience to date involves getting to know the iOS APIs, and having worked with the STMicro BlueNRGs ACI interface in a very embedded form.
>
> Again, sorry if this is the wrong list, if there is a better place to seek for some guidance, please let me know.
>
> Thanks In Advance
>
>
> --
> 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
--
Gowtham.A
Hi Travis-
By far, the easiest way to accomplish what you're trying to do is to
use Node.js and a library called Bleno. If you are inexperienced,
it's easier to use Bleno to do what you're trying to do; and if you
need to control a C application, then you'd have to do some kind of
IPC between your Bluetooth communications app and your main app.
Having said that, there is a platform that will be much more friendly
to what you are doing (at least as far as Bluetooth is concerned).
Check out the Intel Edison. Using tools provided for free by Intel,
you can have a BLE peripheral set up on an Edison in around an hour or
so. They have comprehensive examples on how to do this. You can
expect to pay around $60 for an Edison and a breakout board that is
required for its operation.
--JK
On Fri, Dec 18, 2015 at 11:21 AM, Travis Griggs <[email protected]> wrote:
> I hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
>
> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
>
> I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
>
> I *think* I’ve discerned that there may be 3 different ways I could do this?
>
> 1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
>
> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
>
> 3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
>
> I get that I’ve got some learning to do, I’m looking for some guidance on which of the 3 above to bite off. I’d hate to spend a bunch of time figuring out #2 and then get told “oh, that’s the old way of doing it, you should have gone the other route.”
>
> I would be indebted for any code samples or for any general approach examples. Even if its just a link that my google skills did not find. If there are guns-for-hire lurking here, I’d probably be even to scrape together some cash to pay someone to help us bootstrap our efforts here.
>
> My BLE experience to date involves getting to know the iOS APIs, and having worked with the STMicro BlueNRGs ACI interface in a very embedded form.
>
> Again, sorry if this is the wrong list, if there is a better place to seek for some guidance, please let me know.
>
> Thanks In Advance
>
>
> --
> 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 hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
I *think* I’ve discerned that there may be 3 different ways I could do this?
1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
I get that I’ve got some learning to do, I’m looking for some guidance on which of the 3 above to bite off. I’d hate to spend a bunch of time figuring out #2 and then get told “oh, that’s the old way of doing it, you should have gone the other route.”
I would be indebted for any code samples or for any general approach examples. Even if its just a link that my google skills did not find. If there are guns-for-hire lurking here, I’d probably be even to scrape together some cash to pay someone to help us bootstrap our efforts here.
My BLE experience to date involves getting to know the iOS APIs, and having worked with the STMicro BlueNRGs ACI interface in a very embedded form.
Again, sorry if this is the wrong list, if there is a better place to seek for some guidance, please let me know.
Thanks In Advance
Hello Travis,
On 8 January 2016 at 21:37, Travis Griggs <[email protected]> wrote:
>
>> On Dec 18, 2015, at 9:22 AM, Gowtham Anandha Babu <[email protected]> wrote:
>>
>> Hi Travis,
>>
>> On 18 December 2015 at 21:51, Travis Griggs <[email protected]> wrote:
>>>
>>> I hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
>>>
>>> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
>>>
>>> I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
>>>
>>> I *think* I’ve discerned that there may be 3 different ways I could do this?
>>>
>>> 1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
>>>
>>> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
>>>
>>> 3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
>>>
>>
>> I am not that much familiar with embedded. But I tried below things in Ubuntu.
>> There are few python scripts in bluez git tree which is using DBus interface.
>> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server
>> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-advertisement
>>
>> 1) Run bluetoothd with experimental flag enabled (# sudo ./src/bluetoothd -ndE).
>> 2) Run the above mentioned script.
>> 3) # ./test/example-gatt-server -- it exposes 3 services.
>> 4) # ./test/example-advertisement -- it will advertise a sample data.
>> 5) Finally you can capture these via your phone app.
>>
>> You can edit those python scripts to meet your needs.
>>
>> This is very basic information. Let others comment on this.
>
> First of all, belated thanks to Gowtham and the others. I didn’t make immediate progress because of holidays and other distractions, but once I got at this, have been able to make _some_ progress quick.
>
> I changed my bluetooth.service to include the -E option. And I took the example-gatt-server and example-advertisement and started molding/shaping. In both cases, I’ve been able to python3ize them, and can now see it advertised as well as see my single service.
>
> My single service has a single characteristic that I’m trying to configure as a [‘write’, ‘notify’]. Both Service and Characteristic are “custom” with 128bit UUIDs. I’ve been using the iOS LightBlue app to connect to it. Which it does. When I cause a WriteValue() to occur on my Characteristic, I can see debug info from print() statements, but it doesn’t seem to send methods to the object. The iOS app prints back something like:
>
> “Characteristic Notified”
> “No User Description”
> “No value”
>
> My subclasses for Characteristic/Service look like:
>
> class MainService(Service):
> UUID = '00000000-08af-41c0-8048-4215e1560a37'
>
> def __init__(self, bus, index):
> super().__init__(bus, index, self.UUID, True)
> self.add_characteristic(DataStreamCharacteristic(bus, 0, self))
>
>
> class DataStreamCharacteristic(Characteristic):
> UUID = '00000001-08af-41c0-8048-4215e1560a37'
>
> def __init__(self, bus, index, service):
> super().__init__(bus, index, self.UUID, ['write', 'notify'], service)
> self.sendBuffer = []
>
> def _foo_send1(self, byte): # I USED A WEIRD NAME BECAUSE I WONDERED IF THERE WAS SOME RESERVED THING GOING ON
> print('appending:', byte, type(byte)) # THIS NEVER SHOWS UP
> self.sendBuffer.append(dbus.Byte(byte))
> print('sendBuffer:', self.sendBuffer) # THIS NEVER SHOWS UP EITHER
> if len(self.sendBuffer) == 20:
> self.flush()
>
> def flush(self):
> print('flushing:', self.sendBuffer)
> self.PropertiesChanged(GATT_CHRC_IFACE, {'Value': self.sendBuffer}, [])
> self.sendBuffer[:] = []
>
> def WriteValue(self, value):
> print('write:', value) # THIS SHOWS AN ARRAY WITH THE VALUE THE APP SUPPOSEDLY WROTE
> for byte in value:
> print('got byte:', 0 + byte) # THIS SHOWS UP _ONCE_
> print('sending byte:', 255 - byte) # THIS SHOWS UP _ONCE_
> self._foo_send1(255 - value) # BUT I QUESTION WHETHER THIS EVER HAPPENS, SEE ABOVE
>
> def StartNotify(self):
> pass
>
> def StopNotify(self):
> pass
>
> The ALLCAPS comments in the code above show what happens when the WriteValue() method is apparently called. I’m completely confused as to what’s going on here. Is this some sort of nuance with the dbus/gobject bindings?
>
> I’m also wondering if I need to be doing something to set up some sort of Descriptors? I admit I’m fuzzy on what the descriptors do and how they work. The previous 2 experiences I’ve had with BLE, the descriptors seemed to be automagically managed.
I'm not sure if I can directly help you on this. However I did want to
point you towards a resource that might help you.
Martin Woolley (from the BluetoothSIG) has a good video that tries to
explain about how services, characteristics and descriptors interact
at https://youtu.be/auApsoMHxtA?list=PL2c6RSvzuF5EmNckwoKYhDUi0O7kDQiaL
There is a problem with the audio for the first few minutes but stick with it.
He also talks about a tool (Bluetooth Developer Studio) to help people
create services etc. I've not looked at the tool myself but seemed
useful from his demo.
I'm also new to using BLE and struggling with the lack of good Python
examples. I've had some success with reading Battery Services and
creating an Eddystone URL beacon using the Bluez DBus API. My plan is
to clean my experiments up and put them at
https://github.com/ukBaz/python-bluezero under an MIT license as
examples for others. Hopefully the library will have an API that will
save people from doing the same boilerplate code over and over again.
There is nothing there at the moment but please keep an eye on the
repository and if you can contribute with what you have learnt it
would be appreciated.
Regards,
Barry
> On Dec 18, 2015, at 9:22 AM, Gowtham Anandha Babu <[email protected]> wrote:
>
> Hi Travis,
>
> On 18 December 2015 at 21:51, Travis Griggs <[email protected]> wrote:
>>
>> I hope this question isn’t completely out of order here… I’ve been lurking for a week or so, and it seems the list is mostly patch submission/discussion.
>>
>> I’m working with a small Linux ARM SBC (similar to a Raspberry Pi), trying to set it up as a BLE peripheral. I’m running Debian Jessie, and build 5.36 of the bluez stack.
>>
>> I’m relatively new to the bluez stack. I’ve been able to follow some SO posts and such to poke a couple of hciconfig commands to get my device advertising so that I can scan it with a phone app, and even changed its advertised name by tweaking one of the bluetoothd .conf files. But getting past that, I’m not sure really where to go. I want to set up a single service and characteristic with notify/write so that I can communicate with it via my phone app.
>>
>> I *think* I’ve discerned that there may be 3 different ways I could do this?
>>
>> 1) Just use the hcitool/hciconfig command line tools. Work out all the hairy details of the various HCI command bytes, and write a script or something that just calls these command line tools. Not sure how I would be notified when a characteristic had been updated.
>>
>> 2) There’s a C library. So write a C program that cross compiles for the ARM, including the ARM headers for the bluez stuff. I have not seen a rigorous reference document for these APIs. I’m assuming it’s “use the source Luke”.
>>
>> 3) There’s a dbus interface. I appear to have dbus running on my device. But I have zero experience with interfacing with dbus, and I have yet to find any overview of what the bluez-dbus protocols look like. Would this be more general to weld a python3 script to though?
>>
>
> I am not that much familiar with embedded. But I tried below things in Ubuntu.
> There are few python scripts in bluez git tree which is using DBus interface.
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-advertisement
>
> 1) Run bluetoothd with experimental flag enabled (# sudo ./src/bluetoothd -ndE).
> 2) Run the above mentioned script.
> 3) # ./test/example-gatt-server -- it exposes 3 services.
> 4) # ./test/example-advertisement -- it will advertise a sample data.
> 5) Finally you can capture these via your phone app.
>
> You can edit those python scripts to meet your needs.
>
> This is very basic information. Let others comment on this.
First of all, belated thanks to Gowtham and the others. I didn’t make immediate progress because of holidays and other distractions, but once I got at this, have been able to make _some_ progress quick.
I changed my bluetooth.service to include the -E option. And I took the example-gatt-server and example-advertisement and started molding/shaping. In both cases, I’ve been able to python3ize them, and can now see it advertised as well as see my single service.
My single service has a single characteristic that I’m trying to configure as a [‘write’, ‘notify’]. Both Service and Characteristic are “custom” with 128bit UUIDs. I’ve been using the iOS LightBlue app to connect to it. Which it does. When I cause a WriteValue() to occur on my Characteristic, I can see debug info from print() statements, but it doesn’t seem to send methods to the object. The iOS app prints back something like:
“Characteristic Notified”
“No User Description”
“No value”
My subclasses for Characteristic/Service look like:
class MainService(Service):
UUID = '00000000-08af-41c0-8048-4215e1560a37'
def __init__(self, bus, index):
super().__init__(bus, index, self.UUID, True)
self.add_characteristic(DataStreamCharacteristic(bus, 0, self))
class DataStreamCharacteristic(Characteristic):
UUID = '00000001-08af-41c0-8048-4215e1560a37'
def __init__(self, bus, index, service):
super().__init__(bus, index, self.UUID, ['write', 'notify'], service)
self.sendBuffer = []
def _foo_send1(self, byte): # I USED A WEIRD NAME BECAUSE I WONDERED IF THERE WAS SOME RESERVED THING GOING ON
print('appending:', byte, type(byte)) # THIS NEVER SHOWS UP
self.sendBuffer.append(dbus.Byte(byte))
print('sendBuffer:', self.sendBuffer) # THIS NEVER SHOWS UP EITHER
if len(self.sendBuffer) == 20:
self.flush()
def flush(self):
print('flushing:', self.sendBuffer)
self.PropertiesChanged(GATT_CHRC_IFACE, {'Value': self.sendBuffer}, [])
self.sendBuffer[:] = []
def WriteValue(self, value):
print('write:', value) # THIS SHOWS AN ARRAY WITH THE VALUE THE APP SUPPOSEDLY WROTE
for byte in value:
print('got byte:', 0 + byte) # THIS SHOWS UP _ONCE_
print('sending byte:', 255 - byte) # THIS SHOWS UP _ONCE_
self._foo_send1(255 - value) # BUT I QUESTION WHETHER THIS EVER HAPPENS, SEE ABOVE
def StartNotify(self):
pass
def StopNotify(self):
pass
The ALLCAPS comments in the code above show what happens when the WriteValue() method is apparently called. I’m completely confused as to what’s going on here. Is this some sort of nuance with the dbus/gobject bindings?
I’m also wondering if I need to be doing something to set up some sort of Descriptors? I admit I’m fuzzy on what the descriptors do and how they work. The previous 2 experiences I’ve had with BLE, the descriptors seemed to be automagically managed.