Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 28 15:36

    dariuszseweryn on dagger

    Improved DeviceComponent and De… (compare)

  • Jan 28 15:21

    dariuszseweryn on dagger

    Improved ClientComponent and Cl… Improved DeviceComponent and De… (compare)

  • Jan 28 15:10

    dariuszseweryn on dagger

    Merged DeviceModuleBinder with … (compare)

  • Jan 28 15:09

    dariuszseweryn on dagger

    Merged ClientModuleBinder with … (compare)

  • Jan 24 15:01
    Steppschuh closed #536
  • Jan 23 19:14
    dariuszseweryn edited #534
  • Jan 22 11:55
    Steppschuh opened #536
  • Jan 20 22:46
    lukaszkalnik opened #535
  • Jan 20 19:53
    mohank1288 opened #534
  • Jan 20 13:14
    lukaszkalnik edited #528
  • Jan 19 22:33
    lukaszkalnik edited #528
  • Jan 19 22:32
    lukaszkalnik edited #528
  • Jan 19 22:32
    lukaszkalnik synchronize #528
  • Jan 19 15:39
    lukaszkalnik closed #531
  • Jan 19 15:39
    lukaszkalnik synchronize #528
  • Jan 18 17:27

    dariuszseweryn on dagger

    Improved DeviceComponent and De… (compare)

  • Jan 18 17:22

    dariuszseweryn on dagger

    Improved ClientComponent and Cl… (compare)

  • Jan 18 17:21

    dariuszseweryn on dagger

    Bumped dagger version to 2.21 (compare)

  • Jan 18 16:23
    dariuszseweryn closed #510
  • Jan 18 16:21

    dariuszseweryn on master

    Added sample application in kot… (compare)

Ari Lacenski
@tensory
I think I at least need to implement a retry loop. :sweat:
Dariusz Seweryn
@dariuszseweryn
Ah, Ok — was thinking that maybe there was some battery saving on the phone side. Your case is totally legit
Ari Lacenski
@tensory
Yeah, that case seems alright to me too.
At the moment, I'm getting GATT_ERROR / 133 sometimes trying to connect to a freshly scanned BLE device after I've scanned for it, waited 500ms, stopped scanning, and the device is on (it's blinking). Not 100% of the time, and the connection rate is certainly better than before, when I wasn't scan/wait/connecting.
I'm going to try getting a bluetooth hci dump and see if there's any goods in there. It's possible Im hitting a cached scan record.
Ari Lacenski
@tensory
Fixed iiit. The thing to do, when you don't know the MAC address you want yet, is
1) scan for the devices you want; 2) stop scanning (dispose the first scan disposable), 3) using the mac address you got, scan AGAIN. Connect only to the fresh ScanResult obtained in the thread for the second scan.
My co-workers have been high-fived.
Dariusz Seweryn
@dariuszseweryn
Hmmm... Step 3. seems to be not needed from my experience unless your peripheral has a really long advertisement interval (and goes to sleep for extended periods of time in between i.e. several seconds)
Ari Lacenski
@tensory
Any known issues with scanning observed on a Samsung S6?
Dariusz Seweryn
@dariuszseweryn
Nothing I can recall
asketes
@askesis

Hi there!

Is it possible to interact with paired (via OS, only android interesting for me) device through the package?

async devices(deviceIdentifiers: Array<DeviceId>): Promise<Array<Device>>
get required argument, but I know nothing about device

Looks like I should know information about device earlier then use this package. Is it true?

Dariusz Seweryn
@dariuszseweryn
@askesis this question should be asked on https://gitter.im/RxBLELibraries/react-native-ble I suppose
asketes
@askesis
@dariuszseweryn oops, sorry, you are right
Besides, when I asked, I just didn't understand what this library is doing. But finally, I figured it out
thanks :)
Francesco Callieco
@f.callieco_gitlab
Hi everybody, we are facing a strange issue retrieving information from our BLE device. We are retrieving long dataset information from BLE with a write command on device service. We start receiving the dataset on the observable object but it stops being updated without reasons and the answer stream is truncated every time (in different point of the stream).
and no exceptions occured. Thank you in advance for any support.
Dariusz Seweryn
@dariuszseweryn
What do you suspect?
Francesco Callieco
@f.callieco_gitlab
It seems something related to buffer stream. The message received is very long. the same situation with iOS version of library works so it should be something related to data reading management (not able to say if javarx or ble library...). Unfortunateley log is not indicating any issues simply the response is truncated. The snippet of the code used is the following
Dariusz Seweryn
@dariuszseweryn
You are taking assumptions that iOS and Android work exactly the same
Francesco Callieco
@f.callieco_gitlab
Nope, for me it means that the problem not rely on the ble device just to have a point for starting investigation. I am trying to understand if I am missing some configuration while reading from characteristic hoping that anyone has issues reading very long response maybe giving me a direction to solve this bug.
Dariusz Seweryn
@dariuszseweryn

