Pull request #1 - Bluetouch Paper release

[Wayne Keenan]

On this fireworks night I have lit the blue touch paper!

https://github.com/TheCellule/python-bleson/pull/1

Wayne

[Wayne Keenan]

Hi,

I've made a commit, to the same PR, that adds UUID16 and UUID128 object types and support of them in creating and receiving Advertisements.  There is also a new HRM (advertisement only) example that uses UUID16 here: https://github.com/TheCellule/python-bleson/blob/wk_draft_experiment/examples/basic_advertiser_heartrate.py

There are additional unit tests in the test folder too.

I plan to work on the macOS provider next so don't plan to make public API additions or alterations unless it make sense/is needed to support additional providers. 

If there are public API changes or additions that are needed to make the API easier to consume for clients, or any other feedback, please shout. 

Thanks,

Wayne 

Mobile: +447717781468  

Skype: wayne.keenan

Twitter: @wkeenan

The Bubbleworks Factory Limited 

Fenscape Offices, Harrier House, Sedgeway Business Park, 

Witchford, Cambridgeshire, CB6 2HY

Registered in England and Wales, 

Company Registration Number 10191037 / VAT GB 246639773

Follow @The_Bubbleworks on Twitter.

www.thebubbleworks.com

--
You received this message because you are subscribed to the Google Groups "python-bleson" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-bleson+unsubscribe@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/python-bleson/344bc909-d700-4b78-8de1-a91ea2709c37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wayne Keenan]

I've added a macOS provider.

It's a very alpha, supporting only the observer role but it does actually scan. 

The (unmodified) example observer shows Advertising reports, however these are incomplete as they currently only show: name, rssi and txpower; other info is available but it still needs to be extracted from the CoreBluetooth data.

The commit, for the same PR is https://github.com/TheCellule/python-bleson/pull/1/commits/65adbcd0925aae8a1a0ba66175144281cbd06026

[Barry Byford]

Hi Wayne,

This seems to work.

For the record...

I did get the following error when I run this at first on the Mac.

ModuleNotFoundError: No module named 'objc'

This was fix by:

pip3 install pyobjc

Regards,

Barry

[Wayne Keenan]

Hi Barry,

Thanks for kicking the tyres. 

The thing that not sitting right at the moment is the fact that in the current experiment the observer.start() method doesn't return as it starts the main loop (a RunLoop on macOS).

I've tried to find a way to initiate the runloop on a background thread, and to do this without having to changing the bleson public API or by introducing a 3rd party library.  But, although I can start the runloop on a background thread, I'm not receiving CoreBluetooth events when I do.

A few key facts:

a) 'bleson' is currently Python 3.x only, by design.    (I also think not requiring additional library installs is a big bonus) 

b) macOS comes bundled with Python 2.7 with PyObjC pre-installed, but not a version of Python3.

c) If this was a pure Obj-C app the 'runloop' responsible for receiving CoreBluetooth events should, in theory, be able to run from a background thread, but doesn't seem possible using PyObjC, I've raised: https://bitbucket.org/ronaldoussoren/pyobjc/issues/215/starting-runconsoleeventloop-from-a

d) As an alternative to using PyObjC there is a XPC Python wrapper. XPC is Apple's form of light-weight IPC, Sandeeps Noble library uses CPC on macOS. However, the Python XPC module I've found has installation/build (PY2/Py3) issues that I've overcome and runtime Unicode issues (Py3 only) that require more investigation.  https://github.com/matthewelse/pyxpcconnection

The alternates that I see:

1. Change the Bleson API to be more like Adafruit Python LE library, i.e. bleson starts the platforms 'mainloop' and runs the users code  on a secondary thread (specified by a user provided callback)

2a. Support Python 2.x so not to require the additional installation of PyObjC step, and change the bleson API

2b. Support Python 2.x so not to require the additional installation of PyObjC step, but NOT change the bleson API and (hopefully resolve the runloop issue

3 Switch to XPC. Would not require API change but requires fixing it in the process and an additional install step that requires building a native components.

Questions:

Is changing the Bleson API to call user code on a background thread the way to go?

Is it worth the effort of supporting Python2?

Is it worth the potential pain of adopting an XPC library?

Is there another way?

[Wayne Keenan]

Although I don't know if we should use it but as I was up I went ahead and then submitted a pull request with .cpp fixes for pyxpcconnection, https://github.com/matthewelse/pyxpcconnection/pull/5

Wanting to avoid native extensions if XPC is the better way togo I've created a pure python XPC experiment, but have doubts as to it viability and have asked the author of xpcconnection for his thoughts, https://github.com/matthewelse/pyxpcconnection/issues/6

The PyObj author replied to my question on the issue linked previously, he has adding dispatch queues as a top priority but no ETA.   

I've confirmed dispatch queues are mandatory for CoreBluetooth to be able to run in a background thread.  

In the interim I've tried blending the creation of dispatch queues using Python's builtin ctypes module and then passing them via the PyObjC layer, but it explodes.   

The experiment is part of PR#1 and is disabled/enabled using internal flags: https://github.com/TheCellule/python-bleson/blob/546b5d907b0a4495362843237c947f3e8f89f0bc/bleson/providers/macos/macos_adapter.py

I did another commit to the open PR#1, to include the latest PyObjc, XPC and other experiments and from an end-user perspective it makes the observer on macOS display more useful info (e.g. UUID's for 16 and 128 bit services)

I'm going to look at a Windows provider next.

[Wayne Keenan]

I've just made a commit that allows CoreBluetooth to run in a background thread, so no changes to the public API.   

Also interesting to see that the Windows BLE API has moved on a lot too, it possible to scan for devices without manually pairing, hoorah!

[Barry Byford]

Good work on progressing this forward.

Be interested to hear more about how the Windows BLE API has moved on. Is there a reference online?

Cheers,
Barry