Monthly Archives: March 2018

What the Alternative API mean for ConnectStats

Posted on by
5

Most users experienced new activities from Garmin not syncing up with ConnectStats since last week (March 23rd or so). As described in the last post, it can be fixed by using an alternative API.

It looks like it’s going to be a permanent change. It also has some minor consequences for users.

What is the alternative API?

It’s probably obvious to most of you, but the API is the mechanism that third party (ConnectStats) can use to access the data stored by a provider (Garmin or Strava).

Garmin a long time ago had a public API to access the activities recorded in Garmin Connect. Back in 2014, Garmin decided to change it’s approach to third party. While the old API allowed a third party to access directly the running or cycling data from Garmin servers, they decided to switch to a push approach. The key consequence is that a third party now has to build and maintain an infrastructure to store the data in the cloud after it was pushed by Garmin. This is great for a platform like Strava, it makes for a great user experience. But it’s impractical for small independent hobbyist developers like myself with ConnectStats like app.

While Garmin announced they would deprecate the old API in 2014, in practice until last week it continued to work more or less. It just had regular tiny changes, which beside the fact that the change came as a surprise outage to developer via lots of sudden bug reports, they were usually easy to keep up with.

The old API continued to work and was used by their own Garmin Connect website. since they upgraded their website to the new look shortly after the API announcement, they also slowly started to upgrade the site to a very different API. This is what the settings “Alternative API” refers to.

Practical Difference between the two API

ConnectStats downloads data in two stages. The first is to get a summary of all recent activities, which is intended to be faster. Then when you go and look at an activity in details, it will downloads all the individually recorded data point to create the graphs and the track on the map. The details can be a lot of data, so it’s an optimisation to only download the summary first.

The main difference between the two APIs, is that the new one (alternative) contains a lot less information in the summary. Using the new API, a lot of the extra information (for example: running dynamics, min and max, etc) will only be downloaded while getting the full detail of the activity. It’s not a major issue, as in practice when you select an activity, you need to wait a bit for the graphs and map data anyway.

Where it can impact the user experience is in some of the historical statistics pages. Some historical statistics on the extra information will be missing until each activity detail is downloaded. To mitigate the issue, ConnectStats tries to automatically download the last dozen or so activities that are missing detail.

Will the old API come back?

Only Garmin knows. But at this point I would anticipate it won’t. ConnectStats lived on borrowed time since 2014 when they announced they would deprecate the API.

Also the behaviour of the old API is not that it errors, but it contains a lot less data (almost none). In the past changes, it always was either some error, or some subtle change that broke ConnectStats use of the API. This time feels different.

What’s next?

I am releasing a new version of ConnectStats (4.3) that will by default use the new API. I keep the setting to switch back, in case things change in the short term and to keep optionality.

As in all the previous discussion on API change, I also continue to prepare for a day when Garmin may completely shutdown the API ConnectStats uses.

At such time the only option to continue using ConnectStats will be to switch to another service provider like Strava.

Using Strava data though has the drawback that it contains a lot less details on each activities (no running dynamics, etc).

Alternatively, now the the app is open source, if it comes to that we may link it to other service and hopefully the app will continue to live.

 

Activities not updating, how to fix…

Posted on by
6

Today, Friday march 23rd, 2018, the garmin api ConnectStats uses by default is not returning any new activities. It can be fixed by switching to the alternative api supported by the app.

 

This happened already in the past, but it was temporary then. Garmin API Change: Good News Bad News,

Assuming this is a permanent change, I’ll try to release shortly a new version that will by default use the new API. Meanwhile people need to switch manually if they see the issue.

Similar Summary Stats, Different effort…

Posted on by
4

While I still need to figure out how to use the new power field from Stryd, Running Power is already a useful other way to compare the type of effort of different activities. Since I got the new pod, I have been motivated to go out run more, and looking at the last few weeks, I realised that a few runs had interestingly some similar headline stats but very different feel. So I decided to see how ConnectStats displayed the differences.

In the summary, you can see the first two have very similar heart rate average, but very different pace, while the run in Shanghai has similar pace as the first one, but higher heart rate. The run in the new territories run (Hong Kong) is also interesting to compare to the Putney run (Richmond Park). Let’s dive in.

Comparing Activities in ConnectStats

You can easily compare two activities in ConnectStats by sliding the activities in the list and selecting mark. The activity will then shows in the background of the new one you look at.

A mark will be displayed to remind you which activity is the “compare” activity.

Same Heart Rate, Different Pace

The first two run to compare have an average of 176 and 175 HR respectively but a pace of 4:50 and 5:30. You can of course just look at the pace plot on top of each other, but it’s a bit messy

Note that the map will show you both activities, useful when they are on the same location, but less when they are quite different route, as here. The pace graph clearly shows that for large part of the run the pace was faster, but not very insightful. A much better way to compare the effort is to look at the best rolling plots.

You can see that it was definitely a higher power effort, but the pace shows that the slower run had more constant pace, flatter curve. The heart rate plot shows that the max effort (left part of the curve) was similar, but the tail was lower (steeper curve on the right for the faster curve). Overall a less consistent effort, but where I pushed more at time and resulted in the same average heart rate but very different pace. The power curve interestingly shows quite a higher effort. These were two different runs, the slower one was a commute run, with a backpack and on city streets with more stop and go at light. It was also early morning, so typically not when I do my best performances…

Same Pace, Different Heart Rate

We can also compare that same activity to another run a week ago with same pace (4:49 and 4:50) but higher heart rate (181 and 176 respectively).

You can see the activity being compared to (lighter colour) has clearly higher heart rate effort through out. One interesting observation is that the lower heart rate run has steeper start, which means there were a few period where I pushed rather than a continuous effort .The pace on the other hand has a quite a different profile between the two runs

The lower heart rate run has a much steeper shape, while the other one has a quite flat profile, meaning a more constant effort.

Now for the new measure of power, again interestingly the raw graph comparison is quite useless. Hard to really see much in the difference of the effort.

 But the best rolling graph again shows a very interesting story, if somewhat consistent with the other. While the effort was about the same, the higher graph shows a much more varied effort: more power on shorter time period, but converge at the end for the overall time.

The higher heart rate was just a run where I tried to push much more through out and consistently. Quite interesting that it resulted in the higher heart rate…

If you wonder why the little bump around 5min, me too! this is an annoying little bug or quirk which I haven’t yet figured out!

Time ahead

A last graph that maybe of interest, even though in this specific case, maybe less interesting in this specific case, but it shows you the time ahead (or behind) from the compared activity. The big straight drop are pauses. So you can see that I took quite a few pauses in the lower heart rate run, and it had period where I was catching up (upward slopping) and period where I was getting behind (downward slopping). On the map, the area where I am ahead are blue, and then goes to red when I am behind. Which makes it easy to see where you are behind or ahead, especially when the run is at the same place (not the case here).

Hope you found this interesting. Happy Training.