A little tidying up :)

[waveform80]

Sorry for the massive PR! By way of explanation:

I figured I'd have a go at fixing a couple of things in Blue Dot and got a bit carried away in my initial efforts at getting things tidied up. So, although it looks like there's a huge amount of change in this PR actually there isn't much (in fact it's best to ignore the overall diff and just have a look at individual commits). For example, the first commit does nothing but sort out white-space (several files had mixed DOS/UNIX line endings which always causes a bit of fun in diffs - if you set diff to ignore white-space you should see the commit does basically nothing). The second commit again changes nothing but file permissions (removing executable flags from the vast majority of things).

Then it's onto fixing up the docs so internal links work correctly in non-HTML output (e.g. PDF) and class/method links are all in place. Then I split out the examples into their own files so they're easier to experiment with, and then finally I did a little bit of tidying on some of the boolean conversions and exception handling. Everything still passes the test suite on py2 and 3, and several examples seem to work happily under either version.

Anyway, I figured I'd stuff it all in one PR to make it a bit easier to merge but if you'd prefer it split into separate PRs, or if you don't like some bits do let me know - I can always split/drop stuff from it fairly easily!

[martinohanlon]

Let's see what you have been up too...

[martinohanlon]

Thanks Dave, its great to have an independent tidy up and review.

I had totally forgotten I put into the string_to_bytes function.. I remember being away and doing some refactoring and getting massively frustrated with python 2 & 3 incompatibilities and putting this in as a stop gap.

[martinohanlon]

Really, thank you very much :)

[waveform80]

No prob! Now the spring-cleaning's done, onto the stuff I really want to fix. Mostly a nasty little heisenbug in the event handling; I've only managed to get it to occur under Python 2 but that's probably down to subtle thread timing differences - there's no theoretical reason it can't occur under 3 as well - anyway, might get it done over xmas, might be new year :)

[dglaude]

So is it now ready for inclusion in GPIOZERO?

On 19 Dec 2017 10:48 am, "Dave Jones" notifications@github.com wrote:

No prob! Now the spring-cleaning's done, onto the stuff I really want to fix. Mostly a nasty little heisenbug in the event handling; I've only managed to get it to occur under Python 2 but that's probably down to subtle thread timing differences - there's no theoretical reason it can't occur under 3 as well - anyway, might get it done over xmas, might be new year :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/martinohanlon/BlueDot/pull/91#issuecomment-352692636, or mute the thread https://github.com/notifications/unsubscribe-auth/ASiRnAA_wIEuet9zfOrRq0gXgOLGMAR7ks5tB4Z0gaJpZM4RFuO- .

[waveform80]

Heh - not sure Martin wants that (besides - I'm so far behind on gpiozero my todo list is ridiculous; I've got some time reserved for it in January though :)

[martinohanlon]

@dglaude they are very different projects, I dont think merging bluedot into gpiozero would offer any benefit. Albeit I purposely did go for a 'similar' api, to allow them to work together.

[dglaude]

I know, and now you have expert review from a GPIOZERO expert. :-)

On 19 Dec 2017 2:00 pm, "martinohanlon" notifications@github.com wrote:

@dglaude https://github.com/dglaude they are very different projects, I dont think merging bluedot into gpiozero would offer any benefit. Albeit I purposely did go for a 'similar' api, to allow them to work together.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/martinohanlon/BlueDot/pull/91#issuecomment-352742220, or mute the thread https://github.com/notifications/unsubscribe-auth/ASiRnFsAi_u1_e63P0IJ00nmcQLZs-Dbks5tB7ODgaJpZM4RFuO- .

[waveform80]

I do love how well it integrates - BlueDot is always my "go to" library when someone asks how they should control their robot at Raspberry Jams or HackMcr events (whether or not they've opted to use gpiozero). I've been meaning to have a good crack at it for months now but only just found a little time recently.

The only major issue I've ever run into is that lack of an iPhone app (but unfortunately there's nothing I can do to help with that!); even then there's usually someone on the team with an Android, or another Pi can be roped into running the app. Slightly disappointed no-one's stepped up to address that though, especially when Martin went to the trouble of documenting the (extremely simple) protocol.

[ukBaz]

Just a note on iPhone support... The problem is that underneath the hood the Bluetooth communication is using the Serial Port Profile (SPP) which is Bluetooth 2.0 (Classic). iPhone only supports the newer Bluetooth 4.1 (Low Energy) version while Android supports both. The other piece of this is Linux/Raspberry Pi which uses the BlueZ stack for Bluetooth communication. The version of the BlueZ stack that is in Debian Stretch releases doesn't have great support for creating a Bluetooth Low Energy (BLE) peripheral. There are newer versions of the BlueZ stack that do support creating BLE peripherals with Python but it currently requires building those newer versions from source. This is not something that most people would want to do at a Raspberry Jam or Picademy I am sure.

BlueZ has two types of API,

1. DBus API
2. HCI API (raw sockets to the kernel)

The comments above refer to the DBus API. There are people trying to create Python libraries that use the HCI API so that many of the dependencies are removed. However these libraries are not very mature at the moment. A couple of examples are: https://github.com/frawau/aioblescan https://github.com/TheCellule/python-bleson

So the blocking issue to getting an iPhone App is really about getting better support for BLE on Linux.

[waveform80]

Ahh, that explains it, thanks!

Very likely means it'll be another major Debian/Raspbian release before this is supported (I doubt Debian would update BlueZ within a release just for BLE support - it's not a security issue after all - and I suspect supporting a back-port is probably not something the foundation are terribly interested in). The raw sockets implementations are interesting but if they're using raw sockets I'm assuming they require elevated privileges in which case they're probably not ideal either. Oh well, one mystery solved anyway.

[ukBaz]

Your assumption about the raw sockets needing elevated privileges is correct.

It is all a bit tricky to get everything to line up which makes what Martin has done all the more impressive