It seems that the watch face gets stuck a few times a day on versa 3.

[tzachi-dar]

It does not happen with sentinel watch face, so it seems that a workaround can be found for the issue.
If no one has an idea what to do, I'll try to debug this.

[sulkaharo]

If you can find out what's causing this, that'd be great. I've tried to run the watch face in the debugger for long periods of time but can't replicate. The same happens with Sense. The symptom that I can see is the API used to load the data changes reports there's no data file on the watch at all, or it hasn't updated for a long time. On the device, this can sometimes be remedied by restarting the watch app, but sometimes you need to restart the Fitbit app on the phone to correct this, which indicates there's separate issues affecting the Fitbit app and the watch face. Also note the same core code is used for both the Versa 2 and 3 and Versa 2 does not have this issue using the exact same sync logic, so looks like the issue only appears when run on the newer firmware in the Versa 3+ devices.

[tzachi-dar]

I have built the app and installed it.
I'm using sdk 5. Should I use SDK 6 somehow (I see that at least for one device SDK has increased to 6).

[sulkaharo]

For Versa 3 / Sense, you should be using SDK 6.1 (the latest) - that's the SDK used to made the build in the Fitbit store. Note the dual SDK folder structure in the repo as documented in the README.

[tzachi-dar]

A short update:
I have enabled wifi on the watch and connected it to the fitbit debug environment.
I have built the code from scratch while enabling the logging capabilities (using the sdk5 directory).
After that most issues seems to be over except for 2:

1. Once the phone has rebooted, and I have received the app can not be installed error. Once I have connected the phone to the debug environment, the phone and the watch have connected.
2. I have pushed the phone away from the watch, for 10 minutes and after that the phone and watch did not connect again for an hour. Only when I have opened the phone (using another app) the phone and watch have connected again.
   So, it seem that either this is a race and printing is changing the timing of the code, or this is some build problem for the app in the store.

I'll keep following and see how things go.

[sulkaharo]

1. Not sure what you mean by app cannot be installed error? Is this something Fitbit is telling you?
2. The behaviour of the watch not reconnecting after losing the phone connection is consistent with what I'm seeing. Looks to me that at least iOS kills the background running of the app on the phone and the way to reconnect the app in these cases is to reboot the Fitbit app, which implies the issue in these cases is not the app?

[tzachi-dar]

Just for the record, I'm using android...
The unfinished install is this message:


After continuing to run for some time the app on watch stopped working and did not connect again.
Looking at the logs the last messages there have been:

