search

HubbellCorp / SweetBlue

BLE on Android the easy way
Apache License 2.0
23 stars 8 forks source link

Connect to device without scanning beforehand. #12

Closed racketry closed 2 years ago

racketry commented 2 years ago

Hi,

first I have to say this lib has done a great job so far. My app was struck with the famous 133 error and stopped connecting at random times with standard Android functions. This library seems to got rid of that problem which is a huge success. Thanks!

Now to the problem: I have a peripheral device which connects to the Android app. Once the device has connected the app remembers the MAC address. The periperal can then be turned off and app creates the worker which polls to see if the connection can be made to the peripheral. Peripheral has wake-on-motion functionality and the idea is to automatically start the foreground service when it is turned on.

This works well except in one case - when the phone is in sleep mode. Worker still works and I can see the logs when state of the bluetooth is changing:

BT STATE: StateEvent entered = [STARTING_SCAN] exited = [] current = [ON, STARTING_SCAN, BLE_SCAN_READY] BT STATE: StateEvent entered = [SCANNING] exited = [STARTING_SCAN] current = [ON, SCANNING, BLE_SCAN_READY] BT STATE: StateEvent entered = [SCANNING_PAUSED] exited = [SCANNING] current = [ON, SCANNING_PAUSED, BLE_SCAN_READY]

But the manager.setListener_Discovery is never triggered - this works if the phone screen is turned on.

I tried to connect directly without scanning: val device = manager.getDevice("XX:XX:XX:XX:XX:XX") device.connect()

But I get a null device error when the periperal is off and also when it is on. This is possible to do with getRemoteDevice and connectGatt metod from the standard library.

Would something like that be possible with SweetBlue library as well?

ryanhubbell commented 2 years ago

No, right now SweetBlue doesn't take advantage of the getRemoteDevice method. I'm thinking when calling getDevice, it should call into getRemoteDevice if there is no cached version of the device already. It's something that is in our backlog now, though I'm not sure when we will be able to get to it. Feel free to submit a pull request, if you can't wait.

ryanhubbell commented 2 years ago

So I had some free time to explore adding this functionality. Turns out, you can actually get what you want out of the library right now. If manager.getDevice(mac) returns a null device, then call manager.newDevice(mac). This will call getRemoteDevice on the native stack, add the device to SweetBlue's internal cache, and returns the BleDevice instance.

ryanhubbell commented 2 years ago

Closing this issue, as the functionality does actually exist already.