General Discussion

• C

  RxJava 3 support
  • caeduk

  1
  0
  Votes
  1
  Posts
  64
  Views

  No one has replied

• 

  Android 12
  • AlejandroHCruz

  2
  0
  Votes
  2
  Posts
  110
  Views

  R

  @alejandrohcruz said in Android 12: https://developer.android.com/about/versions/12/non-sdk-12 For new android versions, we always run the library through tests, to make sure the library is compatible. At a quick glance, I only see one method we use that will be blocked (factoryReset). While it'd be nice to keep that method, I don't think it's a huge loss (and I was never sure it really made any difference than just turning the ble radio off/on).
• 

  Disconnection issues while bonded on Huawei & Honor devices
  • AlejandroHCruz

  12
  0
  Votes
  12
  Posts
  2426
  Views

  C

  @ryanbis the fix to this connection loop went out with 3.2.3 right? I had implemented the methods in DefaultReconnectionFilter , to workaround the issue described here https://forum.sweetblue.io/topic/12/explicit-disconnect-triggers-automatic-reconnect/15 Now the workaround fails. How do we simply tell Sweetblue -- hey, disconnect now and do not retry to connect until we call connect() again?
• J

  API KEY unavailable
  • jastrada

  1
  0
  Votes
  1
  Posts
  181
  Views

  No one has replied

• 

  How does ConnectionLostPlease.persistIf work compared to autoconnect?
  • AlejandroHCruz

  7
  0
  Votes
  7
  Posts
  748
  Views

  

  @ryanbis Ah! Alright, everything's clear now. That was the confusion
• B

  Background scan times out on S10 (maybe other Samsungs)
  • blawlor

  3
  0
  Votes
  3
  Posts
  847
  Views

  

  @blawlor Funny enough, I'm seeing this behavior despite using a foreground service to scan. So in theory I shouldn't need the background location permission. Have you seen something like that too?
• 

  Foretting a device's characteristics
  • AlejandroHCruz

  6
  0
  Votes
  6
  Posts
  566
  Views

  

  @ryanbis Perfect! Thanks a lot. This is great.
• 

  Bonding with autoBondFixes set to true deletes all Bluetooth devices from Sony phones
  • AlejandroHCruz

  14
  0
  Votes
  14
  Posts
  1633
  Views

  R

  @alejandrohcruz Set autoBondFixes to false.
• E

  App crashing when SweetBlue dependency is added
  • EarlyWild

  2
  0
  Votes
  2
  Posts
  712
  Views

  E

  Issue solved... make sure to add Java 8 compatibility to project. compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }
• M

  Cannot get read/notify when connected to more than two devices.
  • mcgkc55

  3
  0
  Votes
  3
  Posts
  785
  Views

  M

  Thanks for getting back with me. It appears I get the same results using the Toolbox app, but did notice something interesting. My flow using Toolbox app after having connected to two devices Turn device 1 on. Wait for button to turn green and say "Disconnect". Usually takes about 5-10 seconds I'm able to get notify values Turn device off. Wait for button to turn white and say "Connect" ========= Turn device 2 on. Wait for button to turn green and say "Disconnect". Usually takes about 5-10 seconds. I'm able to get notify values Turn device off. Wait for button to turn white and say "Connect" This is pretty consistent. I can do this multiple times with the same result, but sometimes when I turn a device on, it's button will not turn green even after waiting for over a minute. But as soon as I turn on another device (two devices are now on), both devices will connect and buttons will turn green. When a third device is added, the only way I can get a device to connect and turn green, is to turn on another device too. This is pretty consistent with results I'm seeing with Sweetblue in our app. We try to connect to devices use a ReconnectFilter val deviceReconnectFilter = object : DeviceReconnectFilter { override fun onConnectFailed(connectFailEvent: DeviceReconnectFilter.ConnectFailEvent): ConnectFailPlease { return ConnectFailPlease.retry() } override fun onConnectionLost(connectionLostEvent: ConnectionLostEvent): ConnectionLostPlease { return ConnectionLostPlease.retryIn(Interval.secs(3.0) ) } } So our app is continuously trying to connect to devices it knows about. When device is turned on ConnectionEvent is triggered and we start getting data. When the device is turned off, onConnectionLost is fired and we start continuously trying to reconnect. Is there another way we should be trying to handle continuously being connected to a device?
