Accuracy of Sync Solver Health to Fitbit

A few days ago, I posted instructions on how I have set up my iPhone and Pebble Time devices to push step counts to my corporate wellness program via Fitbit. My first day using the step synchronization was frustrating as I tried to figure out why steps tallied in Fitbit were not matching those in iOS Health. With some digging into the numbers, I think I see what is going on.

Hourly Shifting During the Day

My first observations were yesterday, Jan 24, at 16:30. At that time, iOS Health was reporting a daily total of 1967 steps. Fitbit, on the other hand, was reporting 1797 steps. Here is a snippet of raw sample data from the iOS Heath app. Note that all of the samples that fall between 15:00 and 16:00 hour add up to 183 steps. We can call this the 3PM hourly block.

Now, look at the data dumped from iOS Heath to a *.csv file using QS Access.  This is shown in the first three columns of the spreadsheet below. Importantly, this dump shows the actual time ranges used to aggregate the hourly samples; there is no ambiguity as to what steps fell in which hourly block. We can also see that these block ranges are correct since the 15:00 to 16:00 range reports the 183 steps seen in the detailed view above. I have spotted checked a number of hourly totals; they were all correct and matched what I was doing at the time.

In this same spreadsheet, the colored cells show the rows that can be summed up to compute the Fitbit number 1797 and the iOS Health number 1967. The inclusion of the 60 steps on the first row is problematic and discussed in more detail.

Next, look at what shows up on Fitbit's server at 16:30 after having completed a force push from  Sync Solver Health to Fitbit using the "Sync Now" feature. The individual samples that were pushed on an hourly basis exactly match those extracted from iOS Health. This is great news - no wonky round-off errors, duplicated entries, missing entries, or other common syncing problems.

However, something is fishy about the time-alignment of these samples. The way this data is labeled leaves some ambiguity as to the meaning of the time-stamps. Do they represent the time at the beginning or at the end of the hourly blocks in which the steps occurred. This makes a big difference in how the daily total should be computed and how data should be posted.

• The way that the hourly samples from the Health app are pushed in would imply that the times represent the end of the blocks. For example, we know that the 602 steps were taken between 14:00 and 15:00 and they are labeled as "Today, 3:00PM". The time stamp is interpreted as the "steps taken as of 15:00."

• However, in the image above note the circled samples, all of which are label with the date "Today". These correctly sum up to the daily total of 1797 steps. However, they include the 12:00AM sample. Thus, Fitbit is clearly treating the time stamp as representing the beginning of the hourly blocks, otherwise the sample at midnight would have been included as part of "Jan 23". The time stamp is interpreted as the "steps taken in the 12:00 hour."

Though this explains inaccuracies in daily totals, I am not sure if this explains why the 183 step sample is not showing up in Fitbit as part of the push I did at 16:30. Is there simply a large delay in posting or is it a side-effect of the apparent shifting in time?

Hourly Shifting in Daily Totals

The next morning, I dumped all of the data again. Ignoring any issues of delay in posting hourly results, we can look at what happens to the daily totals. As I had expected from the behavior above, the daily totals in Fitbit are wrong. Fitbit shows 4367 steps and both the Pebble watch and iOS Health report 4650 steps. The same color coding in the spreadsheet shows what is happening. The Fitbit daily total includes the tail end of the previous day but omits the end of the current day.

In practice, this will not matter for most people who are always asleep from 11pm to midnight as the mismatched tails will both contain zero steps. However, for those of us who are not, it is an annoyance to have to mentally track two sets of numbers.

I have double checked that my iPhone and Fitbit account are both using the same time-zone to eliminate that as a possible cause of the time-shifting. Two possibilities occur to me. First, the Fitbit portal has an error in how it accumulates steps. I don't think this is the case because I did not have mismatch problems when I was using a Fitbit One device. More likely, Sync Solver is pushing data into the API with the wrong choice of time stamp (beginning vs. end) for an activity block.

Daily Shifting

Interestingly, you will recall from my earlier post that a similar time-shift occurred when I pushed the month's history of daily values up to Fitbit. All of the totals ended up posted in Fitbit on the day after they should have been. For example, all of the steps I took on Jan 1 ended up as the total in Fitbit for Jan 2. This is potentially caused by the same type of problem, a confusion about whether to pass the time-stamp at the beginning of the day or end of the day.

Update Jan 28 - Authors contacted me to say they would look into the issue. Looking forward to a patch to give a fully working, though complex solution to my problem of getting Pebble steps into our corporate portal.

Update Feb 25 - Authors contacted me today with a screen shot related to a proposed fix which looks like it will address the hour-offset problem I have been having. Look forward to testing it out when it its the App Store.

Update Mar 4 - Completed a beta test of an upcoming patch. I posted that this does fix the daily problem.

Update Mar 25 - The updated version finally hit the app store today. Case closed. Now, if only iOS would let SyncSolver update in the background more reliably.