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.