BluetoothLE: Gerät lässt sich verbinden, verliert Verbindung aber wieder sehr schnell

[philipp.hofmann]

Hi,

generell läuft unsere BluetoothLE-Verbindung sehr stabil. Es werden immer die folgenden Schritte durchlaufen:
- discoverDevices
- discoverServices für ein gefundenes Gerät
- subscribeToCharateristic für relevante Characteristicen

Manchmal kommt es aber wenigen Minuten danach zu einem
- bluetoothLEDisconnect
für ein Gerät. Dies passiert insbesondere unter Windows, wenn das Gerät auch in den Windows-Einstellungen gepaired wurde, aber auch sonst lässt es sich manchmal beobachten.

Meine Vermutung ist, dass auch andere Apps sich mit dem bei uns verbundenen Gerät verbinden wollen und uns die Verbindung "stehlen". Lässt sich dies in der Delphi-BluetoothLE-Implementierung irgendwie verhindern, dass man wenn man einmal die "Macht" über ein Gerät hat, andere Apps diese nicht klauen können?

Grüße, Philipp

[Rollo62]

Ich habe sowas bei Android gesehen, hatte was mit Abwerfen vom IoT aus zu tun, als eine Art Timeout.
Bin gerade nicht am Rechner, ich suche das morgen mal raus.
Ganz gelöst ist das aber noch nicht, hängt irgendwie vom IoT Stack ab, der kommt bei uns aus China von mehreren Lieferanten.

Es ging so in diese Richtung mit Status 133
https://stackoverflow.com/questions/...ister-callback

[Rollo62]

Wie gesagt, das ist für Android, aber ein paar Punkte betreffen eben auch BT generell
Hier mal zusammengeschrieben, vielleicht ist ja uach was für Windows dabei:

Zitat:

Aside from the random occurrences of 133, we’ve generally seen error 133 happen most frequently in one of the two following scenarios:

- The BluetoothDevice we’re trying to connect to is no longer advertising or within Bluetooth range, and the connectGatt() call has timed out after about 30 seconds of trying to connect to it
with the autoConnect argument set to false.
=> Not the case: Because it is connected and connections gets disconnected after < 6 sec..

- The firmware running on the BLE device has rejected the connection attempt by Android.
=> Maybe, but connection was already establihed < 6 sec. before

- Connections exceed the max. no. of 6 connections, perhaps caused bei not properly closed connections

- Too small MTU size, which might limit the troughput


Regardless of which error status code you got in your onConnectionStateChange() callback, the recovery flow typically goes like this:

- Call close() on the BluetoothGatt object to indicate that we’re done with this BluetoothGatt instance, and that the system can release any pending resources.

- Null out any references to this BluetoothGatt object.

- If status code is either GATT_INSUFFICIENT_ENCRYPTION or GATT_INSUFFICIENT_AUTHENTICATION: call createBond() first and wait for the bonding process to succeed first
before calling connectGatt() again. We’ll go through how to initiate a bond with a BLE device in a later section.

- For other status codes: either surface an error to the user, or attempt to reconnect again silently for a few times before giving up.
The latter is actually a viable strategy, considering the fact that error 133 can sometimes be very random and occur a few times in a row before the connection attempt eventually succeeds.