Explicit disconnect triggers automatic reconnect?

  • Hi, we’ve setup a DefaultDeviceReconnectFilter object to deal with some scenarios but it is sometimes still triggered when we don’t want it to (please note that an explicit disconnect is called and the attemptShortTermReconnect triggers a reconnect.

      1. Shouldn’t the reconnect only be attempted on implicit/soft disconnections?
      1. What triggers a SOFTLY_CANCELLED? It seems to be product of us calling either unbond() or undiscover()


    (We’re disconnecting, then scanning and connecting the same device with another UUID.

    1. Would you recomment to rather use the native discover services function?)

    Thanks, all the best!

  • P.S. I’ve tried to set this up before disconnecting and scanning to stop the automatic reconnect but it’s not helping:

            bleManager?.setListener_DeviceReconnect(object: DefaultDeviceReconnectFilter() {
                override fun onConnectionLost(connectionLostEvent: ConnectionLostEvent?): ConnectionLostPlease {
                    return ConnectionLostPlease.stopRetrying()
                override fun onConnectFailed(connectionFailEvent: ConnectFailEvent?): ConnectFailPlease {
                    return ConnectFailPlease.doNotRetry()

  • Are you explicitly unbonding? The tryBondingWhileDisconnected flag affects this...if that option is true (which it is by default), then SweetBlue will disconnect to do the unbond. I think there is some weirdness here. So because the library initiated the disconnect, it labels it as being implicit (because, well, it is). So the library then thinks it should reconnect. I think we'll have to add some logic there to take care of this case.

    Could you explain what you mean by "connecting the same device with another UUID"? Is the device's gatt database changing somehow? Do you really need to disconnect?

  • This post is deleted!

  • Yes, I was not sure if calling disconnect() would also unbond() but on the source code on v2 it seemed that the later would end up calling the first one.

    So what is the correct way to disconnect with unbond, without reconnecting and also make the app forget that this device was ever connected?

    Our use case might seem a bit weird, but we're following Cypress' standard process for a firmware-over-the-air update: The hardware peripheral needs to reboot and start its FOTA mode with a special service, thus it will be disconnected and we need to rediscover it with its new service UUID that is now available but was not there before.

    Alternatively I try to skip the disconnect step, since the hardware device reboots it will get disconnected anyway. But if the app is still trying to reconnect, we're pretty much back to the same situation described on this post.

    Any ideas?






    I set a NoReconnectFilter() before asking for a disconnect.


    2. Undiscover the device after the disconnection.
    3. Set the setListener_DeviceReconnect to null.


    @ryanbis any ideas?




  • @ryanbis will undiscover() also unbound and disconnect?

    Yes I was trying to unbound() before disconnecting.

  • Undiscover will disconnect, but will not explicitly unbond.