search

spacecheese / bluez_peripheral

A library for building BLE peripherals using GATT and bluez
MIT License
38 stars 8 forks source link

Advertising timeout #27

Closed targettadams closed 1 year ago

targettadams commented 1 year ago

This is more of a general question than an issue. I noticed there is no option to specify that the peripheral should always advertise. I realise that I could just set the timeout argument in the advertisement constructor to something large, which is fine for my purposes, but is it not better to have the option to have no timeout? Or is this generally not how bluetooth devices are expected to operate?

Great library btw.

spacecheese commented 1 year ago

Hello sorry for the slow response. The documentation I based this code off doesn't include an explanation of how to set a indefinite timeout (although interestingly they do for DiscoverableTimeout). I'll do some experiments with this and see if I can find a way to add this.

spacecheese commented 1 year ago

For me setting the timeout to 0 seems to achieve this. Pretty sure I checked this before but I'll add this to the documentation and make it the new default.

targettadams commented 1 year ago

Thanks for looking into it for me. I set it to a large value as a workaround, but will change to 0. Must confess, I didn't try the obvious (setting it to 0). I read some of the code and couldn't see any special treatment of 0. Obviously didn't dive deep enough. Thanks again.

targettadams commented 1 year ago

Btw, this comment you made in your docs was super important in my case:

"Services are not implicitly threaded. If you register a service in your main thread blocking that thread will stop your service (and particularly notifications) from working. Therefore you must frequently yeild to the asyncio event loop (for example using asyncio.sleep) and ideally use multithreading."

I created a write method, that was receiving data from a 3rd party central. It sends its data in short bursts that accumulate to a few seconds of transfer. I had some simple processing of each data 'burst' in the write method itself (a few string splits/manipulations). Even this was enough blocking to cause some of the packets to be missed. To get around, I harvested each burst of bytes data into a new thread and did any processing there. It then worked a treat.

spacecheese commented 1 year ago

I've made this note more prominent in the new version of the docs. Pretty sure I made the exact same mistake the first time around.