• M

  multiple calls per second for onConnectionLost of DeviceReconnectFilter
  • mcgkc55

  2
  0
  Votes
  2
  Posts
  602
  Views

  R

  No, it's not supposed to fire that much. Looks like you found a bug, thanks for pointing it out. We'll make sure to get this fixed for the next release.
• R

  Trial Key not working in Android library package
  • rhilse

  4
  0
  Votes
  4
  Posts
  1019
  Views

  R

  Managed it to make it work. What you need is the application id, not the package name. Very confusing.
• 

  Best practices for saving battery life
  • AlejandroHCruz

  4
  0
  Votes
  4
  Posts
  1095
  Views

  R

  To be honest, it's been a while since I've dug deep into the numbers for connection interval. I would think 100ms would be good, just make sure to test like crazy :).
• 

  Interacting with device that's already connected to the OS
  • AlejandroHCruz

  10
  0
  Votes
  10
  Posts
  3274
  Views

  

  @caeduk interesting, I didn't know that you can do that if you scan without filters. We can probably look into their source code and find more hints i.e. see under which conditions they trigger that notification to ask the user if they want to debug the connection
• E

  Are there any sample projects that besides the SweetBlue v2 toolbox found on github?
  • Eheartlyanderson

  3
  1
  Votes
  3
  Posts
  1464
  Views

  V

  There is nothing in sample apps. Any possibility of it in being released in future ?.
• 

  Explicit disconnect triggers automatic reconnect?
  • AlejandroHCruz

  15
  0
  Votes
  15
  Posts
  5004
  Views

  R

  Undiscover will disconnect, but will not explicitly unbond.
• M

  Prevent reconnect regardless of disconnect reason
  • mkurtz

  17
  0
  Votes
  17
  Posts
  5347
  Views

  R

  @caeduk Please post a new topic with specific steps to reproduce the issue you're having so we can investigate it on our end.
• 

  Native state doesn't match reported state
  • AlejandroHCruz

  3
  0
  Votes
  3
  Posts
  1160
  Views

  C

  I found your post here https://forum.sweetblue.io/topic/12/explicit-disconnect-triggers-automatic-reconnect and I was actually able to make it work, but it's tricky
• B

  Increasing speed on an OTA transaction
  • benp

  18
  0
  Votes
  18
  Posts
  4620
  Views

  

  @benp thanks a lot, will check it out!
• B

  Bluetooth connections servered by the OS get the power back to SweetBlue
  • Bjoern_ilockit

  5
  0
  Votes
  5
  Posts
  1673
  Views

  B

  @alejandrohcruz said in Bluetooth connections servered by the OS get the power back to SweetBlue: Are you enabling the autoConnect parameter? Also, from what I've seen, Android OS does not reconnect to bonded devices, except for A2DP ones… However, if that is happening, maybe you could disconnect/unbond when you notice that the device is stuck or when your service gets killed? Hope Hey, the autoConnect parameter is not enabled. Yes I can do disconnect/unbond the device, the problem is that the user has to open the app, because we don't get any response in the background when the Android OS controls the connection and kills our app. Currently we have a little workaround in our device that kicks the smartphone after 2 seconds in a set up state, because we found out when Android OS tries to reconnect, it get stuck in this state. So we can handle it from our device and get the control back. Edit: Is there a chance to disconnect to a device when the Android OS has the control of the connection ? Like to use the native Android LE methods ? Because if you use the SweetBlue disconnect or shutdown methods the connection is still there..