Follow TrendWeight:

@TrendWeight, Facebook

Hey, there! As you may be aware, TrendWeight is a web application that I originally created for myself, but then decided to make available for anyone to use. In reality, though, I am just a computer geek who likes to develop web applications in his free time—I'm not some big corporation with a team of support staff. That said, I am always willing to try to help or answer questions if you have them. Just email me at and I'll try to get back to you as soon as I can.

From time to time, I post on my blog when there are new features or important announcements regarding TrendWeight. You'll find the most recent blog posts related to TrendWeight below.

Odds are, you probably aren't interested in subscribing to my entire blog since it has posts about computer geek-y things not related to TrendWeight. So, if you want to stay in the loop with just TrendWeight things, your best bet is to follow @TrendWeight on Twitter or 'Like' the TrendWeight Facebook Page.

Fat Mass is Missing for Withings Users [Resolved]

Multiple Withings users have let me know that their Fat Mass data has disappeared from TrendWeight. Apparently something is going on with the Withings API. I don't know what the problem is yet, but I am investigating. Please stay tuned.

3/27 Update: I have confirmed with multiple users that the body fat data is simply missing from the data that the Withings API is giving TrendWeight. At this point, I don't know of anything I can do to change that. I still don't know why it is only happening to some people and not others. I have sent an email to Withings support asking if they know of anything that might have changed, and someone from Withings has already responded and is actively investigating the problem.

3/28 Updated: A developer at Withings emailed me to let me know that they found and fixed the problem. I confirmed that body mass data is once again appearing for several of the people who I know were affected and everything looks good. I automatically did a full resync for all Withings users who updated in the last week (which should catch anyone who might have been affected), so your missing data should now be back. If you notice anything wrong, though, don't hesitate to contact me.

And thanks to the folks at Withings for finding and fixing the problem so quickly.

Mystery Solved: FitBit Rounding Error

A long-standing mystery has finally been solved...

Short Version:

If your TrendWeight account is connected to Fitbit, and you don't use the metric system (kilograms), you may have noticed that the actual weights shown on TrendWeight were often different from the weights show on by 0.1 - 0.2 pounds. This doesn't happen anymore.

Long Version:

Sometimes Trendweight shows my actual scale weight as 0.1 lb higher or lower than what I remember the scale actually showing. I've noticed it on and off for a while, and I have gotten quite a few emails about it. I had looked into it in the past several times and confirmed that I am displaying exactly what Fitbit tells me in their API. So, I chalked it up to an idiosyncrasy on the Fitbit side. Who cares about 0.1 lb anyway?

Well, after yet another email today, I started looking into it again. After some research (aka Google searches), I found a couple other cases where people were having similar problems and in those reports was the nudge I needed to finally understand the problem. The problem is a rounding error when converting between Metric and English weight units. Here's what happens:

  1. You step on the scale and it displays your weight in pounds and sends it to the database.
  2. TrendWeight makes an API request and returns your recent weight readings in kilograms and rounded to 1 decimal place.
  3. TrendWeight converts your recent weight readings back into pounds.

The problem is the highlighted part of step #2. When your weight gets converted to kilograms and rounded to 1 decimal place and then converted back into pounds, the 0.1 - 0.2 lbs error gets introduced.

If only there was a way to tell the Fitbit API that I want the results in pounds (for users who are using pounds) so that I don't have to convert them myself, then this problem would go away... Oh wait. There is. Doh!

By asking Fitbit for weights directly in pounds, TrendWeight now gets actual scale weights that exactly match what was displayed on your scale and what you see on I should have realized this a long time ago, and so I feel a little foolish. Sorry.

TrendWeight's logic has been updated, and the next time you visit your dashboard, your weight readings for the past 21 days will automatically be re-downloaded and "fixed". That will result in an accurate current 'trend weight' (because that trend weight is based, essentially, on the past 20 days of weight readings).

If you really want to retroactively fix all your historical scale readings, you can do so by going into your settings and clicking the 'Resync All Data' button at the bottom of the page. However, do not click this if you have more than 3or 4 years of historical data in TrendWeight or you will risk running into the other Fitbit limitation that prevents TrendWeight from loading lots of historical data. If you have that much old data, you'll want to wait until that other limitation has been addressed.

Side Note

I also want to mention that I am actively working on a new version of the TrendWeight backend that addresses that Fitbit API limitation and also opens up the doors for addressing some of the long requested enhancements you all have made. I still have a bunch of work left to finish before it is ready, but at least the work is in progress...

As always, email me at if you have any questions or concerns.

iOS 7 and TrendWeight

I have gotten several reports of problems with using TrendWeight on iOS7 devices. Most commonly, I hear that TrendWeight seems to force you to login every time you open the site.

