Watch App Stopping (and other reliability problems)

[jones139]

I am trying to get a very simple app working for a Fitbit Versa or Ionic (Using SDK 3.x).   

The idea is that it collects 5 seconds worth of accelerometer and heart rate data, and post it to a web server (that is running on the attached android phone)....and repeats indefinitely.

I seem to have it working - watch app collects the data, uses messaging to send it to a companion app, which uses fetch() to post it to the web server, and returns the response to the watch app as a message.

The problem is reliability - I am experiencing the following issues, which may or may not be linked:

• Sometimes the companion app does not send the message back to the watch app (although it says it is, the watch app does not receive it). (I cured this by re-booting the phone)
• When I am using the debugger to try to see what is running (started using the command line install command), after a while it says that the watch has disconnected from developer bridge, and I have to use the watch  settings to connect it again.
• Most significantly, after a relatively short period (between 2 and 15 minutes), the watch app stops.

The watch app stopping sounded like a memory leak, but as far as I can tell the memory usage is not increasing (but does seem to vary a lot over time).   I found a 'run in background' permission, but that seems to relate to the companion app, so not relevant for me.

I wondered if anyone has any advice how to de-bug this, because I am struggling - is there a system log I can get to to find out why the watch app stopped?  Or something I need to do to stop the watch app shutting down - is it a power saving 'feature' that I need to disable?

The source code is here if you would like to see it: https://github.com/OpenSeizureDetector/Fitbit_SD.

[Gondwana · Accepted solution]

Unfortunately, messaging isn't as reliable as file transfer. Even file transfer fails about 5% of the time.

I, too, see dev bridge disconnections regularly. I'm not sure that this is indicative of behaviour of an app when it isn't being debugged. Red herring?

Re watch stopping, did you set Appbit's me.appTimeoutEnabled to false?

If it's just your app seeming to not monitor and send, it could happen if you're using ontick() which only fires when the watch's display is on.

You can use memory API to monitor memory usage.

In general, stick some console.log() output in strategic places in your code, then run it until it dies. You can then see where it got to (roughly).

[jones139]

---

@Gondwana wrote:

Re watch stopping, did you set Appbit's me.appTimeoutEnabled to false?

 I think that is it, thank you!   I had not seen the appTimeoutEnabled setting, so I have set it to false, and it seems to be running for longer than it would yesterday - will run it over night to check before I accept the solution, just in case.

Oddly though, when I print out the value of appTimeoutEnabled, it is false before i do anything to it, but maybe the act of importing the Appbit library is doing something.

Thanks!

Graham.

[brynjarb]

Did this work for you?

I'm trying to change the me.appTimeoutEnabled = false;

But when I do a console.log("Timeout Enabled: " + me.appTimeoutEnabled); after the change I still get true

[jones139]

It did work in the sense that it stops the app shutting down unexpectedly.
But I think I saw the same issue as you in that reading the value back
looks wrong.