You wrote:

not able to say if javarx or ble library...

Anyway: what is a read (or a write)?

Maybe the question is too abstract. It is a transfer of data
Dariusz Seweryn
@dariuszseweryn
How can the peripheral/central know how big transfers are possible?
Francesco Callieco
@f.callieco_gitlab

Maybe the question is too abstract. It is a transfer of data

You are right, sorry. We are communicating with BLE device having a specific characteristic on which we write a command. The BLE device returns us the entire configuration pattern which is a very long xml truncated in small byte stream. The data receiving is done with an observable and we are able to process around 20 % of the entire stream (we log the data response) and then no more. We have checked for keep alive but it seems that is no loss of connection (or closing) problem. So I am assuming there is something related to byte buffering or similiar

Dariusz Seweryn
@dariuszseweryn
Could you edit the message with code so it will all be properly formatted?
Dariusz Seweryn
@dariuszseweryn
The library does not buffer any incoming data. It should be possible to debug if the data is indeed received by the central or if the connection stalls
Francesco Callieco
@f.callieco_gitlab
@dariuszseweryn I will do another couple of tests just to see if I can figure out more details and I will copy a well formatted snippet of the code we are using to you.
Francesco Callieco
@f.callieco_gitlab
return connectionObservable()
        .flatMap { connection ->
            //Find the characteristic that we need
            connection.discoverServices()
                    .flatMap { services: RxBleDeviceServices -> services.getService(UUID.fromString(serviceId)) }
                    .map { gattService: BluetoothGattService -> gattService.getCharacteristic(UUID.fromString(characteristicId)) }
                    .toObservable()
                    .flatMap { characteristic: BluetoothGattCharacteristic ->
                        Observable.merge(
                                //setting up the indication we will receive the stream from the device
                                connection.setupIndication(characteristic,NotificationSetupMode.DEFAULT).flatMap { it }
                                        .log("indication"),
                                //send the commands to the device (when they are pushed to the [commandRelay]
                                commandRelay.flatMap {
                                    Log.d(TAG, "sending: ${it.toString(Charset.defaultCharset())}" )
                                    connection.writeCharacteristic(characteristic, it).toObservable() }
                                        .log("write command"),
                                //send the keep alive
                                Observable.interval(1, TimeUnit.SECONDS)
                                        .flatMap {
                                            connection.writeCharacteristic(characteristic, ControlChars.keepAlive.toString().toByteArray()).toObservable()
                                                    .log("keepalive")

                                        }
                                        //Filter the keep alive messages (since are sent by us and not by the device)
                                        .filter { !it.contentEquals(ControlChars.keepAlive.toString().toByteArray()) }
                                        .log("filtered keepalive")
                        )
                    }
                    .doOnNext { Log.d(TAG, "-received: $it") }

                    //Convert the message to a String
                    .map {it.toString(Charset.defaultCharset()) }
                    .doOnNext { Log.d(TAG, "-stringreceived: $it") }

        }
        //Share the observable so each subscribers will use the same observable
        .compose(ReplayingShare.instance())