{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': False, 'position': {'generated': False, 'line': 142, 'name': 'NightscoutMonitor', 'column': 0, 'source': 'app:///companion.js'}, 'message': ['currentBgDate: 1659714860699'], 'timestamp': 1659715003.439}
{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': False, 'position': {'generated': False, 'line': 176, 'name': 'NightscoutMonitor', 'column': 0, 'source': 'app:///companion.js'}, 'message': ['All promises resolved'], 'timestamp': 1659715003.504}
{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': False, 'position': {'generated': False, 'line': 122, 'name': 'NightscoutMonitor', 'column': 0, 'source': 'app:///companion.js'}, 'message': ['Queued a file change: data.cbor'], 'timestamp': 1659715003.52}
{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': True, 'message': ['App closed on device, unloading companion in 3 seconds…'], 'timestamp': 1659715030.932}
{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': True, 'message': ['Unloading companion…'], 'timestamp': 1659715033.944}
{'emittedBy': {'component': 'companion', 'hostId': '09CA5C4C6524', 'buildID': '03a8c96c51b6d014', 'uuid': 'eaed806d-9ff5-4aa9-a2c8-518f1f852f5a'}, 'kind': 'log', 'fromHost': True, 'message': ['Companion unloaded'], 'timestamp': 1659715035.974}

After I have rebooted the watch, they have connected again.
I have decided to try and follow this thread:

and use try catch in the app. Let's see how this will work...

[tzachi-dar]

Now getting an error after rebooting the phone. Not sure if it is a problem in our code or not.
I have opened https://community.fitbit.com/t5/SDK-Development/quot-webview-crash-webview-has-crashed-quot-in-logs/m-p/5207685#M17803 with a question.

[tzachi-dar]

A short update:
Right now it seems that there are 3 problems:
1-2 are problems of unhandled exceptions in both the application and the companion. This seems to be solved by using try catch over them.
3 the webview crash. I have stopped the always on option in the settings, and now this doesn't happen anymore.

So, right now the program is already running for 12 hours, and obviously we need much more testing.
As a side note, I would say that it seems that the phone can not pass even 24 hours without charging (even when screen is turned off), and this is far from what I would expect.

[tzachi-dar]

A short update:
After more testing, it seems that my suggestions did not work. Program is still getting stuck (probably less than before, but still getting stuck).
I have also tried deleting all code in client that is responsible for display, but still it does not help.

One time I have received a message saying:

App timeout triggered; app closing. See https://dev.fitbit.com/build/reference/device-api/appbit/#interface-appbit- for more information.

This was printed a long time after there was no data, so still not sure what is going on there.

My next step should be write the client log to a file and have a button to print this file. Hope it will shaw what the problem is.

[tzachi-dar]

Right now there should be 3 issues identified:

1. The webview crashing from above.
2. Exceptions on server side (I have a fix).
3. The socket becomes close and does not re-open when the phone and device connect.
   I have opened https://community.fitbit.com/t5/SDK-Development/Socket-remains-closed-even-when-the-device-and-phone-are-connected-and/m-p/5219690#M17910 to track this issue.

I'll also try to use fitbit-asap as a way to wake the companion app. (https://www.npmjs.com/package/fitbit-asap)

[sulkaharo]

FWIW on iOS:

1. I've never seen the web view crash, so this seems Android specific
2. By server side, do you mean Nightscout or the companion? The companion already wraps all requests in try/catch blocks, so would be curious to see what issues you've seen and what the fix is
3. How do you know it's the socket having issues? Note the data sync does not use the messaging at all, it's just there to keep the sync alive. The data is actually passed using the files API. Based on logs, what seems to happen is the companion thinking the app is closed on device when that's not the case, but there's no clear reason why this is happening and this is not the same as the messaging closing.

[tzachi-dar]

1. Never checked that with iphone, so you are probably right.

2. on the companion side, the promises are not using try catch. I have received the following errors:
   Uncaught (in promise) Illegal state error: RPC getFileTransferName result is undefined.
   and the fix seems to be replacing:
   return fetch(url, options)
   .then(function(response) {
   return response.json()
   .then(function(data) {
   with:
   return fetch(url, options)
   .then((response) => response.json())
   .then(function(data) {

3. Indeed the logs are as you describe. But what I think that should happen is that the ping should leave the companion alive. But the ping stops working because the socket is never opened.

[tzachi-dar]

Reading this, does not seem to be too optimistic: https://community.fitbit.com/t5/SDK-Development/messaging-socket-randomly-not-open/m-p/3299122

[sulkaharo]

FWIW that log has nothing in it that says the messaging is the issue and we're not transporting data using messaging. The log implies Fitbit has a bug somewhere, where the app on the phone periodically thinks the app on the watch is dead, which results in the companion being killed. Note this does not happen on the Versa 2, so this is a problem in the new firmware.

[tzachi-dar]

I totally agree that the issue is with the watch/phone side and not with the application.

[sulkaharo]

Looked at the data loading logic and made #68 to clean shit up. With the current implementation, it looks like there's a lot of undefined code paths that can break things if any of the requests fails. The refactor attempt to make the logic a bit more robust. Now testing on my device.

[tzachi-dar]

Thanks for the update.
#68 seems quite big, so I'm finding it hard to see what actually has changed there.
I must say that at least for the client side, I have removed almost all code, and that did not help either, which makes me believe the issues are not with the application but rather with the watch.

[sulkaharo]

The relevant changes are all in companion/index.js. Best viewed in the mode where you hide white space changes.