Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Get IP address of device from Companion side code in order to establish a connection as a TCP Client

ANSWERED

1) To my understanding, the companion side code should be running on the phone, so I am wondering if there is a way to send/fetch for the devices' IP Address from the Companion?

2) Or vice versa I could send the IP address of the device from Unity to the Companion Code? This would be assuming there is a way to know that the companion code is running from outside the Fitbit environment on both iOS and Android.

3) Alternatively would it be safe to assume that a fetch request from the Companion to LocalHost would have the same affect?

Let me know your thoughts, if you've ever tried something like this and what the best approach would be. I already familiarized myself with the basics of the Fitbit SDK and Fetch requests, as well as got the fetch request working through direct IP/LocalHost using my desktop and the simulator.
I need to avoid using an API request with any client private information (user ID) because I would not have that information available on the Fitbit side. (As far as I know)

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

Maybe I'm preoccupied with the issue, but it really sounds to me like the problem is with the IP. Unless you're using non-self-signed https (which seems unlikely in your case), you can only use about four specific IP addresses (which you can find in one of those links). 127.0.0.1 should work for localhost (assuming your server is running on the phone that's running the Fitbit app, hence companion).

 

The sim doesn't check for https so strictly.

 

Even getting to other devices on your LAN will be highly problematic because of the https and IP constraints.

 

Yes, the companion code must be running for it to be able to communicate with your server. Waking it, and keeping it awake, can be problematic. However, the companion should start running as soon as your clockface/app starts running on your watch, so that shouldn't inhibit initial data flows. You can check whether the companion is alive by console.log whenever it receives anything from the watch.

Peter McLennan
Gondwana Software

View best answer in original post

Best Answer
0 Votes
3 REPLIES 3
Best Answer
0 Votes

I'm trying to send real-time heart rate and accelerometer data to a fitness application, but because the Web API SDK doesn't support real-time data, I'm looking for an alternative to send data over a server hosted within the fitness application. And doing so through a fetch request to localhost or direct IP of a local device.

However fetching to Localhost from the Companion app did not seem to work in my test on the Versa and Android (OnePlus 7T Android 10), despite working on the simulator and Desktop. It did however work when I use a direct IP fetch from Simulator to Android, so now I'm exploring a way for the companion to somehow resolve the IP Address internally without the user having to enter it. (Since the companion is supposedly running on the device I was hoping they could interact this way).

[EDIT]
WAIT. On Awake of the application on the Watch, do I have to make a Fitbit SDK API call to wake up the companion on the phone? Could it be that the Companion is not running on my device when I make the SendMessage/Fetch requests?

Best Answer
0 Votes

Maybe I'm preoccupied with the issue, but it really sounds to me like the problem is with the IP. Unless you're using non-self-signed https (which seems unlikely in your case), you can only use about four specific IP addresses (which you can find in one of those links). 127.0.0.1 should work for localhost (assuming your server is running on the phone that's running the Fitbit app, hence companion).

 

The sim doesn't check for https so strictly.

 

Even getting to other devices on your LAN will be highly problematic because of the https and IP constraints.

 

Yes, the companion code must be running for it to be able to communicate with your server. Waking it, and keeping it awake, can be problematic. However, the companion should start running as soon as your clockface/app starts running on your watch, so that shouldn't inhibit initial data flows. You can check whether the companion is alive by console.log whenever it receives anything from the watch.

Peter McLennan
Gondwana Software
Best Answer
0 Votes