Dariusz Seweryn
@dariuszseweryn
What does the log function do?
Francesco Callieco
@f.callieco_gitlab
is logging on terminal for debugging purposes, from further tests it seems that if we ping the keepalive before the device finishes sending, the connection is interrupted
Dariusz Seweryn
@dariuszseweryn
that was one of my suspicions
glad you have solved it
Francesco Callieco
@f.callieco_gitlab
unfortunately we have not solved it, we receive almost 90% of the settings from the device and then we receive this error: Disconnected from MAC=‘XX:XX:XX:XX:XX:XX’ with status 8 (GATT_INSUF_AUTHORIZATION or GATT_CONN_TIMEOUT)
Dariusz Seweryn
@dariuszseweryn
That is a different problem I believe
Dariusz Seweryn
@dariuszseweryn
Most probably your peripheral stops responding
Francesco Callieco
@f.callieco_gitlab
we have tried not to send keepalive at all and we receive 20% of the complete response.
Dariusz Seweryn
@dariuszseweryn
Have you tried talking to the peripheral's firmware developer?
Francesco Callieco
@f.callieco_gitlab
we have talked to them but as application on other technologies works correctly they told us the it is "our" problem...
I have seen that library use the same queue for writing and reading, maybe this could be an issue?
Dariusz Seweryn
@dariuszseweryn
No, this is not a problem since Android OS does not allow for scheduling any operation before the previous is not finished
This queue only helps with serialising the requests so the user does not have to do it. But it has to be done
Maybe you are sending a write command when the peripheral is returning the settings and it make the peripheral go off?
Ari Lacenski
@tensory
Why might I see GATT CONNECT messages that seem to be ACL events logged by the Android system after I have just lost the RxAndroidBle connection?
Something like this:
2019-05-28 17:02:43.233 30377-30511/com.xxx.debug D/BluetoothGatt: unregisterApp() - mClientIf=7
2019-05-28 17:02:43.240 30377-30377/com.xxx.debug E/Error: Failed to write to characteristic.
    com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from FF:B3:F6:00:81:50 with status 8 (GATT_INSUF_AUTHORIZATION)
        at com.polidea.rxandroidble2.internal.connection.RxBleGattCallback$2.onConnectionStateChange(RxBleGattCallback.java:77)
        at android.bluetooth.BluetoothGatt$1$4.run(BluetoothGatt.java:262)
        at android.bluetooth.BluetoothGatt.runOrQueueCallback(BluetoothGatt.java:770)
        at android.bluetooth.BluetoothGatt.access$200(BluetoothGatt.java:39)
        at android.bluetooth.BluetoothGatt$1.onClientConnectionState(BluetoothGatt.java:257)
        at android.bluetooth.IBluetoothGattCallback$Stub.onTransact(IBluetoothGattCallback.java:71)
        at android.os.Binder.execTransact(Binder.java:731)
2019-05-28 17:02:52.223 20076-20334/? I/bt_stack: [INFO:gatt_api.cc(1109)] GATT_Connectgatt_if=2 ff:b3:f6:00:81:50
2019-05-28 17:03:22.227 20076-20334/? W/bt_stack: [WARNING:bta_gattc_act.cc(1040)] bta_gattc_conn_cback: cif=3 connected=0 conn_id=0x0003 reason=0x0100
2019-05-28 17:03:22.228 20076-20334/? W/bt_stack: [WARNING:bta_gattc_act.cc(1040)] bta_gattc_conn_cback: cif=4 connected=0 conn_id=0x0004 reason=0x0100
2019-05-28 17:03:22.228 20076-20334/? W/bt_stack: [WARNING:bta_gattc_act.cc(1040)] bta_gattc_conn_cback: cif=5 connected=0 conn_id=0x0005 reason=0x0100
2019-05-28 17:03:22.228 20076-20334/? W/bt_stack: [WARNING:bta_gattc_act.cc(1040)] bta_gattc_conn_cback: cif=6 connected=0 conn_id=0x0006 reason=0x0100
2019-05-28 17:03:22.231 20076-20334/? I/bt_stack: [INFO:gatt_api.cc(1109)] GATT_Connectgatt_if=3 ff:b3:f6:00:81:50
2019-05-28 17:03:45.168 20076-20334/? I/bt_stack: [INFO:gatt_api.cc(948)] GATT_Register 8a132d39-efa7-20eb-fa0b-a0de78580ff2
2019-05-28 17:03:45.168 20076-20334/? I/bt_stack: [INFO:gatt_api.cc(968)] allocated gatt_if=7
I have a sense of why the GATT_INSUF_AUTHORIZATION may be happening, so I'm not asking about that. Just, how come it seems like the phone is trying to reconnect (and maybe succeeding?) This is a Google Pixel 1 if that's at all related.
Dariusz Seweryn
@dariuszseweryn
Android as a Gatt Server
Ari Lacenski
@tensory
I'm unclear on what I might be doing to designate the phone as a server. I just want to use rxBleDevice.establishConnection, and I see stuff like that when it disconnects with either error code 8 or 133.
Ari Lacenski
@tensory
I solved my problem above, no longer an issue.
Dariusz Seweryn
@dariuszseweryn
Care to share the solution?
Dariusz Seweryn
@dariuszseweryn
@tensory
Viktor Eriksson
@vikeri
Does anyone know if there's a solution to getting a connection from an already connected device? If the device was connected through the Android BLE settings then I can't connect to it in the app. I get connect error: com.polidea.rxandroidble2.exceptions.BleAlreadyConnectedException which would have been helpful if I already had a connection in my app but since it's another app that connected it doesn't help me much.
Dariusz Seweryn
@dariuszseweryn
You have the connection established through RxAndroidBle in your app, you can check it in RxBleDeviceImpl