Explicit disconnect triggers automatic reconnect?



  • What we do right now is to call undiscover() (even when the docs state that there's no obvious use case for this function, I think ours is pretty valid), then disconnect() and then only if the device is() is on BOND state, we call unbond().

    The whole process seems utterly complicated for me since we also are reacting to other connection/disconnection issues and this is on top of that. But I've been building this on top of itself as the behavior proved to need more rework.



  • @ryanbis hi, any comments about the issue? Thanks again!



  • Removing all the calls to unbond() from our side does not mitigate the automatic reconnection.



  • I was able to make it work by always keeping the last updated connection state manually:

    I have a BehaviourSubject (or BehaviourRelay) where I track the latest connection state
    I have a boolean flag inside the ReconnectFilter which I switch off and then it returns stopRetrying(), etc before I ask for a disconnect.
    I set a NoReconnectFilter() before asking for a disconnect.
    I call disconnect_remote() and undiscover() when I ask for a disconnect
    I explicitly trigger a STATE_DISCONNECTED on my BehaviourSubject after this, so the rest of the app continues and we get no more notification from sweetblue after this. Firmware update works normally and we recover from this.


  • @caeduk that's a good solution is similar to what we do:

    1. Before switching the device to be in firmware update OTA/DFU mode, we keep track of which device will be put into that mode.
    2. Undiscover the device after the disconnection.
    3. Set the setListener_DeviceReconnect to null.
    4. We only trigger a connection in the DefaultDeviceReconnectFilter if we know that the device is not transitioning into its firmware update mode.


  • @AlejandroHCruz I haven't really been able to unbound without triggering RECONNECTING_SHORT_TERM on the library as a side effect.

    @ryanbis any ideas?



  • @caeduk what is your situation? Are you trying to unbond while connected?



  • Just some info here. SweetBlue initiates an implicit disconnect when you try to unbond when connected. This is to fix a bug which happens on Android where the bond state gets out of sync. The unbond will work, but the reported bond state no longer matches reality. SO, SweetBlue disconnects before unbonding to ensure bond state is as reliable as possible.

    With that said, we need to make the library a little more flexible here. I think we should be able to whip something up for more OTA friendliness.



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

    Yes I was trying to unbound() before disconnecting.



  • Undiscover will disconnect, but will not explicitly unbond.