The underlying issue seems to be a bug or a series of bugs in Safari/iOS7 related to storing cookies. This Apple bug appears to affect all web apps, and not just TrendWeight, and other people are also reporting problems with iOS7 on this front. There have always been oddities in iOS with web apps that are pinned to the home screen, but it appears that iOS 7 made things noticeably worse.

Unfortunately, there is not anything I can do to fix the underlying problem, but I did make a small change that should cause TrendWeight to launch in the full Safari app instead of by itself. For some users, this seems to make your login session last longer, but it isn't a real fix and you'll eventually be asked to login again.

Until Apple addresses the underlying problems, there are two other workarounds I can suggest:

  • Instead of bookmarking your normal TrendWeight dashboard, bookmark (or add to your home screen) your public "sharing URL" (which you can find on your settings page). Your public "sharing URL" doesn't require you to login, so you won't see a login page when you visit that page regardless of if cookies are working or not.
  • You can also choose to use Chrome instead of Safari as a browser on iOS as cookies work fine in Chrome and so it will have no problem remembering your login.

If I hear more about the underlying Apple bug, I'll let you all know. Until then, if you have questions or concerns, email me at

TrendWeight Maintenance [All Clear]

Just a quick note that I am adjusting some of the TrendWeight server settings. As a result, you may get an SSL error from your browser saying that the name of ther server does not match the name of the web site. Example error dialog boxes are below (these are only a couple examples, your specific browser may look different). This is a benign error and should be resolved soon. You can safely ignore these errors.

I'll post again when things are back to normal. Sorry for the inconvenience.


Update (6/19, 10:28am):

The SSL certificate issues seem to have been resolved. Everything is working again. Note, I reserve the right to screw it up again as I keep tinkering :)

Dealing with Lots of Historical Data

So, a TrendWeight user contacted me this week to let me know he was getting an error about the FitBit website not working. It happened right after he loaded 10 years worth of historical data into FitBit and changed his TrendWeight start date to a date in 2013. At the same time that the email from this user arrived in my inbox, I also received an automated email from FitBit telling me that a user had exceeded the API request limits and had been temporarily blocked for 1 hour. Oops.

There are two "rules" that FitBit enforces on their API that are the heart of this problem:

  • No single request for data can retrieve more than 1 month of data at a time.
  • No single user can make more than 150 requests in a single hour (or they get blocked temporarily).

Add in that the API requires separate requests for weight and body fat data. Now, let's do the math on how many requests are required to load 10 years worth of data:

10 years 12 months/year 2 requests/month = 240 requests

So, 240 requests are needed to load 10 years worth of data, but FitBit blocks requests after 150. What it boils down it is that, current, it is not possible to tell TrendWeight to use a start date 10 years in the past.

I have looked more carefully at the FitBit API and there are basically two options that I can think of to resolve this:

Option 1: I could create a queuing system so that when you need to load 10 years worth of data, it doesn't do it all right away. Instead it would do a few years, wait and hour, do another few years, wait an hour, etc, until all the data was loaded.

Option 2: I could use a different API for "old" data. FitBit has an alternate API that allows me to request up to 3 years of weight or body fat data in a single request. The catch is that they only return a single data point per day. If you weight yourself multiple times in a single day, the FitBit API appears to return the last weight of the day. This is different than what TrendWeight does right now. Currently, if you weigh yourself multiple times in a single day, TrendWeight uses the first weight of the day because if you weigh yourself right after you wake up, the weight readings tend to be more consistent. My approach would probably be to use the existing API for any data in the past 12 months and to use the less-precise bulk API for data older than 1 year.

Neither option is really very good, in my opinion. Option 1 is a pain for users. I wouldn't want to have to wait several hours just to see my data. This delay would happen not only when you first setup your account, but it happens any time TrendWeight has to do a full resync: when you change your start date, when you change your time zone, when you change your weight units, when you click the 'Resync All Data' button.

Option 2 is a little better because it means you can get all your data pretty much instantaneously, but it isn't perfect either. The biggest issue would be that your weight for any given day might subtly change after 1 year. For example, let's say I weigh myself today (June 8, 2013) in the morning and weigh 220 lbs. Then I weigh myself in the evening after a large meal and weigh 224 lbs. For the next few months, TrendWeight will use 220 lbs as my scale reading for the day. However, if I need to do a resync 13 months from now, TrendWeight will suddenly start using 224 lbs as my scale reading for June 8, 2013.

In the grand scheme of things, maybe this doesn't matter all that much. It won't affect the trend weight calculations for July 2014 because the trend weight math is generally unaffected by weight readings older than 20 days or so. Mostly, the graph will have a slightly different shape than it did before if I happen to look back in time at that older-than-one-year data.

My inclination is to go ahead and program Option 2 because having approximately correct old data is better than not having old data at all, but what do you guys think? Would Option 1's queuing system be better even if it meant that you you have to wait an hour or two to see your data anytime TrendWeight decides it needs to do a full resync?