help menu

Join us on the Community Forums!

  • Community Guidelines

    The Fitbit Community is a gathering place for real people who wish to exchange ideas, solutions, tips, techniques, and insight about the Fitbit products and services they love. By joining our Community, you agree to uphold these guidelines, so please take a moment to look them over.

  • Learn the Basics

    Check out our Frequently Asked Questions page for information on Community features, and tips to make the most of your time here.

  • Join the Community!

    Join an existing conversation, or start a new thread to ask your question. Creating your account is completely free, and takes about a minute.

Not finding your answer on the Community Forums?

Cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help / Advice with Frequent Versa to Companion Disconnects

‎08-01-2018 15:44

‎08-01-2018 15:44

 Hi Fitbit devs!

 

I'm building a clock face that does basic Heart Rate monitoring and stores the HR in a server about every minute for history. To do this, I need the Versa to be in frequent contact with the Companion. However, during testing, I noticed the Versa would lose connection to Companion frequently ("companion unloaded").
 
I'm curious to know if anyone has any advice or suggestions on what to do to minimize Versa and Companion disconnects?

Things like this for example:
  • Leave Fitbit app open on phone 
  • Make sure background refresh is enabled
  • Make sure bluetooth is enabled for Fitbit 
  • Login again through the Companion 
And in the event of a disconnect, how to have the Versa force the Companion to reconnect? 
 
Using  me.wakeInterval is not effective, as my polling needs to occur about every minute or so, and me.wakeInterval has a minimum of 5 minutes. 
 
I tried to force the connection by having the Versa send a message to the Companion, but this does not work once the Companion has unloaded. 
 
I've tried everything I can think to help with this,  so any and all suggestions would be appreciated.
 
 
Best Answer
3 REPLIES 3

‎03-12-2019 05:59

‎03-12-2019 05:59

I am also having this problem. The application we are building requires the watch to be connected to the companion persistently and so far we have not found a way to force the companion to reopen when it decides to unload itself.

Best Answer

‎04-28-2019 12:31

‎04-28-2019 12:31

Same. I'm working on Ionic app and since I'm new to the whole Fitbit sdk and evn, I'd like to simply have good connection to test messaging. It's quite frustrating how unreliable is the connection! No idea how to improve. Phone and the Ionic device are literally touching each other and next to the router.

Best Answer

‎04-29-2019 01:13

‎04-29-2019 01:13

Hi,

we're in the same situation with our sleep tracking app, where we need the companion to run for several hours and send messages quickly and reliably, ideally every two minutes but often more frequently.

I'm trying to overcome the issues for the past few months, so I'll share some of what I learned in the process, and what I've tried with inconclusive results.

Disclaimer: below is my experience, and things may have changed in the meantime, bugs fixed, or my incompetence at programming, at testing, or at living in general might have convinced me that I see things that don't exist.

With that said... 

 

The companion, in words of Jon Barlow, is "designed to be suspended", however I was also told that "in theory, if your app is running, your companion is running" by Liam McLoughlin.

 

The companion would be woken up by launchReason [startedOnTracker] when you start your watch app. In theory, until the watch app is stopped, the companion should run. I found some scenarios when the companion could stop even though the watch app runs:

  • the Fitbit app is killed off on the phone by some battery optimization (see dontkillmyapp.com - it might be possible to do something about this on the user's end)
  • the Chromium process inside the Fitbit app crashes - this is accompanied by logs from companion that suggest that the app on device has stopped, although it didn't (I reported this as a bug to Jon Barlow)
  • absolutely randomly and I have no idea why (this might be the case of my observation incompetence) 

Inconclusive results / don't know if has any effect:

  • Device being bluetooth paired to phone via Android system Bluetooth menu. I've had mixed results with my Ionic both paired and unpaired, so if anything, this definitely isn't a silver bullet
  • Enabling All-day sync in Fitbit app. Always tested with this turned on, but sometimes found that the connection between app and companion breaks nonethless.
  • Enabling Always connected in Fitbit app. Always tested with this turned on, but sometimes found that the connection between app and companion breaks nonethless.

What CAN be done:

  • Rethink the messaging design. You might not need to send it every 1 minute. You may aggregate five values and send an array every five minutes, parse it back on your server and you're good to go with the 5 minute me.wakeInterval.
  • Use file-transfer API for messaging instead of the messaging API. File transfer will wake up the companion (if it's not stuck, which unfortunately also sometimes happens). The downside is that you never know when the file transfer will actually happen. You just put the message in the queue which is then handled by the system.
  • Use something like fitbit-asap that handles retransmitting messages until they successfully land on the companion (in combination with 5 minute me.wakeInterval)

Sometimes when heavily testing, I find out that I cannot get the companion to start no matter what, and I have to Force close the Fitbit app and reopen it, which will probably reinit something crashed in there.

Best Answer